How to Build an EHR Platform - HL7 FHIR, ONC Certification, HIPAA Architecture, and Clinical Data Model 2026
The global EHR market is projected to reach $55.11 billion by 2033, growing at a CAGR of 5.10%. Every hospital, clinic, and healthcare provider in the United States is required to maintain electronic health records.
The 21st Century Cures Act mandates interoperability. CMS requires FHIR-based APIs. ONC certifies EHR systems against a defined set of criteria before they can be used for Medicare and Medicaid programmes.
Building an EHR is the most technically complex category of healthcare software. It is not a database with a clinical theme. It is a regulated, certified, multi-stakeholder platform that must handle clinical workflows, insurance billing, laboratory integration, prescription management, patient engagement, and interoperability with every other system in the healthcare ecosystem, simultaneously, reliably, at the data quality standard that patient safety requires.
EngineerBabu has built healthcare platforms for Apollo Hospitals, Somnoware (acquired by ResMed), and digital health clients across the US, UK, and India. CMMI Level 5. Google AI Accelerator 2024 Top 20. This guide covers everything required to build a production-grade EHR platform.
The EHR Architecture – Five Layers
| Layer | What It Does |
| Clinical data layer | Patient records – demographics, diagnoses, medications, allergies, lab results, vitals |
| Workflow layer | Clinical workflows – scheduling, charting, orders, prescriptions, billing |
| Interoperability layer | HL7 FHIR R4 APIs – data exchange with payers, labs, pharmacies, other EHRs |
| Decision support layer | Clinical alerts – drug interactions, care gap reminders, order sets |
| Patient engagement layer | Patient portal – record access, appointment scheduling, secure messaging |
Module 1 – The Clinical Data Model
The clinical data model is the foundation of everything else. Get it wrong and every feature built on top of it carries the error forward.
The core clinical entities:
| Entity | What It Stores | FHIR Resource |
| Patient | Demographics, identifiers, contact | Patient |
| Encounter | Each clinical visit – date, provider, location, type | Encounter |
| Condition | Diagnoses – ICD-10 codes, onset, clinical status | Condition |
| Observation | Vitals, lab results, clinical findings | Observation |
| MedicationRequest | Prescriptions – drug, dose, route, frequency | MedicationRequest |
| AllergyIntolerance | Documented allergies – substance, reaction, severity | AllergyIntolerance |
| Procedure | Completed procedures – CPT/HCPCS, date, performer | Procedure |
| DiagnosticReport | Lab and imaging reports – with component results | DiagnosticReport |
| Immunization | Vaccine history – CVX codes, dates, administered by | Immunization |
| DocumentReference | Clinical notes – SOAP notes, discharge summaries | DocumentReference |
| CarePlan | Care plans – goals, interventions, responsible party | CarePlan |
| Appointment | Scheduled visits – provider, slot, type | Appointment |
The data model decisions that determine everything:
Decision 1 – OMOP vs FHIR-native vs proprietary: The OMOP Common Data Model (OHDSI community standard) is optimised for research and analytics. FHIR-native storage maps directly to FHIR resources. Proprietary models give flexibility but create interoperability debt. For new EHR builds in 2026: FHIR-native with PostgreSQL as the primary store, OMOP as the analytics layer.
Decision 2 – Versioned records: Every change to a patient record, a diagnosis updated, a medication discontinued, must be versioned. The platform must be able to reconstruct the patient’s clinical state at any point in time. This is not optional for a production EHR, it is a clinical and legal requirement.
Decision 3 – Terminology standards: Every clinical concept must be coded against a standard terminology:
| Clinical Domain | Standard | Example |
| Diagnoses | ICD-10-CM | J45.20 (Mild intermittent asthma) |
| Procedures | CPT / HCPCS | 99213 (Office visit, established) |
| Medications | RxNorm | 1049502 (Metformin 500mg tablet) |
| Lab tests | LOINC | 2339-0 (Glucose, serum) |
| Vaccines | CVX | 207 (COVID-19 mRNA) |
| Allergies | SNOMED CT | 372687004 (Amoxicillin) |
Module 2 – HL7 FHIR R4 API Layer
The 21st Century Cures Act requires ONC-certified EHRs to support FHIR R4 APIs for patient and provider access. The CMS Interoperability Rule extends these requirements to payer systems. FHIR is not optional for any EHR built in 2026.
The required FHIR capabilities for ONC certification:
| Capability | What It Enables |
| FHIR R4 RESTful APIs | Read, write, search, and update clinical resources |
| SMART on FHIR | OAuth2-based authorisation for third-party app access |
| Bulk Data Export ($export) | Population-level data access for analytics and quality reporting |
| CDS Hooks | Real-time clinical decision support embedded in EHR workflows |
| Patient Access API | Patients can access their records via third-party apps |
| Provider Directory API | Published provider information for care coordination |
The SMART on FHIR authorisation flow:
SMART on FHIR is the OAuth2-based framework that allows third-party apps, patient-facing portals, clinical analytics tools, billing systems to access EHR data with appropriate authorisation.
| Step | What Happens |
| 1. App registration | Third-party app registers with the EHR’s authorisation server |
| 2. Launch | App launches within EHR (EHR launch) or standalone |
| 3. Authorisation request | App requests specific FHIR scopes (patient/.read, user/.write) |
| 4. User consent | Clinician or patient approves the requested scopes |
| 5. Token exchange | App receives access token |
| 6. FHIR API access | App calls FHIR APIs with bearer token |
| 7. Token refresh | Access token refreshed using refresh token |
The FHIR search parameters:
Every FHIR resource supports standard search parameters. The EHR must implement these correctly for interoperability:
| Resource | Key Search Parameters |
| Patient | name, birthdate, identifier, gender |
| Observation | patient, code, date, category |
| MedicationRequest | patient, status, medication |
| Condition | patient, code, clinical-status, onset-date |
| Encounter | patient, date, type, status |
Module 3 – ONC Certification Requirements
ONC (Office of the National Coordinator for Health Information Technology) certifies EHR systems against criteria defined in the 21st Century Cures Act. ONC certification is required for EHRs used in Medicare and Medicaid programmes.
The ONC certification criteria categories:
| Criterion Category | Examples |
| Clinical | Problem list, medication list, medication allergy list, demographics, vital signs, smoking status |
| Care coordination | Care plan, referral summary, transitions of care |
| Clinical decision support | Drug-drug interaction checking, drug-allergy checking, relevant care gap reminders |
| Electronic prescribing | EPCS (Electronic Prescribing of Controlled Substances), formulary checks |
| Patient access | View/download/transmit, SMART on FHIR API |
| Security | Authentication, authorisation, audit log, encryption |
| Reporting | Quality measure calculation, QRDA I and III export, FHIR quality reporting |
The certification process:
- ONC-Authorised Testing Laboratory (ONC-ATL) tests the EHR against the certification criteria
- ONC-Authorised Certification Body (ONC-ACB) reviews and grants certification
- The certified EHR is listed on the ONC Certified Health IT Product List (CHPL)
Building for ONC certification from the start (not retrofitting) is the difference between a 6-month certification process and an 18-month one.
Module 4 – Clinical Workflow Modules
-
Module 4a – Patient Registration and Demographics:
Every encounter begins with patient registration. The registration module captures:
| Field Category | Fields |
| Identity | Name, DOB, gender, race, ethnicity, preferred language |
| Contact | Address, phone, email |
| Identifiers | MRN (Medical Record Number), SSN (encrypted), insurance member ID |
| Insurance | Primary and secondary coverage, guarantor |
| Emergency contact | Name, relationship, phone |
-
Module 4b – Appointment Scheduling:
The scheduling module manages provider calendars, appointment types, and patient booking:
| Feature | Details |
| Provider schedule management | Define appointment slots by type, duration, and availability |
| Online patient scheduling | Patient portal self-scheduling for appropriate appointment types |
| Waitlist management | Queue management for high-demand providers |
| Appointment reminders | SMS + email + phone at 7 days, 48 hours, and day-of |
| No-show tracking | Pattern tracking for care gap identification |
-
Module 4c – Clinical Documentation (SOAP Notes):
The clinical documentation module is where clinicians spend most of their time. A poor documentation experience is the primary driver of EHR abandonment.
The structured SOAP note:
- S (Subjective): Chief complaint, history of present illness, review of systems
- O (Objective): Vital signs, physical examination findings, lab results
- A (Assessment): Problem list, diagnoses (ICD-10 coded)
- P (Plan): Orders, prescriptions, referrals, follow-up instructions
AI-assisted documentation:
In 2026, the best EHRs include ambient documentation, AI that listens to the clinical encounter (with patient consent) and generates a draft SOAP note. The physician reviews and edits rather than typing from scratch. This reduces documentation time by 50 to 70% and is rapidly becoming a standard EHR feature.
-
Module 4d – Order Management (CPOE):
Computerised Provider Order Entry (CPOE) allows clinicians to enter orders directly, eliminating transcription errors.
| Order Type | What the Module Handles |
| Medication orders | Drug name, dose, route, frequency, duration, PRN conditions |
| Lab orders | Test selection, specimen type, priority, collection instructions |
| Imaging orders | Modality, body part, clinical indication, priority |
| Procedure orders | Procedure type, location, pre-procedure instructions |
| Referral orders | Specialty, urgency, clinical indication, supporting documentation |
-
Module 4e – Electronic Prescribing (eRx):
All prescriptions are transmitted electronically via Surescripts. Controlled substances require EPCS (Electronic Prescribing of Controlled Substances) with two-factor authentication.
| Feature | Regulatory Basis |
| Standard prescription (eRx) | Surescripts NCPDP SCRIPT standard |
| Controlled substance prescription | DEA EPCS rules – two-factor auth required |
| Formulary check | Verify drug is on patient’s insurance formulary before prescribing |
| Drug interaction check | Real-time check against clinical drug database (FDB, Multum) |
| Refill request management | Handle pharmacy-initiated refill requests |
Module 5 – Laboratory and Imaging Integration
- Lab integration (LIS – Laboratory Information System):
| Integration Type | Protocol | What It Delivers |
| Order transmission | HL7 v2 OML (Order Message – Lab) | Lab order sent to lab system |
| Result receipt | HL7 v2 ORU (Observation Result) | Result received in EHR, matched to order |
| FHIR-based (modern) | FHIR R4 ServiceRequest + DiagnosticReport | For modern LIS with FHIR capability |
- Abnormal result routing:
When a result arrives flagged as abnormal (H/L/C/P flags in HL7 or equivalent FHIR value), the platform:
- Routes to the ordering provider’s result review queue
- Sends an alert (configurable by severity – critical values get immediate notification)
- Links the result to the relevant encounter and problem list
- Documents the provider’s result acknowledgement for liability purposes
- Imaging integration (RIS/PACS):
Radiology results arrive via HL7 ORU messages or FHIR DiagnosticReport. DICOM images are stored in a PACS (Picture Archiving and Communication System) and linked to the EHR via WADO-RS (Web Access to DICOM Objects via RESTful Services).
Module 6 – Patient Portal
ONC certification requires patient access to their records via a patient portal. The portal covers:
| Feature | FHIR Resource Used | Patient Can Do |
| Health summary | Patient, Condition, Allergy, Medication | View active conditions, allergies, medications |
| Lab results | DiagnosticReport, Observation | View results with provider interpretation |
| Appointments | Appointment | View upcoming, request new, cancel |
| Secure messaging | Communication | Message care team, receive responses |
| Prescription history | MedicationRequest | View prescriptions, request refills |
| Visit notes | DocumentReference (OpenNotes) | View clinical notes from visits |
| Care plan | CarePlan | View goals and care team recommendations |
The Tech Stack
| Layer | Technology | Why |
| Backend | Python (FastAPI) + Node.js | Python for AI/NLP; Node.js for real-time HL7 processing |
| FHIR server | HAPI FHIR (Java) | Most complete open-source FHIR R4 server |
| Database | PostgreSQL | ACID compliance, FHIR-native JSON support |
| SMART authorisation | Keycloak + SMART on FHIR library | OAuth2 + OpenID Connect |
| Terminology | VSAC (NCI) + local term server | ICD-10, LOINC, RxNorm, SNOMED |
| HL7 messaging | Mirth Connect or Azure Health Data Services | ADT, ORU, ORM message processing |
| Clinical NLP (ambient) | GPT-4o + custom fine-tuning | Ambient documentation, note generation |
| Cloud | AWS (HIPAA BAA available) | HIPAA-compliant infrastructure |
| Security | SOC 2 Type II + HIPAA | Required for all healthcare data |
Build Cost
| Module | Cost Range (USD) | Notes |
| Clinical data model + FHIR R4 server | $15K – $28K | HAPI FHIR + custom extensions |
| Patient registration + scheduling | $8K – $15K | |
| Clinical documentation (SOAP + templates) | $10K – $18K | |
| CPOE – orders management | $10K – $18K | |
| Electronic prescribing (Surescripts) | $8K – $15K | Surescripts certification required |
| Drug interaction checking (FDB/Multum) | $5K – $10K | Annual licensing extra |
| Lab integration (HL7 v2 ORU/OML) | $6K – $12K | |
| SMART on FHIR authorisation | $6K – $12K | |
| CDS Hooks implementation | $6K – $12K | |
| Patient portal | $8K – $15K | |
| Ambient AI documentation | $10K – $20K | GPT-4o fine-tuning |
| ONC certification prep | $15K – $30K | Testing lab fees extra |
| AWS HIPAA + SOC 2 + VAPT | $10K – $20K | |
| Total | $117K – $225K | ONC-certifiable EHR |
EngineerBabu built healthcare platforms for Apollo Hospitals and Somnoware (acquired by ResMed). CMMI Level 5. Google AI Accelerator 2024 Top 20. Contact: mayank@engineerbabu.com
Frequently Asked Questions about EHR platform development
-
What is ONC certification and why does an EHR need it?
ONC (Office of the National Coordinator for Health Information Technology) certifies EHR systems against criteria defined in the 21st Century Cures Act and implementing regulations. ONC certification is required for EHRs used in programmes that provide incentive payments, Medicare, Medicaid, and MIPS (Merit-based Incentive Payment System). Without ONC certification, providers using the EHR cannot receive Medicare and Medicaid incentive payments and may face payment adjustments. The certification process involves testing by an ONC-Authorised Testing Laboratory and certification by an ONC-Authorised Certification Body. Building for ONC certification from the architecture stage (not retrofitting) is the critical decision, the data model, API layer, security architecture, and clinical functions must all be designed to meet certification criteria.
-
What is SMART on FHIR and why does it matter for EHR development?
SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on FHIR) is the HL7-standardised authorisation framework that allows third-party applications to access EHR data securely. It combines OAuth2 for authorisation, OpenID Connect for identity, and FHIR for data access. A SMART-enabled EHR can support a marketplace of third-party clinical apps, a cardiology specialist app, a diabetes management tool, a revenue cycle analytics platform that launch within the EHR workflow with appropriate access to patient data. ONC certification requires SMART on FHIR support for both patient-facing and provider-facing applications. For EHR developers, implementing SMART correctly is one of the most technically complex requirements, the authorisation server, scope definitions, token management, and app launch flows all require careful implementation.
-
What is the minimum viable EHR for a specialty clinic in 2026?
A minimum viable EHR for a specialty clinic needs: patient demographics and registration, appointment scheduling, clinical documentation (SOAP note with the relevant specialty’s template), problem and medication list management, electronic prescribing (Surescripts integration), lab result receipt and review, and a patient portal for record access and secure messaging. A focused specialty EHR (single specialty, 5 to 20 providers, one location) can be built for $80,000 to $130,000 and achieve ONC certification in 9 to 12 months. Multi-specialty, multi-location systems with full interoperability, ambient AI documentation, and revenue cycle integration run $150,000 to $250,000 and take 14 to 18 months to ONC certification.
