EHR software development means building a clinical system of record that is safe, auditable and able to exchange data through standards such as HL7 FHIR. The software must also meet health privacy law, such as HIPAA in the United States and GDPR in the EU.
This guide covers the modules, the compliance rules, EHR integration, the build steps and the cost drivers. Most of the work goes into clinical workflows, integrations and compliance, and blockchain plays a small supporting role at most.
People often use EMR and EHR as the same term, but the two differ. An EMR (electronic medical record) is a digital chart used inside one practice, while an EHR (electronic health record) shares a patient's record across providers, so interoperability is a core requirement. EMR software development for a single practice still needs most of the same modules and rules.
Core modules of EHR software
| Module | What it covers | Notes |
|---|---|---|
| Patient chart | Demographics, problems, medications, allergies, history and notes | Structured data coded with SNOMED CT, LOINC, RxNorm and ICD-10 |
| Clinical documentation | Encounter notes, templates, and voice or AI-assisted drafts | Clinicians judge a system largely by how fast they can document a visit |
| Orders and results | Lab and imaging orders, results and alerts | Many lab interfaces still use HL7 v2 messages |
| E-prescribing | Prescriptions sent to pharmacies, with drug interaction checks | In the US, controlled substances need EPCS identity proofing and two-factor signing |
| Scheduling and patient portal | Appointments, secure messages and patient access to records | Patients have a legal right to access their data |
| Billing and coding | Charge capture, claims and eligibility checks | Often a separate practice management or revenue cycle system |
| Reporting | Quality measures, registries and public health reports | Requirements differ by country and payer program |
Compliance rules for EHR and EMR software
United States
The HIPAA Privacy and Security Rules protect protected health information (PHI). For a development team, HIPAA means these controls:
- Role-based access control.
- Audit logs that show who viewed which record.
- Encryption in transit and at rest.
- A breach notification process and regular risk assessments.
- A business associate agreement (BAA) with every vendor that handles PHI, including the cloud provider.
HHS proposed changes to the HIPAA Security Rule in January 2025 that would make encryption and multi-factor authentication mandatory. As of October 2026, HHS has not published a final rule, so the current rule still applies. The 2026 federal regulatory agenda lists July 2027 as the target date for a final rule.
Products sold to providers in federal programs usually need certification under the ASTP/ONC Health IT Certification Program. The HTI-1 rule made USCDI v3 and US Core 6.1.0 the baseline from 1 January 2026, and the 21st Century Cures Act also bans information blocking. In December 2025, ASTP/ONC proposed the HTI-5 rule, which would remove 34 of the 60 certification criteria. The comment period closed in February 2026, and as of October 2026 ASTP/ONC had not published a final HTI-5 rule.
European Union
GDPR treats health data as a special category with stricter conditions, and national laws add more duties. The European Health Data Space Regulation (EU) 2025/327 entered into force in March 2025 and applies from 26 March 2027. The regulation sets requirements for EHR systems, including support for the European EHR exchange format, and these requirements phase in from 2029.
EHR integration with HL7 FHIR
HL7 FHIR exchanges health data through REST APIs and JSON resources such as Patient, Observation, MedicationRequest and Encounter. EHR integration usually uses several standards together:
| Standard | Typical use |
|---|---|
| FHIR R4 with US Core | Read and write patient data through APIs that certified US systems must offer |
| SMART App Launch v2 | Lets a third-party app open inside an EHR and receive limited permissions through OAuth 2.0 |
| Bulk FHIR | Exports data for a whole patient group, for analytics or population health |
| HL7 v2 | Lab results, admissions and other hospital messages; many interfaces still run on it |
| C-CDA | Summary documents, such as a discharge summary or care record |
Large EHR vendors publish developer programs for these APIs, such as Epic on FHIR, while hospital HL7 v2 feeds usually pass through an interface engine. Mirth Connect was a common open-source engine, but NextGen moved it to a commercial-only license with version 4.6 in 2025, so teams should check the Mirth Connect license before they choose the engine.
A data model that maps cleanly to FHIR resources from the start saves a large amount of rework later. In the US, TEFCA connects national networks through Qualified Health Information Networks (QHINs).
EHR software development steps
- Choose a specialty and setting. A behavioral health EMR, a dental system and a hospital EHR have very different workflows, and new products usually compete through a specialty focus.
- Observe clinicians at work and record real workflows and problems before you design screens.
- Design the data model around FHIR resources and standard code systems.
- Build security in: role-based access, audit logs, encryption, single sign-on and session limits.
- Integrate labs, pharmacies, imaging, health information exchanges and billing.
- Test clinical safety, including drug alerts, result routing and the system's behavior when an integration fails.
- Certify where needed, then pilot in a few practices before a wide rollout.
Build, buy or extend
A full EHR takes several years to build, so many new products build a specialty app on top of an existing EHR's APIs instead. Others license a modular platform and build only the parts that make their product different.
Assuming standard requirements, a focused specialty EMR with charting, scheduling, a patient portal and a few integrations needs a team of about six to ten people. Such a product usually needs more than a year before real clinical use. Certification and compliance add cost on top of development.
The main cost drivers are:
- The number of integrations, especially HL7 v2 hospital interfaces.
- Certification testing and the work to keep it current as rules change.
- Security controls, penetration tests and HIPAA risk assessments.
- Clinical content such as drug databases and code sets, which are often licensed.
- Hosting on a cloud service that signs a BAA.
Where blockchain fits, and where it must not
Never store PHI on a blockchain, even in encrypted form. A ledger copies records to many nodes and keeps them permanently, which conflicts with patients' right to correct records and with deletion duties. Encryption can also fail later if keys leak or algorithms weaken. Defensible uses keep all clinical data off the chain:
- Consent records. A tamper-evident log stores hashes of each consent and each withdrawal of consent.
- Audit anchoring. The system writes hashes of access logs to a ledger at fixed intervals, so any later change to a log is detectable.
- Clinician credentials. Licenses and certifications become verifiable credentials that hospitals can check quickly.
- Drug supply traceability, covered in the guide to blockchain in the pharmaceutical industry.
Signed audit logs without a blockchain can solve several of these needs. The article on blockchain in healthcare covers the wider picture, and the guide to blockchain cybersecurity covers the security trade-offs.
Frequently asked questions
What is the difference between EMR and EHR software?
An EMR is a digital chart used inside one organization, while an EHR shares records across providers, so interoperability is part of its design. Most new systems aim to be EHRs.
Does EHR software need ONC certification?
In the US, certification matters when customers take part in federal programs that require certified technology. Small specialty tools may not need certification, but buyers often ask for it.
How does EHR integration work?
Most new integrations use FHIR APIs with SMART App Launch for authorization, though lab and hospital feeds often still use HL7 v2 messages through an interface engine.
Can patient records be stored on a blockchain?
No. Keep records in compliant storage with access control, and if you use a ledger, it should hold only non-sensitive references such as consent events or audit hashes.
Is FHIR enough for interoperability?
FHIR is the base. Most systems also need HL7 v2 for lab and hospital interfaces, C-CDA for summary documents, and membership in exchange networks.