| name | abdm-fhir |
| description | Build and parse ABDM-compliant FHIR R4 bundles - Eka's resource mappings (Observation, Condition, MedicationRequest, ServiceRequest, AllergyIntolerance, CarePlan, etc.), hi_type document bundles, base64 encoding for the Link API, and parsing incoming HIU data. Use when the user mentions FHIR, bundles, "map my data to ABDM format", hi_type, SNOMED/LOINC coding, or is handling hip_data_fetch / hiu_data_push payloads. |
FHIR for ABDM Connect
ABDM exchanges health data as FHIR R4 document bundles conforming to NRCES India profiles (https://nrces.in/ndhm/fhir/r4/). Each care context's data is one bundle whose type matches its hi_type.
hi_type → bundle composition
| hi_type | Composition (typical resources) |
|---|
| OPConsultation | Composition + Patient, Practitioner, Encounter, Observation (symptoms/vitals/exam), Condition (diagnoses), MedicationRequest, ServiceRequest, CarePlan, Appointment (follow-up) |
| Prescription | Composition + MedicationRequest(s), Patient, Practitioner |
| DiagnosticReport | Composition + DiagnosticReport, Observation results, optionally Binary/DocumentReference (PDF) |
| DischargeSummary | Composition + Condition, Procedure, MedicationRequest, CarePlan |
| ImmunizationRecord | Composition + Immunization |
| HealthDocumentRecord | Composition + DocumentReference (any PDF/scan, base64 inside) |
| WellnessRecord | Composition + Observation (vital-signs) |
Eka's field-level mappings (memorize the pattern, fetch the page for detail)
Full table: /api-reference/health-ai/ekascribe/FHIR/Eka-FHIR-structure.md; a 3000-line worked bundle: .../fhir-bundle-example.md. Summary:
| Client data | FHIR resource | Key discriminator |
|---|
| Symptoms | Observation | category: signs-and-symptoms (SNOMED 418799008) |
| Vitals | Observation | category: vital-signs; multi-value via component (e.g. BP) |
| Examinations | Observation | category: exam |
| Diagnoses | Condition | category: encounter-diagnosis |
| Medical history | Condition | category: problem-list-item |
| Medications | MedicationRequest | intent: order; dosage in dosageInstruction (timing repeat: frequency/period/periodUnit); dispense qty = freq × duration × dose |
| Lab/imaging/surgery orders | ServiceRequest | category: lab_test / imaging / surgical_procedure; codes from LOINC/SNOMED/eka.care/mdb |
| Allergies | AllergyIntolerance | category: food / medication; clinicalStatus active |
| Advice | CarePlan | intent: plan |
| Clinical notes | CarePlan | intent: proposal |
| Follow-up | Appointment | appointmentType: FOLLOWUP, status proposed |
| Family history | FamilyMemberHistory | — |
Coding systems: SNOMED CT (http://snomed.info/sct) preferred; LOINC for labs; Eka MDB (http://eka.care/mdb) and https://parchi.eka.care/local as fallbacks. Uncoded text is allowed via CodeableConcept.text but weakens interoperability — code what you can.
Building a bundle (HIP direction)
- Interrogate the client's schema (visits, prescriptions, results tables) and map each entity per the table above. Present the mapping to the user for confirmation before generating code.
- Bundle rules:
Bundle.type = document; first entry is Composition referencing every other resource; every resource needs a stable fullUrl (urn:uuid); Patient must carry the ABHA address as an identifier; timestamps ISO 8601.
- Serialize → base64 →
data field of the Link API (or on-fetch push).
- Validate before shipping: run the bundle through the HL7 FHIR validator (
java -jar validator_cli.jar bundle.json -version 4.0.1 -ig https://nrces.in/ndhm/fhir/r4) or at minimum schema-validate with a FHIR R4 library in the client's language (fhir.resources for Python, HAPI for Java, @types/fhir + fhir-validator for Node, etc.).
Parsing a bundle (HIU direction)
Decrypt (ECDH, see care-contexts/ecdh-encryption.md) → parse Bundle → index resources by resourceType → walk Composition.section for document structure → map into the client's model (inverse of the table). Be defensive: HIP bundles vary in quality; never assume optional fields; handle DocumentReference-only bundles (embedded PDFs).
Test before done
Round-trip: build → validate → base64 → decode → parse → compare. Validate one bundle per enabled hi_type against NRCES profiles.
