Understanding ABDM FHIR Bundles — A Complete Guide from Zero to Expert

If you are integrating with India's Ayushman Bharat Digital Mission (ABDM), you have probably encountered the term "FHIR Bundle" — and then landed on the NRCES Implementation Guide, which can feel overwhelming. This guide changes that. We will take you from zero FHIR knowledge to complete mastery of ABDM FHIR bundles — step by step, with clear explanations and visual diagrams.

By the end of this two-part series, you will understand exactly what goes inside every ABDM health record, why each piece exists, and how they all fit together. This is Part 1 — the fundamentals. Part 2 walks you through a real patient journey, showing every bundle type in action.

What is FHIR? Healthcare's Universal Data Language

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a global standard created by HL7 International for exchanging healthcare data electronically. Think of it as the JSON of healthcare — a structured, predictable way to represent medical information that any system can understand.

Before FHIR, healthcare systems spoke different languages. A hospital management system stored patient data one way, a lab system another way, and an insurance system yet another. Sharing data between them required expensive, custom integrations. FHIR solves this by defining a common set of Resources — standardized building blocks for every type of healthcare data.

Here are some of the most common FHIR R4 resources you will encounter in ABDM:

Each resource has a defined structure. For example, a Patient resource always has fields for name, gender, date of birth, and identifiers. An Observation resource always has a code (what was measured), a value (the result), and a reference to the patient. This predictability is what makes interoperability possible.

Key FHIR concepts to understand:

• Resources — The fundamental building blocks. Everything in FHIR is a Resource: patients, observations, conditions, medications, encounters, and more.
• References — Resources point to each other. An Observation references the Patient it belongs to. A MedicationRequest references the Practitioner who prescribed it.
• Profiles — Constraints applied to base resources for specific use cases. India's NRCES profiles define exactly which fields are required for ABDM.
• Coding Systems — Standardized vocabularies like SNOMED CT (for clinical terms), LOINC (for lab tests), and ICD-10 (for diagnoses).
• Version R4 — The current stable release, and the version ABDM uses. Released in 2019, it is the most widely adopted FHIR version globally.

India chose FHIR R4 as the foundation for ABDM because it is modern, widely adopted, and designed for exactly the kind of large-scale health data exchange that a country of 1.4 billion people needs.

What is a FHIR Bundle? Packaging Resources Together

In real healthcare, a single clinical event — like a doctor's visit — produces multiple pieces of data: the patient's identity, the doctor's notes, vital signs, a diagnosis, prescribed medications, and follow-up instructions. Each of these is a separate FHIR resource. But they need to travel together as one package.

That is exactly what a FHIR Bundle does. It is a container resource that groups multiple related resources into a single, self-contained package. Think of it like a sealed envelope: you put multiple documents inside, seal it, and send it as one unit.

FHIR defines several types of bundles:

For ABDM, the Document Bundle (type: "document") is the primary type. Every health record — whether it is a prescription, a lab report, or a discharge summary — is packaged as a Document Bundle.

A Document Bundle has a specific structure that every ABDM implementation must follow:

{
  "resourceType": "Bundle",
  "id": "unique-bundle-id",
  "meta": {
    "versionId": "1",
    "profile": [
      "https://nrces.in/ndhm/fhir/r4/StructureDefinition/DocumentBundle"
    ],
    "security": [
      { "code": "V", "display": "very restricted" }
    ]
  },
  "identifier": {
    "system": "http://hip.in",
    "value": "unique-identifier"
  },
  "type": "document",
  "timestamp": "2026-04-02T10:30:00+05:30",
  "entry": [
    { "resource": { "resourceType": "Composition", "..." : "..." } },
    { "resource": { "resourceType": "Patient", "..." : "..." } },
    { "resource": { "resourceType": "Practitioner", "..." : "..." } }
  ]
}

Every Document Bundle must have:

• meta.profile — pointing to the NRCES DocumentBundle Structure Definition
• identifier — a globally unique ID for this bundle
• type — always "document" for clinical records
• timestamp — when the bundle was created (ISO 8601 format)
• entry[] — the array of resources, with Composition always as the first entry

The ABDM Ecosystem — Where Bundles Fit In

Before diving deeper into bundle structures, let us understand the ecosystem these bundles operate in. ABDM (Ayushman Bharat Digital Mission) is India's national digital health infrastructure, designed to create a unified health record system for every citizen.

The key actors in the ABDM ecosystem:

• ABHA (Ayushman Bharat Health Account) — Every patient gets a 14-digit health ID (like 91-7345-1816-0779). This is their unique identity across all healthcare providers in India. Think of it as a health-specific Aadhaar.
• HIP (Health Information Provider) — Any entity that creates health records: hospitals, clinics, diagnostic labs, pharmacies. When you visit a hospital, that hospital is the HIP. HIPs create FHIR bundles and link them to your ABHA.
• HIU (Health Information User) — Any entity that needs to access health records: a specialist you are referred to, an insurance company processing a claim, or a PHR (Personal Health Record) app. HIUs request data through consent.
• ABDM Gateway — The central routing layer that connects HIPs and HIUs. It does not store health data — it only facilitates the exchange. All communication between HIPs and HIUs flows through the gateway.
• Consent Manager — The patient is always in control. Before any health data is shared, the patient must explicitly grant consent — specifying what data, for how long, and for what purpose. This is managed through the ABHA app or consent manager.

Here is how FHIR bundles flow through this ecosystem:

1. Patient visits a hospital (HIP)
2. Hospital creates FHIR bundles for the visit (OPConsultation, Prescription, Lab Report, etc.)
3. Hospital links these records to the patient's ABHA via the ABDM Gateway
4. When another provider (HIU) needs the records, they send a consent request
5. Patient approves or denies the consent request
6. If approved, the FHIR bundles are encrypted and transferred from HIP to HIU via the gateway

The FHIR bundle is the actual health data that moves through this pipeline. Everything else — ABHA registration, consent management, linking — is infrastructure to ensure that this data is shared securely and with the patient's permission.

The Composition Resource — Every Bundle's Table of Contents

The most important resource inside a Document Bundle is the Composition. It must always be the first entry in the bundle, and it acts as a table of contents — describing what the document is, who it is about, and what sections it contains.

Think of the Composition like the first page of a medical chart: it tells you the patient's name, the doctor who wrote it, the date, the type of document, and a list of everything inside. Each section in the Composition references the actual clinical resources that contain the data.

Here is what a Composition resource looks like in an ABDM bundle:

{
  "resourceType": "Composition",
  "id": "comp-uuid-001",
  "meta": {
    "profile": [
      "https://nrces.in/ndhm/fhir/r4/StructureDefinition/OPConsultRecord"
    ]
  },
  "status": "final",
  "type": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "371530004",
        "display": "Clinical consultation report"
      }
    ]
  },
  "subject": {
    "reference": "urn:uuid:patient-001",
    "display": "Priya Sharma"
  },
  "date": "2026-04-02T10:30:00+05:30",
  "author": [
    {
      "reference": "urn:uuid:practitioner-001",
      "display": "Dr. Anjali Mehta"
    }
  ],
  "title": "OP Consultation Record",
  "custodian": {
    "reference": "urn:uuid:org-001",
    "display": "City General Hospital"
  },
  "section": [
    {
      "title": "Chief Complaints",
      "code": {
        "coding": [
          {
            "system": "http://snomed.info/sct",
            "code": "422843007",
            "display": "Chief complaint section"
          }
        ]
      },
      "entry": [
        {
          "reference": "urn:uuid:condition-001",
          "display": "Fever and headache"
        }
      ]
    }
  ]
}

Key fields in every Composition:

• meta.profile — The NRCES Composition profile (different for each HI type: OPConsultRecord, PrescriptionRecord, DiagnosticReportRecord, etc.)
• type.coding — A SNOMED CT code identifying the document type (e.g., 371530004 for "Clinical consultation report")
• subject — Reference to the Patient resource
• author — Reference to the Practitioner who created the document
• custodian — Reference to the Organization (hospital/clinic)
• section[] — The heart of the Composition. Each section has a title, a SNOMED code, and entry references pointing to the actual clinical resources

The urn:uuid: reference format is critical. Inside a bundle, resources do not have server-assigned URLs — they reference each other using UUID-based URNs. Every reference includes a display text for human readability.

NRCES Profiles — How India Customizes FHIR for ABDM

Base FHIR R4 is intentionally flexible — it is designed to work for any healthcare system globally. But India's ABDM has specific requirements: patients need ABHA identifiers, facilities need Health Facility Registry (HFR) IDs, and clinical records need specific sections. This is where NRCES profiles come in.

NRCES (National Resource Centre for EHR Standards) publishes India's FHIR Implementation Guide — currently at version 6.5.0. This IG defines:

• Structure Definitions — Constrained versions of FHIR resources. For example, the NRCES Patient profile requires the ABHA number as an identifier with the system https://healthid.ndhm.gov.in.
• Composition Profiles — One for each Health Information type. OPConsultRecord defines which sections an OPD consultation must have. PrescriptionRecord defines prescription sections. Each profile URL follows the pattern: https://nrces.in/ndhm/fhir/r4/StructureDefinition/{ProfileName}
• Value Sets — Approved coding systems. NRCES mandates SNOMED CT for clinical terminology and LOINC for observations and lab results.
• Identifier Systems — Standardized systems for Indian identifiers:
  • https://healthid.ndhm.gov.in — for ABHA numbers
  • https://doctor.ndhm.gov.in — for practitioner registration
  • https://facility.ndhm.gov.in — for HFR facility IDs

Every resource in an ABDM bundle must declare its NRCES profile in the meta.profile field. This tells receiving systems exactly which validation rules apply. Here are the profiles you will use most often:

All profile URLs follow the base: https://nrces.in/ndhm/fhir/r4/StructureDefinition/

The 8 ABDM Health Information Types

ABDM supports 8 types of health information, each packaged as a Document Bundle with its own Composition profile. Understanding these types is essential for any ABDM integration — they define what clinical data your system needs to produce and consume.

1. OPConsultation — Outpatient Visit Records

Generated when a patient visits a doctor's clinic or hospital OPD. This is the most common bundle type — every OPD visit produces one. Contains 8 sections covering chief complaints, allergies, medical history, medications, procedures, investigations, follow-up, and attached documents. Uses SNOMED code 371530004 (Clinical consultation report). Typically contains 13 resources.

2. Prescription — Medication Orders

Generated when a doctor prescribes medications. Contains one MedicationRequest per drug, each with dosage, frequency, and duration. Can also include a Binary resource for scanned prescription copies. Uses SNOMED code 440545006 (Prescription record). The bundle size is dynamic — it grows with the number of medications prescribed.

3. DiagnosticReport — Lab and Imaging Results

Generated when lab results are available. Contains a DiagnosticReport resource linked to multiple Observations (one per test parameter, each with LOINC codes), a Specimen resource, and a ServiceRequest. Uses SNOMED code 721981007 (Diagnostic studies report). Often includes two Practitioners — the ordering doctor and the lab pathologist.

4. DischargeSummary — Hospital Discharge Documentation

Generated when a patient is discharged from inpatient care. This is the most complex bundle type with 7 Composition sections: chief complaints, medical history, investigations, procedures, medications, care plan, and documents. Uses SNOMED code 373942005 (Discharge summary). Typically contains 15+ resources including multiple Practitioners and Organizations. The Encounter resource uses class "IMP" (inpatient) with admit and discharge dates.

5. HealthDocumentRecord — General Clinical Documents

The simplest bundle type. Used for any clinical document that does not fit the other types — scanned reports, clinical notes, PDF documents. Contains primarily a DocumentReference with base64-encoded content. Uses SNOMED code 419891008 (Record artifact). Typically only 5 resources.

6. WellnessRecord — Vitals, Fitness, and Lifestyle Data

The most observation-heavy bundle. Contains 18+ LOINC-coded Observations organized into 6 categories: Vital Signs (respiratory rate, heart rate, SpO2, temperature, blood pressure), Body Measurement (height, weight, BMI), Physical Activity (steps, calories burned, sleep), General Assessment (body fat, blood glucose, fluid intake, calorie intake), Lifestyle (diet, smoking status), and Documents. Uses SNOMED code 118228005 (Functional finding). Each observation uses a specific NRCES Observation profile (ObservationVitalSigns, ObservationBodyMeasurement, etc.).

7. Immunization Record — Vaccination Records

Generated when a vaccination is administered. Contains an Immunization resource (vaccine name, lot number, dose number, date) and an ImmunizationRecommendation resource (next dose date and number). Uses SNOMED code 41000179103 (Immunization record). Typically 7 resources — one of the simpler bundle types.

8. Invoice — Billing Records

Generated for billing and payment documentation. Contains Invoice resources with line items, pricing, and tax details. Uses SNOMED code 52471005 (Invoice). Used to link financial records to a patient's ABHA for insurance claims and payment tracking.

What is Next — Part 2: The Patient Journey

Now that you understand the building blocks — FHIR resources, Document Bundles, Composition as the table of contents, NRCES profiles, and all 8 Health Information types — you are ready to see them in action.

In Part 2: ABDM FHIR Bundles in Action, we follow a patient named Priya Sharma through a complete hospital visit — from reception to viewing her records on the ABHA app. Each clinical step generates a specific FHIR bundle, and we will look inside each one with annotated JSON examples showing every resource and reference.

You will see exactly how an OPConsultation bundle is structured after a doctor's visit, how a DiagnosticReport bundle captures lab results, how a Prescription bundle lists medications, and how all these bundles flow through the ABDM ecosystem to land on the patient's ABHA app.

Need expert help with healthcare data integration? Explore our Healthcare Interoperability Solutions to see how we connect systems seamlessly. We also offer specialized Custom Healthcare Software Development services. Talk to our team to get started.