Interoperability & Standards: How the Pieces Talk to Each Other

This is Part 2 of a three-part series on the Ayushman Bharat Digital Mission (ABDM). Part 1 covered what ABDM is and what it means for doctors, administrators, and software providers. This part goes under the hood: how interoperability actually works, and what the M1–M4 certification milestones and terminology standards require. Part 3 covers certification, accredited partners, and the full ecosystem walkthrough.

How Interoperability Actually Works

ABDM's interoperability model is built around a few key roles, all connected through a central Gateway:

• HIP (Health Information Provider) — a hospital, lab, or clinic that creates health records (e.g., where a patient got a blood test).
• HIU (Health Information User) — a hospital or doctor that wants to view a patient's existing records (e.g., a specialist reviewing history from another hospital).
• Consent Manager — manages patient consent for every single data request. No HIU can pull records without the patient explicitly approving that request, commonly via a PHR app.
• Gateway — the central routing service connecting HIPs and HIUs, enforcing that consent is honored on every exchange.

Two more pieces make this actually work end to end:

• ABHA ID — the common key every record is linked to. Without it, a HIP and HIU would have no reliable way to agree they're talking about the same patient. ABHA is what lets a lab result created in one hospital's system be correctly matched to the same person's record request from a completely different hospital's system, years later.
• ABDM-certified software — the technical translator. Being an HIP or HIU isn't a status a hospital declares; it's a capability that only exists if the software running at that hospital has passed M1/M2/M3 certification and correctly implements the FHIR data format and consent protocol. Two hospitals can only exchange records if both sides are running certified software speaking the same standardized language — uncertified software simply cannot participate in the exchange.

This means health data doesn't sit in one central government database — it stays with the hospital that created it, and is only shared, record-by-record, with the patient's active consent. That's the core design principle: federated storage, centralized consent-based discovery.

The Software Provider's Role in Making This Work

None of the HIP, HIU, or Gateway roles above are things a hospital does manually — they're technical capabilities built into whatever HMIS/EHR software the hospital runs. This is exactly where an ABDM-accredited software provider sits: they are the ones who actually implement the HIP and HIU functionality inside the hospital's software, so the hospital itself doesn't have to build any of this from scratch.

• Acting as the technical bridge — the software's ABHA creation screen, FHIR record packaging, and consent-request handling are all built and maintained by the accredited vendor, not the hospital's IT staff.
• Keeping pace with ABDM's evolving API versions and FHIR profiles, so the hospital stays compliant without needing to track NHA's technical updates itself.
• Carrying the certification burden — since ABDM certification is per-software, the accredited vendor absorbs the sandbox testing, WASA audit, and NHA review process once, and every hospital using that software inherits the compliance.
• Enabling multi-hospital interoperability — a single accredited vendor's software, deployed across many hospitals, means those hospitals can exchange records with each other (and with hospitals on entirely different accredited software) through the same Gateway, because both sides speak the same certified FHIR/consent protocol.

In practice, this is why the accreditation question matters so much for a hospital choosing software: an accredited provider isn't just “compliant” in an abstract sense — it's the entity actively operating your hospital's HIP/HIU connection to the entire national network, every single day.

M1, M2, M3 — Explained Simply

Milestone 1 (M1) — Identity

Your software becomes capable of creating and verifying ABHA IDs during patient registration (using Aadhaar or mobile number), and can look up existing patients by their ABHA. This is the foundation — before anything else can happen, a patient needs a verified digital identity.

Official test cases (ABDM sandbox documentation) that certify this milestone include:

• CRT_ABHA_101 / 102 — the system must offer ABHA creation via Aadhaar OTP and must collect the patient's consent before doing so.
• CRT_ABHA_113 — the system must display the created 14-digit ABHA Number to the user.
• VRFY_ABHA_101 — the system must allow ABHA verification using the ABHA Number/Address plus an Aadhaar-linked OTP.

Milestone 2 (M2) — Health Information Provider (HIP)

Your software becomes a Health Information Provider. It can package clinical documents (prescriptions, discharge summaries, lab reports) into standardized HL7 FHIR R4 format and make them available for sharing, linked to the patient's ABHA.

Official test cases include:

• HEALTH_RECORD_CREATION_101 — the system must be able to create digital health records, recommended in FHIR format.
•  HIP_INTI_LINK_201/203/205 — the system must link a patient's health record to their ABHA address via mobile OTP: send the OTP, validate it, then complete the link.
• HIP_INIT_GRANT_CONSENT — the HIP must save a granted consent request against the patient's ABHA address in its own system.
• HIP_INIT_SHARE_CARECONTEXT — the HIP must verify a valid consent exists, encrypt the requested health records with the HIU's public key, and complete the transfer within 2 hours of the request.

Why FHIR Alone Isn't Enough — The Terminology Standards Inside the Bundle

FHIR defines the container — the structure of a digital health record so any system can parse it. But a correctly structured record is still meaningless across systems unless the medical concepts inside it are described using the same vocabulary. That's what these three standards do, each bundled inside the FHIR resource for a different kind of clinical data:

• SNOMED CT — the clinical terminology for diagnoses, symptoms, procedures, and findings. When a doctor's note says “type 2 diabetes mellitus,” SNOMED CT gives that phrase a single, unambiguous code, so a receiving system doesn't have to guess whether “diabetes,” “DM2,” and “type 2 diabetes” from three different hospitals all mean the same condition.
• ICD-10/11 — the classification standard mainly used for diagnosis coding tied to billing, insurance claims, and epidemiological reporting. Where SNOMED CT captures clinical nuance for care, ICD-10/11 is what feeds structured diagnosis codes into insurance claims (relevant to NHCX/M4) and national disease-burden statistics.
• LOINC — the standard specifically for laboratory and clinical observations. Every lab test result (a blood glucose reading, an HbA1c value, a hemoglobin count) gets a LOINC code, so a lab report from one hospital's system is read the same way by any other hospital's system — this is exactly what the M2 test case HIP_INTI_LINK/HEALTH_RECORD_CREATION requirements are built to support in practice.

Put together: a single FHIR-bundled discharge summary might use SNOMED CT to code the diagnosis, LOINC to code the lab values that supported it, and ICD-10/11 to code it for the insurance claim — three different standards, each doing a specific job, inside one interoperable FHIR document. This is also why, when evaluating an HMIS vendor, asking “is it FHIR-compliant” is necessary but not sufficient — the more precise question is whether it correctly maps clinical data to SNOMED CT, ICD-10/11, and LOINC within those FHIR bundles, since that's what determines whether the data is actually usable by the system receiving it.

Milestone 3 (M3) — Health Information User (HIU)

Your software becomes a Health Information User, completing the loop. It can send a consent request through a Consent Manager, and — once the patient approves — fetch and display a patient's health records from other providers in the network.'

Official test cases include:

• HIU_FLOW_101/102 — the system must find a patient using their ABHA Number/Address, then let the HIU create a consent request specifying purpose, duration, and the type of health information needed.
• HIU_FLOW_105/106 — the HIU must not fetch data for a denied consent request, and must fetch it once the request is approved.
• HIU_FLOW_202 — the HIU must lose access to records the moment the patient revokes consent.
• HIU_FLOW_301 — the HIU must not be able to view health data once a consent request has expired.

(A fourth milestone, M4, extends this further into NHCX — the National Health Claims Exchange — for digital insurance claim processing. It's increasingly discussed alongside M1–M3 but is a separate, newer extension focused specifically on cashless insurance workflows.)

M4 — Claims Exchange

Milestone 4 (M4) enables NHCX — the National Health Claims Exchange — allowing certified software to process cashless insurance claims digitally, alongside consent-based data exchange. It's the milestone most closely tied to schemes like AB-PMJAY, where claim approval speed directly affects hospital cash flow.

PHR Apps — A Separate Certification Track

Personal Health Record (PHR) apps — the patient-facing apps (like the ABHA app or other empaneled PHR apps) that let citizens view records, manage consent, and use Scan and Register — are generally documented as following their own certification track, separate from the M1–M4 milestones built for hospital-side HIP/HIU software. A PHR app typically needs to implement both HIP-like behavior (storing records a patient uploads themselves) and HIU-like behavior (fetching records from other providers on the patient's behalf), plus its own consent-dashboard and security requirements.

Health Locker

The Health Locker is ABDM's secure cloud storage layer for a patient's health records — prescriptions, lab reports, discharge summaries, imaging — linked to their ABHA. Key features:

• Facility-uploaded, patient-controlled — integrated hospitals and labs upload records with patient consent; the patient decides who else can access them afterward.
• Strong encryption at rest — records are expected to be secured with strong encryption (commonly cited as AES-256 or equivalent) to protect sensitive health data in storage.
• Long-term, portable storage — unlike a single hospital's local records system, the Health Locker persists across hospital visits, providers, and even years, giving a patient one place their full history accumulates.
• Accessible through any PHR app — a patient isn't locked into one vendor's app; any ABDM-empaneled PHR app can be used to view and share what's stored in their Health Locker.

In practice, the Health Locker is what makes the promise of “one health ID, lifelong records” actually durable — it's the storage layer underneath ABHA, while HIP/HIU/Gateway are the exchange layer that moves data in and out of it.

Part 3 of this series covers what it actually takes to get a software certified against these milestones, who the accredited partners are, and walks through the full ecosystem with a real hospital scenario.

Dr. Sri VidhyaBhavani M is a Provisionally Accredited NABH Digital Health Standards (DHS) Digital MITRA  |  PhD (HMIS), IIT Madras, empanelled to assess and guide healthcare facilities toward NABH Digital Health accreditation. She is the Founder & Director of Destratum Solutions Pvt Ltd, and creator of Health Attai™, an ABDM-compliant school health platform.

Sources: National Health Authority (ABDM) official documentation and sandbox program; ABDM Sandbox test case documentation (Milestones 1–3, sandbox.abdm.gov.in / community-maintained mirror); publicly available ABDM integration guides current as of 2026. This is Part 2 of a three-part series — see Part 1 for the ABDM overview and Part 3 for certification, partners, and the full ecosystem walkthrough.