Medical Records (EMR/EHR)

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).

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.

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.

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).

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.