ABDM Milestones M1, M2, M3 and M4 Explained: The 2026 Guide for Hospital Software

The ABDM milestones are the three integration stages NHA defines for health software: M1 creates and verifies ABHA (the patient's health ID), M2 makes your system a Health Information Provider (HIP) that shares records with consent, and M3 makes it a Health Information User (HIU) that fetches records from others. "M4" is not an ABDM milestone; the label is commonly used for NHCX, the National Health Claims Exchange, a separate claims track that needs M1 first. You need at least two milestones to exit the ABDM sandbox and get production credentials.

This guide explains each milestone in depth: what NHA expects, the V3 APIs involved, the challenges that stall teams, and what changes when a hospital runs several software systems (HIS, LIMS, RIS, pharmacy) or several facilities. For a hands-on developer walkthrough from sandbox login to go-live, see our ABDM integration step-by-step guide. Updated September 2026.

Who this guide is for: HMIS, LIMS and RIS vendors building toward ABDM certification; hospital IT teams planning a multi-software integration; health-tech startups adding ABDM to an existing product; and integrators managing sandbox-to-production deployments.

The ABDM milestone framework: M1, M2, M3 and "M4" at a glance

In NHA's official terms, Milestone 1 is ABHA onboarding, Milestone 2 is health record linking and sharing as a HIP, and Milestone 3 is consent-driven data sharing as a HIU. Each milestone is built and validated in the sandbox before production. ABDM also works at two levels: the policy level (NHA's rules, registries such as HFR and HPR, and the consent framework) and the technology level (the gateway, the V3 APIs used by NHA's official ABDM wrapper, and the FHIR standards your software implements).

If you want help deciding or building, our ABDM integration services team takes HMIS and health-tech products through M1, M2 and M3 and the sandbox exit.

What decides how long each ABDM milestone takes

Timelines depend less on the APIs than on four things: how your software handles asynchronous callbacks, how clean your clinical data is, how many systems hold patient records, and how quickly you move through NHA's testing queue. This table shows where the time goes for each milestone.

ABDM V3 APIs: the current standard and what changed

All new ABDM integrations use the V3 APIs; the older v0.5 and v1 flows are legacy. Our ABDM V3 migration guide covers every change. The points that matter for milestone planning:

• Gateway session token. Get it from /gateway/v0.5/sessions with your client ID and secret, and send it as Authorization on every call. Sandbox calls also carry X-CM-ID: sbx; production uses X-CM-ID: abdm.
• Bridge URL. Register it with PATCH /api/hiecm/gateway/v3/bridge/url and check it with GET /api/hiecm/gateway/v3/bridge-services. One client ID has one bridge URL, and updates took 5 to 15 minutes to apply in our testing.
• Asynchronous by default. Discovery, linking, consent and data requests return 202 and deliver the real answer to a callback (on-discover, on-init, on-confirm, on-notify). Your handlers must acknowledge at once and do the work in the background.
• Two-step ABHA login. /v3/profile/login/verify returns a T-token and the account list; /v3/profile/login/verify/user returns the X-token that profile, card and QR calls need.
• Request IDs must match. On on-* callbacks, the request ID in the body must equal the one in the header.

# Gateway session token (sandbox). Production gateway: https://apis.abdm.gov.in/api/hiecm
curl -s -X POST 'https://dev.abdm.gov.in/gateway/v0.5/sessions' \
  -H 'Content-Type: application/json' \
  -d '{"clientId":"<your-client-id>","clientSecret":"<your-client-secret>"}'

Milestone 1 (M1): ABHA and the identity layer

What happens in ABDM M1

M1 is the foundation. Your software creates, verifies and uses ABHA, the 14-digit Ayushman Bharat Health Account number, and the patient's ABHA address.

• ABHA creation with Aadhaar OTP or mobile OTP, including a second OTP when the communication mobile differs from the Aadhaar-linked one, and ABHA address suggestions.
• ABHA verification by ABHA number, ABHA address, mobile or Aadhaar, using the two-step login.
• ABHA card and QR for the patient to download.
• Scan and Share: the patient scans the facility's QR, their profile arrives at your bridge URL, and you register or match them and return a token number.
• HFR registration: each facility's Health Facility Registry ID becomes its HIP ID in the ABDM network.

Key V3 APIs for M1

• Enrolment: /v3/enrollment/request/otp, /v3/enrollment/enrol/byAadhaar, /v3/enrollment/enrol/suggestion
• Login and profile: /v3/profile/login/request/otp, /v3/profile/login/verify, /v3/profile/login/verify/user
• Card and QR: /v3/profile/account/abha-card (send no Accept header), /v3/profile/account/qrCode
• Scan and Share: the profile share callback on your bridge URL, acknowledged through /patient-share/v3/on-share

ABDM M1 challenges

• Aadhaar and mobile mismatches: many patients' Aadhaar-linked mobile is not the phone they carry, so the second OTP path must work smoothly.
• Test-sheet UI rules: NHA's M1 test cases check details such as inline validation messages instead of alert boxes and masked mobile numbers in OTP messages.
• Token order: using the T-token where the X-token is needed is the most common M1 bug we see in reviews.
• QR provisioning: the facility QR must be tied to the right HFR and HIP ID, or Scan and Share never reaches your system.

M1 in a multi-software environment

In a hospital running HIS, LIMS and RIS separately, decide which system owns ABHA. It is usually the HIS at the front desk. The LIMS and RIS still need the ABHA to link their own records, so either they share a patient master or an integration layer stores and distributes ABHA numbers. An OPD visit (HIS), a lab report (LIMS) and a radiology study (RIS) are all care contexts for the same ABHA, and ABDM sees them all under one HIP ID.

Milestone 2 (M2): HIP, sharing health records

What happens in ABDM M2

In M2 your software becomes a Health Information Provider: records created in your system can be discovered, linked and shared with the patient's consent, encrypted and in FHIR R4.

1. Link care contexts. Generate a link token with /api/hiecm/v3/token/generate-token (it arrives on your callback) and link each visit with /api/hiecm/hip/v3/link/carecontext, one care context per call.
2. Answer discovery. When a patient searches for records in a PHR app, ABDM calls your discover endpoint; reply through on-discover with the matching care contexts.
3. Handle link init and confirm with an OTP to the patient.
4. Receive the consent notification, store it and acknowledge through consent/v3/request/hip/on-notify.
5. Receive the health information request with the consent ID, date range, the requester's public key, a nonce and a data push URL. Acknowledge it.
6. Validate the consent (expiry, scope, purpose) and fetch the matching care contexts.
7. Convert to FHIR R4 bundles that follow NRCeS profiles, encrypt with Fidelius (ECDH key agreement and AES-GCM), push to the data push URL and notify ABDM that the transfer is complete.

FHIR bundle types you must produce

Our ABDM FHIR bundles guide explains each profile, and why FHIR bundles show NA in PHR apps covers the most common rendering failures.

ABDM M2 challenges

• FHIR conversion is the hardest part. Your database fields must map to NRCeS profiles with correct SNOMED CT, LOINC and ICD-10 coding.
• Fidelius encryption. A wrong curve, key format or nonce means the requester cannot decrypt, and the failure is often silent. See our Fidelius encryption guide.
• Bridge URL reachability. It must be public HTTPS. Firewalls, DNS and sleeping tunnels break the whole flow, and ABDM does not resend a lost consent notification. Our callback debugging guide lists the checks.
• Consent expiry. Validate every consent before serving data.
• One client ID, one bridge URL. In multi-facility setups every callback arrives at one URL and your layer must route it.

M2 in a multi-software environment: the real challenge

This is where integrations succeed or stall. When ABDM asks for records, you must gather them from several independent systems. For hospitals under AB-PMJAY, the stakes and deadlines are in our ABDM compliance guide for AB-PMJAY hospitals.

Problem 1: each system has its own data model. The HIS, LIMS and RIS each need their own FHIR converter:

// Integration layer: handle an ABDM health information request
func handleDataRequest(req HealthInfoRequest) {
    ackToABDM(req.RequestID) // acknowledge first, then work in the background
    go func() {
        opd := hisClient.GetConsultations(req.PatientRef, req.DateRange)
        labs := limsClient.GetReports(req.PatientRef, req.DateRange)
        rad := risClient.GetStudies(req.PatientRef, req.DateRange)
        rx := pharmacyClient.GetOrders(req.PatientRef, req.DateRange)

        bundles := append(convertHIS(opd), convertLIMS(labs)...)
        bundles = append(bundles, convertRIS(rad)...)
        bundles = append(bundles, convertPharmacy(rx)...)

        encrypted := fideliusEncrypt(bundles, req.KeyMaterial)
        pushToRequester(encrypted, req.DataPushURL)
        notifyTransferred(req) // data-flow/v3/health-information/notify
    }()
}

Problem 2: patient identity across systems. The HIS knows the patient as MRN-12345, the LIMS as LAB-67890, the RIS as RAD-11111. Keep a central patient master index mapping ABHA to every system's ID. It is the most important data structure in the integration layer.

Problem 3: care context registration. Every new record in any system (an OPD visit, a finalised lab report, a completed study) must be linked to the ABHA. The integration layer needs events from every system; a system that never tells it about a record makes that record invisible to ABDM.

Problem 4: discovery across systems. When a patient discovers records from a PHR app, your layer must query every system, collect the care contexts for that patient and reply through on-discover. The request is acknowledged immediately and answered asynchronously, but the patient is waiting in the app, so query systems in parallel and keep the answer fast. Each care context reference must trace back to its source system so the data can be fetched later.

{
  "patient": {
    "referenceNumber": "HMS-PAT-000123",
    "careContexts": [
      { "referenceNumber": "OPD-2026-001", "display": "OPD visit, 15 Jan 2026" },
      { "referenceNumber": "LAB-2026-045", "display": "Blood work, 15 Jan 2026" },
      { "referenceNumber": "RAD-2026-012", "display": "Chest X-ray, 16 Jan 2026" }
    ]
  }
}

Milestone 3 (M3): HIU, consuming external records

What happens in ABDM M3

In M3 your software asks for records held by other HIPs, so a doctor can see a patient's history from another hospital.

1. The doctor starts a consent request (consent/v3/request/init).
2. The patient approves in their ABHA or PHR app.
3. ABDM notifies you on on-notify: granted, denied, revoked or expired.
4. You fetch the consent artefact and request the data with a fresh Fidelius public key, a nonce and your data push URL, using the granted date range exactly.
5. Remote HIPs push encrypted bundles to your data push URL.
6. You decrypt, parse and show the records, and purge them with their keys when the consent is revoked or expires.

ABDM M3 challenges and M3 compliance

• Key management: a fresh key pair per request, private keys stored securely until data arrives, deleted with the data.
• Parsing varied FHIR: every HIP's bundles differ slightly; the parser must tolerate that.
• Consent UX: the patient may never approve. Build timeouts, status checks and clear messages for the doctor.
• M3 compliance: keeping records after revocation or expiry is one of the most common certification failures. Purge the data and the keys.

M3 in a multi-software environment

External records should appear in one unified patient record viewer in the HIS, next to internal records, rather than being injected into the LIMS or RIS. Our HIU reference architecture shows the design.

Milestone 4 (M4): what "ABDM M4" really means (NHCX claims)

What happens in "M4"

When people say "ABDM M4" they almost always mean the National Health Claims Exchange (NHCX), the FHIR-based exchange for insurance claims between hospitals, insurers and TPAs. It is not an ABDM milestone: it has its own sandbox (hcxsbx.abdm.gov.in), its own participant registration, its own profiles and its own testing. It is linked to ABDM in two ways: NHCX reuses your ABDM client ID, and a provider needs ABDM M1 in production before it can go live on NHCX.

The four core NHCX flows:

• Coverage eligibility: confirm the policy is active and what it covers before treatment.
• Pre-authorization: request approval for planned treatment; the payer approves, rejects or raises a query.
• Claim: submit the claim after discharge with clinical documents.
• Payment notice: the payer's payment arrives later on your callback, and you acknowledge it.

For PMJAY, most claims still run in the TMS 2.0 portal. NHA has published an NHCX route for PMJAY claims from a hospital's own HMIS, currently in sandbox testing and pilot; we explain it in PMJAY on NHCX.

FHIR resources required for NHCX ("M4")

M4 challenges

• Code discipline: diagnoses need ICD-10 codes and procedures need the scheme's package codes; free-text diagnoses get queried or rejected.
• Asynchronous answers: payers answer in hours or days. The HIS must show each case's status and surface queries to billing staff.
• Payer variations: insurers and schemes differ in required documents and rules, so the claims layer needs per-payer configuration.
• Rejections and reprocessing: build a workflow to answer queries and reprocess rejected claims instead of raising new ones.

M4 in a multi-software or multi-facility environment

Claims pull data from the HIS, LIMS and pharmacy, so the same patient master and integration layer used for M2 should feed NHCX. Each facility registers as its own NHCX participant against its HFR ID. Our NHCX integration architecture for existing HMIS covers the design.

The multi-facility dimension

Architecture decisions

• One client ID or many: certification is per software, but deployment is per facility. A group can run one integration layer that routes callbacks by HIP ID.
• Central or per-branch patient master: a central index makes cross-branch discovery and consent easier.
• Routing: one bridge URL, with internal routing by the HIP ID in each callback.

Critical multi-facility challenges

• Each branch needs its own HFR registration and HIP ID.
• Consents can name a specific HIP, so records must be served from the right facility.
• Monitoring must show callbacks per facility, or one broken branch hides among healthy ones.

The complete picture: multi-software plus multi-facility

What an integrator must think about

1. A patient master index that maps ABHA to every system and facility.
2. Care context events from every system that creates records.
3. FHIR converters per system type, validated against NRCeS profiles.
4. Fidelius encryption and key handling in one place.
5. Callback routing, retries and monitoring per facility.
6. Consent storage, validation and purge rules.

The sandbox to production journey

1. Sandbox integration: register on the ABDM sandbox, get your client ID and secret, build your milestones with X-CM-ID: sbx.
2. Two milestones minimum: NHA Integration Support stated on the ABDM sandbox forum that the exit criteria "require any 2 milestones to be completed to exit sandbox and get the credentials for production environment." See why an M1-only certificate is not possible.
3. Functional testing: NHA's team tests your flows against its test cases.
4. Security audit: a WASA web application security audit by an empanelled auditor.
5. Demo and exit form: after which NHA issues production credentials; production calls use X-CM-ID: abdm and the production gateway at apis.abdm.gov.in.
6. Per-facility go-live: register each facility in HFR, configure its HIP ID and verify with GET /api/hiecm/gateway/v3/bridge-services.

Certification is per software; deployment is per facility. A hospital group repeats step 6 for every branch. The full process is in our ABDM certification process guide.

Common mistakes that stall ABDM integration

1. Losing link tokens and callbacks

Link tokens and consent notifications arrive on callbacks. If your handler is down, slow or behind a sleeping tunnel, they are gone; ABDM does not resend a lost consent notification. Monitor every callback route.

2. Defining care contexts inconsistently

Decide once what a care context is (an OPD visit, an admission, a lab order) and apply it across every system. Link them one per call.

3. FHIR bundles that do not conform to NRCeS profiles

The most common failures are missing required elements, wrong coding systems and bundles that PHR apps render as "NA". Validate every bundle against NRCeS profiles in your test pipeline.

4. Bridge URL misconfiguration

Two environments sharing one client ID, an HTTP instead of HTTPS URL, or testing before a change has applied. Check the registered URL with bridge-services before every test run.

5. Treating ABDM as a weekend API task

The APIs are the easy part. Test-sheet UI rules, callbacks, FHIR conversion, the security audit and the testing queue take most of the time.

6. Skipping the patient master index design

Without a central ABHA-to-system mapping, discovery, linking and data requests fail across systems.

More fixes are in 25 common ABDM errors and how to fix them and why M2 certification breaks dev teams.

Build vs buy vs hire an integrator

Our build vs buy vs SDK guide goes through the decision in detail.

How Nirmitee approaches ABDM integration

We have taken hospital software through all three milestones in the ABDM sandbox, including an HMIS that has cleared sandbox exit and runs ABDM in production, and we ran a live M3 test in September 2026 in which every value in the test records arrived intact (526 of 526 values, 30 of 30 attachments). Our approach:

• Integration layer first: one layer between the ABDM gateway and your HIS, LIMS, RIS and pharmacy.
• Pluggable FHIR converters: system-specific adapters that produce NRCeS-conformant bundles without changing your source systems.
• Central patient master: ABHA mapped to every system and facility.
• Callbacks as a product: immediate acknowledgements, background work, monitoring and alerts for every callback route.
• Follow the certified reference: where a behaviour already passed NHA's testing, we follow it screen by screen.

Our public ABDM V3 Postman collection, V3 error catalog and FHIR bundle examples are free to use. If you are planning ABDM milestones for your software, talk to our team about a scoped plan, or see our ABDM integration services.