ABDM Integration Milestones M1 to M4: The Complete Guide for Multi-Software Hospital Environments

India's healthcare digitization is no longer optional. The Ayushman Bharat Digital Mission (ABDM) mandates that every health IT system — from hospital management to diagnostics to pharmacy — must achieve milestone-based certification to participate in the national health data exchange. But here's what most guides miss: real hospitals don't run on a single software.

A typical mid-size hospital runs 4 to 8 separate software systems: HIS for patient management, LIMS for labs, RIS/PACS for radiology, pharmacy management, billing, and more. Each system owns a different slice of the patient's health record. Making all of them work together under ABDM is fundamentally different from integrating a single monolithic EHR.

This guide breaks down every ABDM milestone in detail, explains what happens at each stage, and addresses the real-world challenge of multi-software, multi-facility integration — the scenario every integrator and hospital IT team actually faces.

Understanding the ABDM Milestone Framework

ABDM certification is structured into progressive milestones. Each builds on the previous one, adding new capabilities and responsibilities:

Milestone	Your Role	Core Capability	Certification Focus
M1	Identity Provider	ABHA creation, verification, patient discovery	Can your system identify patients digitally?
M2	HIP (Health Information Provider)	Share health records on patient consent	Can you serve FHIR records when asked?
M3	HIU (Health Information User)	Fetch and consume records from other providers	Can you request and display external records?
M4	Claims Participant	NHCX — digital insurance claims exchange	Can you process claims digitally?

Certification is per-software, not per-facility. You certify your software once through NHA's sandbox exit process, then each facility registers independently in the Health Facility Registry (HFR).

ABDM V3 APIs — The Current Standard

Before diving into the milestones, a critical technical point: ABDM V3 APIs are the current standard. NHA's official ABDM Wrapper and all new integrations use V3 exclusively. The older v0.5 and v1.0 APIs are legacy — all new development must target V3.

V3 Gateway base URLs:

• Sandbox: https://dev.abdm.gov.in/api/hiecm/gateway/v3/ with header X-CM-ID: sbx
• Production: Same gateway path with header X-CM-ID: abdm

Key V3 changes from legacy APIs:

• Discovery is synchronous: In V3, when ABDM sends a patient discovery request, your system returns the response directly in the HTTP body — no more async callback-based discovery
• Linking token at profile share: V3 provides a linking token at the time of scan-and-share (profile share). Your HRP must save this token and use it for HIP-initiated linking — eliminating the separate OTP-based linking flow
• Unified gateway endpoints: Authentication, bridge registration, and service management all live under the /v3/ path
• Simplified bridge management: PATCH /v3/bridge/url for registration, GET /v3/bridge-services to verify your configuration

V3 authentication:

curl -X POST 'https://dev.abdm.gov.in/api/hiecm/gateway/v3/sessions' \
  -H 'Content-Type: application/json' \
  -H 'X-CM-ID: sbx' \
  -d '{
    "clientId": "your-client-id",
    "clientSecret": "your-client-secret",
    "grantType": "client_credentials"
  }'

Every Client ID maps to one software instance and one callback URL. The gateway session token is passed in the Authorization header for all subsequent API calls.

Milestone 1 (M1) — ABHA and the Identity Layer

What Happens

M1 is the foundation. Your system must be able to create, verify, and link patient identities using ABHA (Ayushman Bharat Health Account) — the 14-digit unique health identifier for every Indian citizen.

The core flows in M1:

• ABHA Creation — Create a new ABHA number via Aadhaar OTP, mobile OTP, or demographic methods
• ABHA Verification — Verify an existing ABHA number presented by a patient at registration
• QR Scan & Share — Patient scans the facility's QR code, and their ABHA profile is auto-shared to your system via the V3 profile share API. In V3, this also provides a linking token that your system must save for subsequent HIP-initiated linking
• Care Context Linking — Link the patient's visit (consultation, admission, lab test) — called a "care context" — to their ABHA. In V3, use the linking token received during profile share for HIP-initiated linking, removing the need for separate OTP-based flows
• Health Facility Registry (HFR) — Register your facility with a valid HFR ID, which becomes your HIP ID in the ABDM network

Key V3 APIs for M1

• ABHA creation and verification APIs (Aadhaar OTP, mobile OTP flows)
• V3 Share Profile API — receives patient profile + linking token during QR scan
• V3 Link Token API — HIP-initiated linking using the saved linking token
• V3 Discovery (synchronous) — respond to patient discovery requests in the HTTP response body

M1 Challenges

• Aadhaar consent management: Many patients don't have Aadhaar-linked mobile numbers, forcing fallback to demographic-based creation which has strict matching rules
• Care context definition: What constitutes a "care context"? An OPD visit? A lab order? An admission episode? This decision must be consistent across your system
• Linking token lifecycle: The linking token provided during V3 profile share must be persisted reliably. If lost, HIP-initiated linking fails and you must fall back to user-initiated discovery — a worse user experience
• QR provisioning: The facility QR code must be correctly provisioned in HFR — misconfiguration breaks the entire scan-and-share flow

M1 in a Multi-Software Environment

Here's where it gets interesting. In a hospital running HIS + LIMS + RIS separately:

• Which system creates the ABHA? Typically the HIS (front desk registration). But the LIMS and RIS also need the ABHA number to link their care contexts
• ABHA and linking token propagation: When HIS receives the ABHA profile and linking token during scan-and-share, it must broadcast both to all downstream systems (LIMS, RIS, pharmacy). If they don't share a patient master, you need an integration layer that stores and distributes the linking token
• Care contexts from different systems: An OPD visit is a care context from HIS. A lab report is a care context from LIMS. A radiology study is a care context from RIS. All must be linked to the same ABHA. The ABDM gateway sees them all coming from one HIP ID — your middleware must aggregate them

Milestone 2 (M2) — HIP: Sharing Health Records

What Happens

M2 is where your system becomes a Health Information Provider (HIP). When a patient or another authorized system requests health records through ABDM, you must serve them — encrypted, in FHIR R4 format, on demand.

The complete M2 data flow:

1. Patient grants consent via ABHA app or an HIU application
2. ABDM sends consent notification to your HIP via your registered bridge URL
3. You acknowledge the consent notification
4. ABDM sends health information request with the consent artefact — this includes: consent ID, date range, the requester's encryption public key, a nonce, and a data push URL
5. You validate the consent artefact (check expiry, scope, purpose)
6. You fetch all matching care contexts from the specified date range
7. You convert to FHIR R4 bundles conforming to NRCeS (National Resource Centre for EHR Standards) profiles
8. You encrypt using Fidelius (Elliptic Curve Diffie-Hellman key exchange)
9. You push encrypted data to the provided data push URL

FHIR Bundle Types You Must Produce

Bundle Type	Source System	Content
OPConsultNote	HIS / EMR	Outpatient consultation notes, vitals, diagnosis
DischargeSummary	HIS / EMR	Inpatient discharge details, procedures, follow-up
DiagnosticReport	LIMS	Lab results — CBC, lipid panel, cultures, etc.
Prescription	EMR / Pharmacy	Medication orders, dosage, frequency
ImagingStudy	RIS / PACS	Radiology reports, imaging metadata
ImmunizationRecord	HIS	Vaccination history
WellnessRecord	Wellness apps	Vitals, activity, lifestyle data
HealthDocumentRecord	Any	Catch-all for scanned documents, PDFs

M2 Challenges

• FHIR conversion is the hardest part: Your internal database schema (SQL tables with custom column names) must be mapped to HL7 FHIR R4 bundles conforming to NRCeS profiles. Every field, every coding system (SNOMED CT, LOINC, ICD-10) must be correct. This is not a weekend project
• Fidelius encryption: ABDM uses ECDH (Elliptic Curve Diffie-Hellman) for end-to-end encryption. You generate a key pair, encrypt the FHIR bundle using the requester's public key + your private key + nonces. Getting any parameter wrong means the transfer fails silently
• Bridge URL reachability: Your bridge URL is the single entry point that ABDM's gateway calls. It must be publicly accessible over HTTPS. Network issues, firewall rules, or DNS misconfigurations silently break the entire flow
• Consent expiry: Consents have TTLs. You must validate before serving data — serving data on an expired consent is a compliance violation
• One Client ID, one bridge URL: Each Client ID maps to exactly one callback URL. For multi-facility setups, all callbacks arrive at one URL — your middleware must route internally

M2 in a Multi-Software Environment — The Real Challenge

This is where most integrations either succeed or collapse. When ABDM sends a data request, you need to aggregate records from multiple independent systems:

Problem 1: Each System Has Its Own Data Model

Your HIS stores consultations in one schema, your LIMS stores lab results in a completely different schema, and your RIS stores radiology in yet another format. Each needs its own FHIR converter:

// Middleware receives ABDM health information request
func handleDataRequest(consentArtefact ConsentArtefact) {
    dateRange := consentArtefact.DateRange
    patientABHA := consentArtefact.PatientABHA

    // Query EACH system for its care contexts
    opdNotes := hisClient.GetConsultations(patientABHA, dateRange)
    labReports := limsClient.GetReports(patientABHA, dateRange)
    radStudies := risClient.GetStudies(patientABHA, dateRange)
    prescriptions := pharmacyClient.GetOrders(patientABHA, dateRange)

    // Convert each to FHIR using system-specific converters
    bundles := []FHIRBundle{}
    bundles = append(bundles, convertHISToFHIR(opdNotes)...)
    bundles = append(bundles, convertLIMSToFHIR(labReports)...)
    bundles = append(bundles, convertRISToFHIR(radStudies)...)
    bundles = append(bundles, convertPharmacyToFHIR(prescriptions)...)

    // Encrypt all bundles and push
    encrypted := fideliusEncrypt(bundles, consentArtefact.PublicKey)
    pushToHIU(encrypted, consentArtefact.DataPushURL)
}

Problem 2: Patient Identity Mapping Across Systems

Your HIS knows the patient as MRN-12345. Your LIMS knows them as LAB-67890. Your RIS knows them as RAD-11111. When ABDM sends a request with an ABHA number, your middleware must know which patient ID to query in each system.

Solution: Maintain a centralized patient master index that maps ABHA → HIS MRN → LIMS ID → RIS ID → Pharmacy ID. This is the single most critical data structure in your integration layer.

Problem 3: Care Context Registration

Every time a care context is created in ANY system (new OPD visit in HIS, new lab report in LIMS, new radiology study in RIS), it must be registered with ABDM against the patient's ABHA. Your middleware needs event listeners on every system:

• HIS creates a consultation → middleware registers care context with ABDM
• LIMS finalizes a lab report → middleware registers care context
• RIS completes a study → middleware registers care context

If any system fails to notify the middleware, that care context becomes invisible to ABDM — the patient's records are incomplete.

Problem 4: Discovery Across Systems

When ABDM sends a V3 discovery request, your middleware must synchronously query ALL systems, aggregate all care contexts for that patient, and return a unified response in the HTTP body. There is no async callback — you must respond within the request timeout:

{
  "patient": { "referenceNumber": "ABHA-1234" },
  "careContexts": [
    { "referenceNumber": "OPD-2024-001", "display": "OPD Visit - 15 Jan 2025" },
    { "referenceNumber": "LAB-2024-045", "display": "Blood Work - 15 Jan 2025" },
    { "referenceNumber": "RAD-2024-012", "display": "Chest X-Ray - 16 Jan 2025" },
    { "referenceNumber": "RX-2024-078", "display": "Prescription - 15 Jan 2025" }
  ]
}

Each care context reference must be traceable back to the originating system so the middleware knows where to fetch the actual data during a health information request. The synchronous nature of V3 discovery makes this more demanding — you need all systems to respond fast or risk timeouts.

Milestone 3 (M3) — HIU: Consuming External Records

What Happens

In M3, your system flips roles. Instead of only serving records, you can now request and consume records from other HIPs in the ABDM network. A doctor in your hospital can pull a patient's records from their previous hospital.

The M3 flow:

1. Doctor initiates consent request — your system creates a consent request via the ABDM gateway
2. Patient approves in the ABHA app (this step is outside your control)
3. ABDM notifies you with the consent artefact via your bridge URL callback
4. You request health information from the gateway, providing your public key and nonce
5. Remote HIP encrypts and pushes data via ABDM to your data transfer endpoint
6. You decrypt using your private key + sender's public key (Fidelius decryption)
7. You parse FHIR bundles and display to the doctor

M3 Challenges

• Key management: Each consent request needs a fresh key pair. Store private keys securely (HSM or Vault) until data arrives, then decrypt. Poor key management equals data breaches
• FHIR parsing from heterogeneous sources: Every HIP produces slightly different FHIR bundles. Some are perfectly structured, some barely conform. Your parser must be resilient to variation
• Consent UX: The patient must approve consent in the ABHA app. If they don't, you wait indefinitely. Build proper timeout handling, status polling, and user feedback into the doctor-facing UI
• Data normalization: Records from 10 hospitals use different coding systems and levels of detail. Presenting this coherently to a doctor is a significant UX challenge

M3 in a Multi-Software Environment

When external records arrive, which system should display them?

• Lab reports from another hospital — should they appear in your LIMS? Or in a unified patient view in the HIS?
• Radiology studies from outside — your RIS may not have a viewer for their FHIR format
• The practical answer: build a unified patient health record viewer in the HIS that aggregates both internal records (from your LIMS, RIS, pharmacy) and external records (from ABDM HIU fetch). Don't try to inject external records into each subsystem — it creates more problems than it solves

Milestone 4 (M4) — NHCX: Digital Claims Exchange

What Happens

M4 introduces the National Health Claims Exchange (NHCX) — a standardized, FHIR-based framework for digital insurance claims processing. This is the emerging frontier, gaining momentum as PMJAY (Pradhan Mantri Jan Arogya Yojana) and private insurers adopt digital-first claims.

Key flows:

• Coverage Eligibility: Check if a patient is covered before treatment begins
• Pre-Authorization: Request approval for a planned procedure from the insurer
• Claim Submission: Submit the claim with supporting clinical documents as FHIR bundles
• Payment Notification: Receive payment status and explanation of benefits (EOB)

M4 in a Multi-Software / Multi-Facility Environment

• Each facility may be empaneled under different insurance schemes (PMJAY, state schemes, private insurers)
• Claims data spans systems: the diagnosis comes from HIS, the lab evidence from LIMS, the procedure details from the surgical module
• Your claims submission module must aggregate from all systems into a single FHIR ClaimBundle

The Multi-Facility Dimension

Beyond multiple software systems, hospitals often have multiple physical locations. A hospital group with 3-10 branches faces additional challenges:

Architecture Decisions

Decision	Option A	Option B	Recommendation
Database	Shared multi-tenant DB	Separate DB per facility	Shared with tenant isolation — simpler ops
Bridge URL	One for all facilities	One per facility	One bridge, route by HIP ID — single point of management
FHIR converter	Single converter	Per-facility converter	Single with facility-aware configuration
Key management	Shared key store	Per-facility keys	Centralized Vault with per-facility key paths
Patient dedup	Allow duplicates	Merge across facilities	Merge — critical for unified patient view

Critical Multi-Facility Challenges

1. Every facility needs its own HFR registration and HIP ID. Five branches means five HIP IDs. The QR code for scan-and-share is per-facility, not per-organization
2. Single bridge URL receives ALL callbacks. Since each Client ID maps to one bridge URL, your router must parse the hip.id from each ABDM request and route to the correct facility's handler. Use GET /v3/bridge-services to verify all facilities are correctly registered under your bridge
3. Patient deduplication across facilities. Same patient visits Facility A and B — your system must recognize it's the same person and merge care contexts. Without this, discovery returns incomplete results
4. Consent artefacts can span facilities. A consent may request data from a date range covering visits at multiple of YOUR facilities. You must aggregate across facility databases
5. Linking token per facility. In V3, the linking token from scan-and-share is specific to the facility where the patient scanned. If they visit another of your facilities, a new scan-and-share generates a new linking token for that facility's HIP ID

The Complete Picture: Multi-Software + Multi-Facility

The hardest real-world scenario — and the most common one — is a hospital group with multiple facilities, each running multiple software systems from different vendors. Here's what the integration architecture looks like:

ABDM V3 Gateway (NHA)
       │
       ▼
┌──────────────────────────────────────┐
│  ABDM Integration Middleware         │
│  (Single Bridge URL per Client ID)   │
│                                      │
│  ┌───────────┐  ┌────────────────┐   │
│  │ HIP ID    │  │ FHIR Converter │   │
│  │ Router    │  │ Registry       │   │
│  └─────┬─────┘  └───────┬────────┘   │
│        │                │            │
│  ┌─────▼────────────────▼──────┐     │
│  │  Patient Master Index       │     │
│  │  ABHA → System IDs mapping  │     │
│  │  + Linking Token Store      │     │
│  └─────────────────────────────┘     │
└──────────┬───────────────────────────┘
           │
    ┌──────┼──────────┐
    ▼      ▼          ▼
Facility A  Facility B  Facility C
(HIP: X)   (HIP: Y)    (HIP: Z)
┌────────┐ ┌────────┐ ┌────────┐
│HIS     │ │HIS     │ │HIS     │
│LIMS    │ │LIMS    │ │LIMS    │
│RIS/PACS│ │Pharmacy│ │RIS     │
│Pharmacy│ │        │ │Billing │
└────────┘ └────────┘ └────────┘

The middleware is the linchpin. It must:

• Route ABDM callbacks to the correct facility based on HIP ID
• Respond synchronously to V3 discovery requests by querying all systems within the target facility in parallel
• Store linking tokens per patient per facility, received during V3 profile share
• Aggregate care contexts from all systems within a facility
• Convert each system's data to FHIR using system-specific converters
• Merge patient identities across facilities and systems via the centralized patient master
• Handle Fidelius encryption, key pair management, and consent validation centrally
• Monitor every system's availability — if LIMS is down, serve what you can and flag partial data

What an Integrator Must Think About

If you are building ABDM middleware for hospitals (as a product or service), these are your critical considerations:

Concern	Detail
Multi-tenancy	Each customer is a different organization with their own Client ID and HIP IDs. Your middleware must be fully tenant-isolated
Pluggable FHIR converters	Each customer's HIS/LIMS/RIS has a different schema. Your FHIR converter must be configurable per system type and per vendor, not hardcoded
Onboarding automation	Each new customer means new HFR registrations, V3 bridge URL configuration, Client ID provisioning, key setup, and system connector configuration
Synchronous discovery performance	V3 discovery is synchronous — you must query multiple backend systems and return aggregated results within the HTTP timeout. Invest in caching, parallel queries, and fallback strategies
Callback reliability	ABDM's consent and data flow callbacks need guaranteed delivery. Use message queues and retry logic — a dropped callback means a failed consent flow
Certification scope	You certify your software once, but each customer's deployment must pass a security assessment (STQC/CERT-IN empaneled agency)
Linking token persistence	V3 linking tokens must be reliably stored per patient per facility. Token loss means linking failure, which blocks care context creation
Monitoring and alerting	Build dashboards for: consent request success rate, FHIR bundle generation failures, encryption errors, discovery response times, linking token hit rate. When something breaks at 2 AM, you need to know which system at which facility failed

The Sandbox to Production Journey

The certification path is structured but rigorous:

1. Sandbox integration: Register with the V3 sandbox (X-CM-ID: sbx), implement all APIs, test against the ABDM sandbox environment
2. Functional testing: NHA's internal team tests your flows against standardized patient journey scenarios
3. Security assessment: A STQC/CERT-IN empaneled agency performs OWASP-10 web application security audit and issues a "Safe-to-Host" certificate
4. Final approval: NHA grants production access — you switch X-CM-ID from sbx to abdm and use production Client ID/Secret
5. HFR registration: Register each physical facility in the production HFR, verify with GET /v3/bridge-services

Key insight: Certification is per-software. But deployment — HFR registration, bridge URL setup, patient data seeding — is per-facility. For a multi-facility group, step 5 is repeated for every branch.

How Nirmitee Approaches ABDM Integration

At Nirmitee, we have built production ABDM integration across all milestones using V3 APIs. Our approach addresses the multi-software reality head-on:

• Middleware-first architecture: A single integration layer that sits between the ABDM V3 gateway and any combination of hospital software systems. Connect your HIS, LIMS, RIS, pharmacy — whatever you run
• Pluggable FHIR converters: System-specific adapters that map your existing data to NRCeS-compliant FHIR R4 bundles without requiring changes to your source systems
• Centralized patient master with linking token store: ABHA-to-system-ID mapping across all connected systems and facilities, with reliable V3 linking token persistence
• Multi-facility routing: Single bridge URL with intelligent routing by HIP ID, handling synchronous discovery aggregation and consent spanning across facilities
• Performance-optimized discovery: Parallel querying of backend systems to meet V3's synchronous discovery requirements within timeout constraints

Whether you're a hospital group looking to achieve ABDM compliance across branches, or a health-tech company building ABDM-certified software, the multi-software integration challenge is the one that matters most. Talk to our team about getting it right the first time.