Healthcare
Medical Records (EMR/EHR)
Electronic health records — the complete longitudinal clinical history of a patient, from diagnoses and medications to lab results and imaging — now being unified across India through ABDM and the ABHA health ID.
50Cr+
ABHA IDs Created
100%
Public Hospital Target
$5.8B
India Healthcare IT
FHIR R4
India Standard
What Engineers Miss When They First Enter Medical Records (EMR/EHR)
Health records are the only domain where the primary data format — HL7 FHIR — is defined not by a technology company or open-source consortium but by a standards body (HL7 International), and where compliance with that format is legally mandated by government regulation in India through the ABDM framework. Every hospital, clinic, and healthcare platform that participates in ABDM must produce health records in FHIR R4 format, linked to the patient's ABHA ID. The engineering implication is that the data model is not something you design from scratch; you inherit a richly specified standard and implement it correctly — which requires reading a lot of specification documents and understanding the clinical concepts behind the data structures.
The data quality problem in health records is severe. A doctor's handwritten note transcribed by a data entry operator into an EMR retains the ambiguity of the original: 'hypertension' might be entered as 'HT', 'HTN', 'BP high', or 'hypertension' — four strings that a rule-based system treats as four different conditions. Clinical NLP that extracts structured ICD-10 codes from free-text doctor notes is a meaningful ML application in this domain, but it requires training data — annotated clinical notes — that is difficult to acquire because of patient privacy regulations. The quality of India's health data is improving through ABDM's push for structured data capture at source, but a decade's worth of legacy unstructured data remains.
India's ABDM is genuinely interesting as a digital public infrastructure project. The architecture separates the identity layer (ABHA ID — who is this patient?), the consent layer (the PHR app — does this patient consent to share their records with this provider?), and the health records layer (the HIU/HIP interfaces — how do providers read and write records?). This separation means a patient's health records can be stored at any registered HIP (Health Information Provider) and shared with any HIU (Health Information User) with the patient's consent, without any central health record repository. The privacy-preserving design is sophisticated and worth understanding for engineers interested in privacy architecture.
What Teams Actually Do Day To Day
- 1Implement ABDM FHIR R4 resource creation and submission: converting clinical data from the hospital's internal EMR into the FHIR resource types required by ABDM (DiagnosticReport, ImmunizationRecord, OPConsultRecord, DischargeSummary, WellnessRecord, Prescription), submitting them to the ABDM Health Information Provider (HIP) interface, and linking them to the patient's ABHA ID.
- 2Build the clinical documentation module: structured note templates for different encounter types (OPD, IPD, emergency, procedure), clinical decision support rules that alert doctors to drug interactions or abnormal lab values, problem list management with ICD-10 coding, medication ordering with dose range checking, and the lab/imaging result view that integrates results from the LIS/RIS.
- 3Develop the patient longitudinal record view: timeline visualisation of past encounters, diagnoses, medications, immunisations, and lab trends; deduplication logic that merges records from multiple visits that may have used different patient IDs; and the record sharing flow that lets the patient consent to share specific records with a specific provider for a specific time period.
- 4Build the interoperability integration layer: the HIE (Health Information Exchange) connections that allow the hospital's EMR to receive records from other hospitals when a patient presents with prior records from another institution; ABDM Health Information User (HIU) integration for fetching a patient's consented records from other providers; and the mapping layer that converts external records in different EMR formats into the internal clinical model.
- 5Implement clinical NLP and data extraction: processing scanned or typed doctor notes to extract structured clinical entities (diagnoses, medications, procedures, lab values) using NLP models; mapping extracted terms to standard clinical codes (ICD-10, SNOMED, LOINC); and building the training data pipeline that allows models to improve as more annotated clinical text is accumulated.
One End-to-End Flow: A Patient's OPD Visit Creates an ABDM-Linked Health Record
When a patient consults a doctor at an ABDM-integrated hospital, the encounter generates structured FHIR records linked to the patient's ABHA ID — which the patient can later share with any other provider.
Patient registration and ABHA ID verification
The patient presents at the OPD registration desk. The registration staff searches for the patient in the hospital's ADT system and links or creates the ABHA ID using the ABDM API — either scanning the ABHA QR card or entering the 14-digit ABHA number. The patient's demographic data from ABDM is pulled and verified against the hospital's record.
Systems Involved
ADT/hospital registration, ABDM registration APIs, ABHA verification
Where It Usually Breaks
ABHA number lookup failures — due to ABDM API downtime or network issues — result in the patient being registered without an ABHA link. The encounter data cannot be submitted to ABDM later without the link, and manual retroactive linking is a manual process with risk of linking to the wrong ABHA ID.
Doctor documents the encounter in the EMR
The doctor opens the clinical documentation module, reviews the patient's past visit history if available, and documents the current encounter: chief complaint, history of present illness, examination findings, assessment with primary diagnosis (ICD-10 coded), and plan including any medications prescribed and investigations ordered.
Systems Involved
Clinical documentation module, ICD-10 coding, drug database, order entry
Where It Usually Breaks
ICD-10 code selection is often deferred to 'coding staff' who code from the doctor's free-text note after the encounter — introducing a translation step where the coder's interpretation of the note may not match the doctor's intended diagnosis. The resulting code may be wrong or imprecisely specified.
FHIR OPConsultRecord is generated and submitted to ABDM
The EMR generates an ABDM-compliant FHIR OPConsultRecord bundle containing the patient ABHA reference, encounter details, diagnosis codes, medications, and advice. The bundle is submitted to the hospital's HIP (Health Information Provider) interface, which validates the FHIR schema, stores the record, and notifies ABDM of the new record for the patient.
Systems Involved
FHIR bundle generator, ABDM HIP API, schema validator, record store
Where It Usually Breaks
FHIR schema validation errors — from mandatory fields missing, incorrect reference formats, or terminology codes not from the required code system — cause record rejection. Without automated validation in the EMR before submission, these errors are only discovered at the ABDM API boundary and require manual correction.
Patient shares the record with a specialist at a different hospital
The patient visits a cardiologist at a different hospital. The cardiologist requests access to the patient's health records. The patient receives a consent request in their ABDM PHR app (Aarogya Setu or similar), reviews the records being requested, and approves with a time-bound consent for this purpose. The cardiologist's HIU fetches the records via the ABDM framework.
Systems Involved
ABDM consent manager, PHR app notification, HIU record fetch, patient-facing consent UI
Where It Usually Breaks
Patients who do not have the PHR app installed cannot grant consent digitally. Hospitals must have an alternative consent flow (physical consent form) for these patients, but the records retrieved via physical consent are not transmitted through ABDM — the cardiologist receives a paper printout rather than structured digital data.
Technology Architecture — How Medical Records (EMR/EHR) Platforms Are Built
The diagram below reflects how production Medical Records (EMR/EHR) systems are structured at scale — nine layers from client channels through edge security, API gateway, domain microservices, polyglot data stores, async event streaming, analytics, external partners, and cloud infrastructure. Solid arrows show synchronous REST/gRPC calls; dashed arrows show async event flows via Kafka or a message queue.
Industry Players & Real Applications
🇮🇳 Indian Companies
NHA / ABDM
Government Health IT
Java, FHIR, OpenEHR
National Health Authority — operator of India's ABHA, HIE, PHR infrastructure
Practo / Insta
Cloud EMR SaaS
Python, React, FHIR
India's largest cloud EMR/clinic management — ABDM HIP certified
Eka.care
Personal Health Records
React Native, FHIR
ABDM-linked PHR app — patient health wallet
1mg / Tata Health
Health Records + Pharmacy
Python, React, AWS
Health records integrated with teleconsultation and pharmacy
Qure.ai
AI Diagnostics on EHR
Python, TF, DICOM
AI reads chest X-rays, CT scans — needs structured DICOM + EHR data
Narayana Health Digital
Hospital Chain EMR
Custom + FHIR
Building India's largest cardiac EHR dataset — clinical AI
🌍 Global Companies
Epic Systems
USAEMR / EHR Vendor
Cache (MUMPS), Java, FHIR
Dominant US EMR — 70%+ of US hospital beds; MyChart patient portal
Cerner (Oracle Health)
USAEMR / EHR Vendor
Java, .NET, FHIR
Major competitor to Epic — acquired by Oracle 2022; $28B deal
athenahealth
USACloud EMR / RCM
Java, cloud
Cloud-native ambulatory EMR + revenue cycle — strong in US clinics
Google Health (FHIR)
GlobalCloud Health Data Platform
GCP, FHIR APIs
Google Cloud Healthcare API — FHIR server, DICOM, HL7 v2 ingestion
🛠️ Enterprise Platform Vendors
HL7 FHIR R4 (HAPI FHIR)
FHIR Server
Open-source FHIR server — Java-based; used by many Indian EMR vendors for ABDM compliance
Google Cloud Healthcare API
Cloud FHIR
Managed FHIR, DICOM, and HL7 v2 server on GCP — used by hospitals for cloud migration
Microsoft Azure Health Data Services
Cloud FHIR
FHIR + DICOM as managed service on Azure — used by hospital groups on Azure
OpenEHR
EHR Standard
Open clinical knowledge model — archetypes for structured clinical data; used in some national EHR programmes
Core Systems
These are the foundational systems that power Medical Records (EMR/EHR) operations. Understanding these systems — what they do, how they integrate, and their APIs — is essential for anyone working in this domain.
Business Flows
Key Business Flows Every Developer Should Know.Business flows are where domain knowledge directly impacts code quality. Each flow represents a real business process that your code must correctly implement — including all the edge cases, failure modes, and regulatory requirements that aren't obvious from the happy path.
The detailed step-by-step breakdown of each flow — including the exact API calls, data entities, system handoffs, and failure handling — is covered below. Study these carefully. The difference between a developer who “knows the code” and one who “knows the domain” is exactly this: the domain-knowledgeable developer reads a flow and immediately spots the missing error handling, the missing audit log, the missing regulatory check.
Technology Stack
Real Industry Technology Stack — What Medical Records (EMR/EHR) Teams Actually Use. Every technology choice in Medical Records (EMR/EHR)is driven by specific requirements — reliability, compliance, performance, or integration capabilities. Here's what you'll encounter on real projects and, more importantly, why these technologies were chosen.
The pattern across Medical Records (EMR/EHR) is consistent: battle-tested backend frameworks for business logic, relational databases for transactional correctness, message brokers for event-driven workflows, and cloud platforms for infrastructure. Modern Medical Records (EMR/EHR)platforms increasingly adopt containerisation (Docker, Kubernetes), CI/CD pipelines, and observability tools — the same DevOps practices you'd find at any modern tech company, just with stricter compliance requirements.
⚙️ backend
Java / Spring Boot
FHIR server (HAPI FHIR), LIS/RIS middleware, EMR backend APIs
Python
Clinical NLP (extracting diagnoses from notes), AI diagnostics, clinical analytics
Node.js
ABDM integration middleware, real-time notifications (critical lab values, alerts)
MUMPS/Caché (InterSystems)
Legacy backend of Epic Systems — unique language for high-performance health data
🖥️ frontend
React / Angular
Doctor's clinical workstation, EMR portal, lab report dashboards, PACS viewer
React Native / Flutter
ABHA mobile app, patient PHR apps (Eka.care), doctor mobile EMR
OHIF Viewer (open-source)
Web-based DICOM image viewer — open-source, used in many PACS implementations
🗄️ database
PostgreSQL
FHIR resource storage (HAPI FHIR uses PostgreSQL), clinical data
MongoDB
Flexible EMR documents — unstructured clinical notes, questionnaires
FHIR R4 Server (HAPI)
Structured health record storage and exchange — the standard for modern EHR
DICOM Store (Orthanc)
Open-source DICOM server — stores medical images; cloud or on-premise
☁️ cloud
AWS / Azure (ap-south-1)
Health data must reside in India — Mumbai region; HIPAA / DPDP compliant
Google Cloud Healthcare API
Managed FHIR + DICOM server on GCP
ABDM Sandbox / Production
Government's ABDM APIs for ABHA creation, HIE, consent management
Azure Health Data Services
Managed FHIR + DICOM on Azure — integrated with Microsoft Teams health apps
Interview Questions
Q1.Explain the FHIR data model — what are the key resources?
FHIR organises health data into Resources — standardised data models for every clinical concept. Key Resources: Patient: Demographics — name, DOB, gender, address, ABHA ID, contact. Encounter: A patient visit — OPD consultation, ER visit, IPD admission. Condition: Diagnosis — with ICD-10 or SNOMED CT code, onset date, clinical status. Observation: Lab results, vitals — value + unit + LOINC code + status. MedicationRequest: Prescription — drug (RxNorm/drug code), dosage, frequency, prescriber. DiagnosticReport: Lab or radiology report — links to Observations and images. AllergyIntolerance: Patient allergies — substance, severity, reaction type. Procedure: Surgeries, procedures performed. DocumentReference: Links to unstructured documents (PDFs, discharge summaries). ImagingStudy: Links to DICOM images in PACS. Resources link to each other via references: MedicationRequest references Patient, Encounter, and Practitioner. A Bundle is a collection of FHIR resources sent together (e.g., discharge summary Bundle contains Encounter + Conditions + Medications + DiagnosticReports).
Q2.How does ABDM consent management work technically?
ABDM consent ensures patients control who can access their health records. Flow: 1) HIU (e.g., insurance company or new hospital) sends Consent Request to ABDM Gateway specifying: patient ABHA, purpose (CAREMGT/PAYMNT/RESEARCH), data types (DiagnosticReport, Prescription), date range. 2) ABDM Gateway forwards to patient's PHR app (ABHA app, Eka.care). 3) Patient reviews — sees exactly who is requesting, what data, for how long. Approves or denies via OTP/biometric. 4) If approved: ABDM creates signed Consent Artifact (JSON with ABDM's digital signature). Consent Artifact specifies: ConsentId, HIU, HIP list, data types, valid-from, valid-to, expiry. 5) HIU fetches health info using the Consent Artifact. 6) HIP (hospital that has records) receives data request with Consent Artifact. Validates signature. Sends encrypted FHIR data (encrypted with HIU's public key) to ABDM Gateway. 7) HIU decrypts and uses data. Security: End-to-end encrypted. HIP cannot see final recipient. ABDM Gateway cannot see content. Patient can revoke consent at any time. Consent Artifacts are time-limited and purpose-specific.
Q3.How does a LIS integrate with lab analysers?
Lab analysers (Roche Cobas, Abbott Architect, Sysmex XN) communicate with LIS using industry standards: HL7 v2: Most common. Order messages (OML^O21) sent from LIS to analyser. Result messages (OUL^R22) sent back from analyser to LIS. Pipe-delimited messages with MSH, PID, OBR, OBX segments. ASTM E1381/E1394: Older standard — still used by many legacy analysers. Both serial/TCP communication. POCT1-A / FHIR R4: Emerging for point-of-care devices. LIS-Analyser integration points: 1) Order download: LIS sends test orders to analyser — patient ID, test codes. Operator just loads sample. 2) Sample barcode: LIS-generated barcode labels placed on sample tubes. Analyser scans and auto-maps to order. 3) Result upload: Analyser finishes test, transmits results to LIS automatically. 4) QC data: Analyser sends QC results separately — LIS plots Levy-Jennings charts, applies Westgard rules, flags if QC is out-of-control. Delta check: LIS automatically compares current result to patient's previous result. If K+ jumps from 4.0 to 7.5, LIS flags for repeat — likely lab error (haemolysed sample) before reporting to doctor.
Q4.What is DICOM and how do medical images flow from scanner to doctor?
DICOM (Digital Imaging and Communications in Medicine) is the universal standard for medical imaging — defines both the file format and the communication protocol. DICOM file: Contains image pixels + metadata (patient name, MRN, study date, modality, acquisition parameters). Each image = DICOM Instance. Multiple images = Series. Multiple series = Study. Flow: 1) Patient scanned on CT/MRI/X-ray (modality). 2) Modality pushes DICOM study to PACS (Picture Archiving and Communication System) via DICOM C-STORE protocol. 3) PACS stores images in proprietary or standard storage. DICOM Worklist provides the modality with patient demographics (prevents manual entry errors). 4) Radiologist opens worklist on DICOM workstation. Pulls study via DICOM C-MOVE or DICOMweb WADO-RS. 5) AI engine (Qure.ai) also receives DICOM study — analyses chest X-ray for TB, COVID opacity, nodules. Returns findings as DICOM SR (Structured Report) or FHIR ImagingStudy. 6) Radiologist types report (structured or free text) in RIS. Report sent back to HMS/EMR. DICOMweb: Modern REST-based alternative to classic DICOM networking. STOW-RS (store), WADO-RS (retrieve), QIDO-RS (query). Enables web browsers to view DICOM without plugins (OHIF Viewer).
Q5.Design a clinical decision support system for drug-drug interaction checking.
System components: 1) Drug interaction database: Licensed database (DrFirst, Medi-Span, Lexi-Interact) containing millions of drug pair interactions. Each pair has: severity (contraindicated/major/moderate/minor), mechanism, clinical effect, management recommendation. Loaded into a searchable data store (PostgreSQL with RxNorm drug codes). 2) CDS Hooks integration: EMR triggers CDS Hook 'medication-prescribe' every time doctor searches for or selects a drug. Prefetch includes patient's current medication list (active MedicationRequests) and allergies (AllergyIntolerance). 3) Interaction check service: For each new drug × all current medications: O(n) database lookup using drug code pairs. Check new drug × all patient allergies. Dose range check against patient age/weight/renal function (Cr in Observations). 4) Response: Return CDS Cards — each card has: summary, detail, indicator (critical/warning/info), suggestions (alternate drug, dose adjustment), override link (with reason capture). 5) Override management: Doctor overrides are logged with reason. Pharmacy runs independent check as second safety layer. Analytics: Track most common overrides — if 90% of moderate DDI alerts are overridden, consider suppression or re-calibration. Performance: Must respond in < 300ms (within normal EMR response time) — use Redis cache for common drug pairs.
Glossary & Key Terms
FHIR
Fast Healthcare Interoperability Resources — HL7's modern standard for health data exchange via RESTful APIs
EMR
Electronic Medical Record — digital patient record maintained by one healthcare provider
EHR
Electronic Health Record — interoperable patient record shareable across multiple providers
ABHA
Ayushman Bharat Health Account — India's unique 14-digit digital health identifier
HIP
Health Information Provider — hospital or lab that creates and shares health records via ABDM
HIU
Health Information User — entity (hospital, insurer) requesting access to patient records via ABDM
LIS
Lab Information System — manages laboratory workflows, analyser integration, and result reporting
PACS
Picture Archiving and Communication System — stores, retrieves, and distributes DICOM medical images
DICOM
Digital Imaging and Communications in Medicine — standard for medical image storage and exchange
CDS
Clinical Decision Support — intelligent alerts and recommendations for clinicians at point of care
ICD-10
International Classification of Diseases 10th revision — standard diagnosis coding system
LOINC
Logical Observation Identifiers Names and Codes — standard coding for lab tests and observations
SNOMED CT
Systematized Nomenclature of Medicine — comprehensive clinical terminology for diagnoses and findings
DDI
Drug-Drug Interaction — clinically significant interaction between two medications
HL7 v2
Health Level Seven version 2 — older messaging standard for LIS-analyser and system integration
PHR
Personal Health Record — patient-controlled health record stored in health locker (ABHA app)