ABDM FHIR Bundle Examples: One Patient Journey from Hospital Visit to Health Record (2026)

In an ABDM-connected hospital, every step of a patient's visit produces an ABDM FHIR bundle: registration creates the Patient resource, the OPD visit an OPConsultation bundle, the lab a DiagnosticReport bundle, the pharmacy a Prescription bundle and billing an Invoice bundle. The hospital links the visit to the patient's ABHA as a care context, and when the patient consents, the bundles are encrypted and shared with the doctor or app that asked for them. If these bundles are your starting point, our FHIR developer learning path provides a broader route into implementation.

This is Part 2 of our ABDM FHIR bundles series. Part 1 covered the fundamentals: FHIR resources, document bundles, the Composition, NRCeS profiles and the 8 health information types. Here we follow one fictional patient, Priya, through a hospital visit and look inside every ABDM FHIR bundle her visit creates, with JSON examples checked against the NRCeS implementation guide, version 6.5.0. Updated September 2026.

The patient journey in short: which bundle each step creates

Building this into your hospital software? Our ABDM integration services team maps your HMIS data to these bundles and takes it through M2 certification.

The whole journey as a swimlane flowchart

The flowchart shows who does what: the patient, the hospital's software as Health Information Provider (HIP), the ABDM gateway, and the specialist's system as Health Information User (HIU).

Steps 1-2: Reception creates the Patient resource every bundle reuses

At reception, staff verify Priya's ABHA, either by scanning the QR on her ABHA card or through Scan and Share, where she scans the hospital's QR and shares her profile. Her ABHA number and demographics become a Patient resource that every bundle from this visit references.

{
  "resourceType": "Patient",
  "id": "pat-0001",
  "meta": { "profile": ["https://nrces.in/ndhm/fhir/r4/StructureDefinition/Patient"] },
  "identifier": [{
    "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR", "display": "Medical record number" }] },
    "system": "https://healthid.ndhm.gov.in",
    "value": "91-XXXX-XXXX-XXXX"
  }],
  "name": [{ "text": "Priya Sharma" }],
  "gender": "female",
  "birthDate": "1992-03-15",
  "telecom": [{ "system": "phone", "value": "+91-9XXXXXXXXX", "use": "home" }]
}

• The identifier system https://healthid.ndhm.gov.in marks the value as an ABHA number; the NRCeS example uses the same pattern.
• Always include birthDate and name; PHR apps show missing fields as N/A.
• The hospital becomes an Organization (with its HFR ID where available) and the doctor a Practitioner. Patient, Practitioner and Organization appear in every bundle.

Step 3: The OPConsultation bundle from the OPD visit

Priya sees the doctor for fever and headache. The doctor records her complaints and vitals, notes a penicillin allergy, orders tests, prescribes medicines and books a follow-up. Closing the visit creates an OPConsultation bundle, the most common ABDM record.

The Composition uses the OPConsultRecord profile and SNOMED CT 371530004 (Clinical consultation report), with an Encounter of class AMB (ambulatory). The OPConsultRecord profile in NRCeS 6.5.0 defines 12 optional sections; you fill the ones the visit produced.

// Inside Composition.section[]
{
  "title": "Chief complaints",
  "code": { "coding": [{ "system": "http://snomed.info/sct", "code": "422843007", "display": "Chief complaint section" }] },
  "entry": [{ "reference": "urn:uuid:cond-0001" }]
}

// The referenced Condition
{
  "resourceType": "Condition",
  "id": "cond-0001",
  "meta": { "profile": ["https://nrces.in/ndhm/fhir/r4/StructureDefinition/Condition"] },
  "code": {
    "coding": [{ "system": "http://snomed.info/sct", "code": "386661006", "display": "Fever" }],
    "text": "Fever and headache for 3 days"
  },
  "subject": { "reference": "urn:uuid:pat-0001" }
}

The OP consultation example in the NRCeS guide carries 15 entries: the Composition, Patient, Practitioner, Organization, Encounter, AllergyIntolerance, Appointment, three Conditions, Procedure, ServiceRequest, MedicationStatement, MedicationRequest and a DocumentReference.

Step 4: The DiagnosticReport bundle with LOINC-coded lab results

The lab runs a lipid profile. When the report is signed, the lab system creates a DiagnosticReport bundle: one DiagnosticReport that points to one Observation per test parameter, each coded in LOINC.

{
  "resourceType": "DiagnosticReport",
  "id": "dr-0001",
  "meta": { "profile": ["https://nrces.in/ndhm/fhir/r4/StructureDefinition/DiagnosticReportLab"] },
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "24331-1", "display": "Lipid 1996 panel - Serum or Plasma" }] },
  "subject": { "reference": "urn:uuid:pat-0001" },
  "result": [
    { "reference": "urn:uuid:obs-chol-0001" },
    { "reference": "urn:uuid:obs-trig-0001" },
    { "reference": "urn:uuid:obs-hdl-0001" }
  ],
  "conclusion": "Lipid profile within reference ranges"
}

{
  "resourceType": "Observation",
  "id": "obs-chol-0001",
  "meta": { "profile": ["https://nrces.in/ndhm/fhir/r4/StructureDefinition/Observation"] },
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma" }] },
  "subject": { "reference": "urn:uuid:pat-0001" },
  "valueQuantity": { "value": 195, "unit": "mg/dL", "system": "http://unitsofmeasure.org", "code": "mg/dL" },
  "referenceRange": [{ "high": { "value": 200, "unit": "mg/dL" }, "text": "Desirable: below 200 mg/dL" }]
}

• One Observation per parameter, each with its own LOINC code and UCUM unit, so the receiving system can chart and compare results.
• A Specimen resource describes the sample, and the ServiceRequest links the result back to the order from the OPD visit.
• Reference ranges let the receiver flag abnormal values without a human reading the PDF.

Step 5: The Prescription bundle, one MedicationRequest per medicine

Priya collects her medicines. The Prescription bundle holds one MedicationRequest for each medicine prescribed, plus a Binary resource if the hospital attaches a scanned or signed copy. It grows with the number of medicines.

{
  "resourceType": "MedicationRequest",
  "id": "mr-0001",
  "meta": { "profile": ["https://nrces.in/ndhm/fhir/r4/StructureDefinition/MedicationRequest"] },
  "status": "active",
  "intent": "order",
  "medicationCodeableConcept": {
    "coding": [{ "system": "http://snomed.info/sct", "code": "387517004", "display": "Paracetamol" }],
    "text": "Paracetamol 500 mg tablet"
  },
  "subject": { "reference": "urn:uuid:pat-0001" },
  "authoredOn": "2026-09-28",
  "requester": { "reference": "urn:uuid:prac-0001" },
  "reasonCode": [{ "coding": [{ "system": "http://snomed.info/sct", "code": "386661006", "display": "Fever" }] }],
  "dosageInstruction": [{
    "text": "1 tablet twice a day after food for 5 days",
    "timing": { "repeat": { "frequency": 2, "period": 1, "periodUnit": "d" } },
    "route": { "coding": [{ "system": "http://snomed.info/sct", "code": "26643006", "display": "Oral route" }] }
  }]
}

Send the dosage text as well as the structured timing; it is what the patient reads in the app. The Composition uses PrescriptionRecord and SNOMED CT 440545006 (Prescription record).

Step 6: The Invoice bundle from billing

At the billing counter the hospital raises an Invoice bundle: an Invoice with a ChargeItem for each line (consultation, tests, medicines) and, for pharmacy items, the Medication. In the NRCeS 6.5.0 example the Invoice Composition is typed by text ("Invoice Record") rather than a SNOMED code. The record gives the patient a complete financial trail for the visit.

The other ABDM FHIR bundle types: discharge, wellness, immunization, documents

Priya's outpatient visit produced four of the eight health information types. The other four cover inpatient stays, wellness data, vaccines and any other document.

DischargeSummary: the richest ABDM record

If Priya were admitted, her discharge would create a DischargeSummary bundle with SNOMED CT 373942005 and an Encounter of class IMP (inpatient) whose period holds the admission and discharge dates. The DischargeSummaryRecord profile defines 10 optional sections, from chief complaints and investigations to procedures, medications and the care plan, and the bundle often carries more than one practitioner and organization.

WellnessRecord: vitals, body measurements and lifestyle

The WellnessRecord is the most observation-heavy bundle: the NRCeS example carries 19 Observations, each using a specific Observation profile (vital signs, body measurement, physical activity, general assessment, women's health, lifestyle). Blood pressure is a single panel observation (LOINC 85354-9) with systolic and diastolic components. Lifestyle uses LOINC 81663-7 for diet type and SNOMED CT 365981007 for tobacco smoking behavior. The Composition is typed by text ("Wellness Record") in the example.

ImmunizationRecord and HealthDocumentRecord

An ImmunizationRecord (SNOMED CT 41000179103) holds an Immunization (vaccine, lot number, dose number, date) and an ImmunizationRecommendation for the next dose, with an optional DocumentReference for the certificate. A HealthDocumentRecord (SNOMED CT 419891008, Record artifact) wraps any document that fits no other type, such as a scanned report or referral letter, in a DocumentReference.

Step 7: Care context linking puts the bundles on the patient's ABHA

After the visit, the hospital links it to Priya's ABHA as a care context, for example "OPD visit, 28 September 2026". This is the M2 (HIP) linking flow: generate a link token for the patient, then call /api/hiecm/hip/v3/link/carecontext with the visit reference. Link one care context per call; batched links lost records in our production experience.

When a specialist later asks for Priya's records:

1. The specialist's system (HIU) raises a consent request.
2. Priya approves it in her PHR app, choosing the record types and date range.
3. ABDM notifies the hospital of the granted consent, then sends a health information request.
4. The hospital builds the bundles for the consented care contexts and HI types and encrypts each with Fidelius encryption (ECDH key agreement and AES-GCM).
5. Each entry is pushed to the requester's data push URL with its media type, the care context reference and an MD5 checksum of the encrypted content, and the hospital tells ABDM the transfer is complete.
6. The specialist's system decrypts and displays the records.

The full HIP design is in building an ABDM HIP from scratch, and the end-to-end integration path in our ABDM integration step-by-step guide.

Step 8: What the patient sees

Priya opens her PHR app and sees the visit's records by date and type: the consultation notes and diagnosis, lab results with reference ranges, medicines with dosage, and the bill. She can share them with a new doctor through the consent flow and revoke access at any time. How good that view looks depends entirely on the bundles: missing names, dates or dosage text appear as N/A. Our guide to fixing N/A fields lists the fields apps rely on.

ABDM FHIR bundle pitfalls we fixed in real projects

• Composition first. Receivers and validators expect the Composition as entry[0].
• A profile on every resource. Declare the NRCeS profile in meta.profile for each resource, and DocumentBundle on the bundle.
• urn:uuid references. Inside a document bundle, never use relative references like Patient/123.
• The right Composition type. OPConsultation is 371530004, Prescription 440545006, DiagnosticReport 721981007, DischargeSummary 373942005.
• Encounter class. AMB for outpatient records, IMP for discharge summaries.
• Codes, not free text. LOINC for observations, SNOMED CT for clinical terms, always with display text.
• Checksum on the encrypted content. The checksum in the data push is an MD5 of the encrypted entry content; compute it after encryption.
• Time zones. Use ISO 8601 with +05:30, for example 2026-09-28T10:30:00+05:30.

From our delivery work

These are the bundles we build inside hospital software for M2 and read back for M3. In a live test against the ABDM sandbox in September 2026, every value in every test record arrived intact at the requesting side: 526 of 526 values and 30 of 30 attachments. The official standards for ABDM FHIR records are the NRCeS FHIR implementation guide and its profiles, value sets and example bundles. For working samples of each type, see our public ABDM FHIR bundle examples and the example bundles in the NRCeS implementation guide.

Mapping your HMIS to ABDM FHIR bundles? Our ABDM integration team builds the mapping, validation and data push, and FHIR integration services cover everything beyond ABDM. Talk to our team for a review of your bundles.