{"id":23453,"date":"2026-06-19T07:45:55","date_gmt":"2026-06-19T07:45:55","guid":{"rendered":"https:\/\/engineerbabu.com\/blog\/?p=23453"},"modified":"2026-06-19T07:45:55","modified_gmt":"2026-06-19T07:45:55","slug":"ehr-platform-development","status":"publish","type":"post","link":"https:\/\/engineerbabu.com\/blog\/ehr-platform-development\/","title":{"rendered":"How to Build an EHR Platform – HL7 FHIR, ONC Certification, HIPAA Architecture, and Clinical Data Model 2026"},"content":{"rendered":"

The global EHR market is projected to reach <\/span>$55.11 billion by 2033<\/span><\/a>, growing at a CAGR of 5.10%. Every hospital, clinic, and healthcare provider in the United States is required to maintain electronic health records.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

EngineerBabu<\/span><\/a> 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.<\/span><\/p>\n

\"\"<\/p>\n

The EHR Architecture – Five Layers<\/b><\/h2>\n\n\n\n\n\n\n\n\n
Layer<\/b><\/td>\nWhat It Does<\/b><\/td>\n<\/tr>\n
Clinical data layer<\/b><\/td>\nPatient records – demographics, diagnoses, medications, allergies, lab results, vitals<\/span><\/td>\n<\/tr>\n
Workflow layer<\/b><\/td>\nClinical workflows – scheduling, charting, orders, prescriptions, billing<\/span><\/td>\n<\/tr>\n
Interoperability layer<\/b><\/td>\nHL7 FHIR R4 APIs – data exchange with payers, labs, pharmacies, other EHRs<\/span><\/td>\n<\/tr>\n
Decision support layer<\/b><\/td>\nClinical alerts – drug interactions, care gap reminders, order sets<\/span><\/td>\n<\/tr>\n
Patient engagement layer<\/b><\/td>\nPatient portal – record access, appointment scheduling, secure messaging<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/h2>\n

\"\"Module 1 – The Clinical Data Model<\/b><\/h2>\n

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.<\/span><\/p>\n

The core clinical entities:<\/b><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Entity<\/b><\/td>\nWhat It Stores<\/b><\/td>\nFHIR Resource<\/b><\/td>\n<\/tr>\n
Patient<\/span><\/td>\nDemographics, identifiers, contact<\/span><\/td>\nPatient<\/span><\/td>\n<\/tr>\n
Encounter<\/span><\/td>\nEach clinical visit – date, provider, location, type<\/span><\/td>\nEncounter<\/span><\/td>\n<\/tr>\n
Condition<\/span><\/td>\nDiagnoses – ICD-10 codes, onset, clinical status<\/span><\/td>\nCondition<\/span><\/td>\n<\/tr>\n
Observation<\/span><\/td>\nVitals, lab results, clinical findings<\/span><\/td>\nObservation<\/span><\/td>\n<\/tr>\n
MedicationRequest<\/span><\/td>\nPrescriptions – drug, dose, route, frequency<\/span><\/td>\nMedicationRequest<\/span><\/td>\n<\/tr>\n
AllergyIntolerance<\/span><\/td>\nDocumented allergies – substance, reaction, severity<\/span><\/td>\nAllergyIntolerance<\/span><\/td>\n<\/tr>\n
Procedure<\/span><\/td>\nCompleted procedures – CPT\/HCPCS, date, performer<\/span><\/td>\nProcedure<\/span><\/td>\n<\/tr>\n
DiagnosticReport<\/span><\/td>\nLab and imaging reports – with component results<\/span><\/td>\nDiagnosticReport<\/span><\/td>\n<\/tr>\n
Immunization<\/span><\/td>\nVaccine history – CVX codes, dates, administered by<\/span><\/td>\nImmunization<\/span><\/td>\n<\/tr>\n
DocumentReference<\/span><\/td>\nClinical notes – SOAP notes, discharge summaries<\/span><\/td>\nDocumentReference<\/span><\/td>\n<\/tr>\n
CarePlan<\/span><\/td>\nCare plans – goals, interventions, responsible party<\/span><\/td>\nCarePlan<\/span><\/td>\n<\/tr>\n
Appointment<\/span><\/td>\nScheduled visits – provider, slot, type<\/span><\/td>\nAppointment<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The data model decisions that determine everything:<\/b><\/p>\n

Decision 1 – OMOP vs FHIR-native vs proprietary:<\/b> 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.<\/span><\/p>\n

Decision 2 – Versioned records:<\/b> 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.<\/span><\/p>\n

Decision 3 – Terminology standards:<\/b> Every clinical concept must be coded against a standard terminology:<\/span><\/p>\n\n\n\n\n\n\n\n\n\n
Clinical Domain<\/b><\/td>\nStandard<\/b><\/td>\nExample<\/b><\/td>\n<\/tr>\n
Diagnoses<\/span><\/td>\nICD-10-CM<\/span><\/td>\nJ45.20 (Mild intermittent asthma)<\/span><\/td>\n<\/tr>\n
Procedures<\/span><\/td>\nCPT \/ HCPCS<\/span><\/td>\n99213 (Office visit, established)<\/span><\/td>\n<\/tr>\n
Medications<\/span><\/td>\nRxNorm<\/span><\/td>\n1049502 (Metformin 500mg tablet)<\/span><\/td>\n<\/tr>\n
Lab tests<\/span><\/td>\nLOINC<\/span><\/td>\n2339-0 (Glucose, serum)<\/span><\/td>\n<\/tr>\n
Vaccines<\/span><\/td>\nCVX<\/span><\/td>\n207 (COVID-19 mRNA)<\/span><\/td>\n<\/tr>\n
Allergies<\/span><\/td>\nSNOMED CT<\/span><\/td>\n372687004 (Amoxicillin)<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Module 2 – HL7 FHIR R4 API Layer<\/b><\/h2>\n

The 21st Century Cures Act requires ONC-certified EHRs to support <\/span>FHIR R4 APIs<\/span><\/a> 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.<\/span><\/p>\n

The required FHIR capabilities for ONC certification:<\/b><\/h3>\n\n\n\n\n\n\n\n\n\n
Capability<\/b><\/td>\nWhat It Enables<\/b><\/td>\n<\/tr>\n
FHIR R4 RESTful APIs<\/span><\/td>\nRead, write, search, and update clinical resources<\/span><\/td>\n<\/tr>\n
SMART on FHIR<\/span><\/td>\nOAuth2-based authorisation for third-party app access<\/span><\/td>\n<\/tr>\n
Bulk Data Export ($export)<\/span><\/td>\nPopulation-level data access for analytics and quality reporting<\/span><\/td>\n<\/tr>\n
CDS Hooks<\/span><\/td>\nReal-time clinical decision support embedded in EHR workflows<\/span><\/td>\n<\/tr>\n
Patient Access API<\/span><\/td>\nPatients can access their records via third-party apps<\/span><\/td>\n<\/tr>\n
Provider Directory API<\/span><\/td>\nPublished provider information for care coordination<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The SMART on FHIR authorisation flow:<\/b><\/h3>\n

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.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n
Step<\/b><\/td>\nWhat Happens<\/b><\/td>\n<\/tr>\n
1. App registration<\/span><\/td>\nThird-party app registers with the EHR’s authorisation server<\/span><\/td>\n<\/tr>\n
2. Launch<\/span><\/td>\nApp launches within EHR (EHR launch) or standalone<\/span><\/td>\n<\/tr>\n
3. Authorisation request<\/span><\/td>\nApp requests specific FHIR scopes (patient\/<\/span>.read, user\/<\/span><\/i>.write)<\/span><\/td>\n<\/tr>\n
4. User consent<\/span><\/td>\nClinician or patient approves the requested scopes<\/span><\/td>\n<\/tr>\n
5. Token exchange<\/span><\/td>\nApp receives access token<\/span><\/td>\n<\/tr>\n
6. FHIR API access<\/span><\/td>\nApp calls FHIR APIs with bearer token<\/span><\/td>\n<\/tr>\n
7. Token refresh<\/span><\/td>\nAccess token refreshed using refresh token<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The FHIR search parameters:<\/b><\/h3>\n

Every FHIR resource supports standard search parameters. The EHR must implement these correctly for interoperability:<\/span><\/p>\n\n\n\n\n\n\n\n\n
Resource<\/b><\/td>\nKey Search Parameters<\/b><\/td>\n<\/tr>\n
Patient<\/span><\/td>\nname, birthdate, identifier, gender<\/span><\/td>\n<\/tr>\n
Observation<\/span><\/td>\npatient, code, date, category<\/span><\/td>\n<\/tr>\n
MedicationRequest<\/span><\/td>\npatient, status, medication<\/span><\/td>\n<\/tr>\n
Condition<\/span><\/td>\npatient, code, clinical-status, onset-date<\/span><\/td>\n<\/tr>\n
Encounter<\/span><\/td>\npatient, date, type, status<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Module 3 – ONC Certification Requirements<\/b><\/h2>\n

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.<\/span><\/p>\n

The ONC certification criteria categories:<\/b><\/h3>\n\n\n\n\n\n\n\n\n\n\n
Criterion Category<\/b><\/td>\nExamples<\/b><\/td>\n<\/tr>\n
Clinical<\/span><\/td>\nProblem list, medication list, medication allergy list, demographics, vital signs, smoking status<\/span><\/td>\n<\/tr>\n
Care coordination<\/span><\/td>\nCare plan, referral summary, transitions of care<\/span><\/td>\n<\/tr>\n
Clinical decision support<\/span><\/td>\nDrug-drug interaction checking, drug-allergy checking, relevant care gap reminders<\/span><\/td>\n<\/tr>\n
Electronic prescribing<\/span><\/td>\nEPCS (Electronic Prescribing of Controlled Substances), formulary checks<\/span><\/td>\n<\/tr>\n
Patient access<\/span><\/td>\nView\/download\/transmit, SMART on FHIR API<\/span><\/td>\n<\/tr>\n
Security<\/span><\/td>\nAuthentication, authorisation, audit log, encryption<\/span><\/td>\n<\/tr>\n
Reporting<\/span><\/td>\nQuality measure calculation, QRDA I and III export, FHIR quality reporting<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The certification process:<\/b><\/p>\n

    \n
  1. ONC-Authorised Testing Laboratory (ONC-ATL) tests the EHR against the certification criteria<\/span><\/li>\n
  2. ONC-Authorised Certification Body (ONC-ACB) reviews and grants certification<\/span><\/li>\n
  3. The certified EHR is listed on the ONC Certified Health IT Product List (CHPL)<\/span><\/li>\n<\/ol>\n

    Building for ONC certification from the start (not retrofitting) is the difference between a 6-month certification process and an 18-month one.<\/span><\/p>\n

    Module 4 – Clinical Workflow Modules<\/b><\/h2>\n