ABDM Integration Guide: M1, M2 and M3 Milestones, ABHA, HIP/HIU and the Sandbox-to-Production Path

As of October 2026, integrating with ABDM means building three milestones in the ABDM sandbox: M1 (create and verify ABHA), M2 (act as a Health Information Provider that links and shares records) and M3 (act as a Health Information User that requests records with consent). To reach production, you then pass functional testing by NHA, get a security audit (“WASA” or “Safe-to-Host”) from a CERT-In or STQC empanelled agency, and file a sandbox exit application. There is no single “ABDM certificate”. What most people call ABDM certification is approval of that exit application. This guide explains each milestone, the registries and consent flow behind them, the FHIR formats, the go-live steps, and the incentive scheme, and flags where official and community sources disagree.

1. The Path at a Glance

These names and steps come from the ABDM sandbox portal, which can change without a dated notice. The government’s July 2026 ABDM backgrounder confirms the principle in plain terms: “Every new app must first be tested in a ‘sandbox’” and “must also pass a security audit before going live.”

2. The Building Blocks: ABHA, HFR, HPR, HIP, HIU and the Consent Manager

ABDM is federated: records “stay with whoever created it” and there is “no central government server storing all this data” (July 2026 backgrounder). ABDM provides identifiers, registries and consent-based exchange; your software stores and serves the records.

Where the definitions disagree

Older official documents use older names. The NDHM Sandbox Enabling Framework (v1.0, August 2020) calls ABHA “Health ID” and the HPR “DigiDoctor”, and defines a HIP as a provider that adopts “EMR software that is certified to be compliant with NDHM standards.” We use the current names from the 2026 backgrounder.

“Consent manager” also has two meanings. In ABDM’s policy it is an electronic system; in the DPDP Act, 2023 it is “a person registered with the Board”, with registration opening 13 November 2026. ABDM has not said whether its infrastructure will register under the DPDP Act. Our DPDP Rules guide covers the second.

3. M1: ABHA Creation and Verification

M1 is the identity milestone, and the sandbox portal requires you to complete the M1 details before you can move on to M2 or M3. An M1 integration lets your registration desk or app:

• create an ABHA for a patient who doesn’t have one, through the authentication methods ABDM’s APIs support (Aadhaar-based OTP is the common route);
• verify an existing ABHA, by number or ABHA address, and fetch the demographic details the patient authorises;
• store the ABHA number and address against your own patient record, so later milestones can link records to it.

Two 2026 details matter. The current API generation is v3, which NHA’s incentive rules require for M1–M3 from July 2026, so ignore older tutorials. And incentives count only records linked to a KYC-verified ABHA, so store each patient’s KYC status too.

4. M2: Becoming a Health Information Provider

M2 lets a facility’s system share the records it creates. The work splits into three parts:

1. Facility and bridge setup. The facility must be registered in the HFR. Your software registers a bridge (the callback endpoint that ABDM calls), and after go-live the HIP updates its production bridge ID in its HFR profile, as the sandbox exit process requires.
2. Linking care contexts. A care context is a visit, admission or episode whose records belong together. When a patient with an ABHA is seen, your system links the care context to their ABHA, either at your initiative after the consultation or when the patient discovers and links records through a PHR app.
3. Sharing on consent. When a HIU’s consent request is approved, ABDM notifies you. Your system checks the consent artefact (which records, which date range, which HI types, until when), builds the matching FHIR bundles, encrypts them for the requesting HIU and pushes them to the data-push URL it was given. You then report the transfer status.

Every step is asynchronous: answers arrive later at your bridge as callbacks. Plan for retries, idempotency and request correlation, and log each consent artefact ID with the records it released. Our audit logging guide lists the fields worth capturing.

5. M3: Becoming a Health Information User

M3 is the other side of the exchange: your system asks for records created elsewhere. A HIU integration:

• raises a consent request against a patient’s ABHA address, stating the purpose, the HI types, the date range and how long access lasts;
• receives the patient’s decision (they approve or deny in a PHR app) and the consent artefact if they approve;
• requests the data, receives encrypted FHIR bundles from each HIP, decrypts them and shows them to the clinician;
• honours expiry and revocation: when consent expires or is revoked, stop showing the data, and delete it if your policy requires.

ABDM’s 2020 sandbox framework is explicit: “No record will be accessible to HIUs without the consent of the user.” Show clinicians which records came from outside, under which consent, and when access ends.

Beyond M3

The sandbox exit form also lists M4, labelled “National Healthcare Provider Registry (HPR/HFR)”, as well as PHR apps, health lockers and NHCX (the National Health Claims Exchange). Most hospital and clinic software needs M1–M3. Consumer apps that hold a patient’s own records look at the PHR and health-locker tracks, and insurers and hospitals filing claims look at NHCX.

6. FHIR Health Records: the NRCeS Implementation Guide

Records exchanged through ABDM are FHIR R4 documents profiled by the National Resource Centre for EHR Standards (NRCeS). As of this review, the FHIR Implementation Guide for ABDM is version 6.5.0, based on FHIR 4.0.1. Its document profiles map to the health-information (HI) types you will see in consent requests:

Each is a Composition inside a document Bundle. Validate every bundle against the profiles before it leaves your system, and record which guide version you built against. Our FHIR integration guide covers resource modelling and validation in more depth.

7. Sandbox to Production: Testing, WASA and Exit

The sandbox portal sets out a four-step exit process:

1. Functional and non-functional testing “of the application by an internal NHA team”, against draft test cases NHA publishes. You schedule a demo date for each milestone.
2. Security testing “of the web/mobile application from any STQC or CERT-IN empaneled agency”, after which you submit the “Safe-to-Host” certificate to NHA. The portal adds that STQC “may also reach out to perform validation testing on a few sample applications.”
3. Final approval of the exit application.
4. Production access: client ID and secret are emailed to you.

The exit form asks for a functional testing certificate or report, a WASA certificate, a Safe-to-Host certificate and a signed undertaking on letterhead, in which you agree to share sandbox and production user logins with NHA and keep your sandbox instance running. Non-compliance “may result in revoke” of access.

WASA is Web Application Security Assessment. In practice WASA and Safe-to-Host are one engagement with an empanelled auditor: test, fix, retest, certificate. CERT-In publishes its list of empanelled auditors on cert-in.org.in. Our CERT-In page covers the separate 6-hour incident-reporting duty.

Where sources disagree

• Who does functional testing. The portal says “an internal NHA team”. Integrators on ABDM’s developer forum have described paying outside agencies for functional testing. We could not open those threads to confirm the current position, so ask NHA integration support before you budget.
• How many milestones you need to exit. Forum answers have said at least two milestones are needed, so M1 alone is not enough. The portal requires M1 before M2 or M3 but, in what we could read, does not state a minimum. Treat “M1 plus one more” as likely, not confirmed.
• Timelines. The 2020 framework sets stages of up to 4, 3, 12 and 4 weeks; it predates the current portal, and vendor estimates are not official.

Production-approved integrators are listed on the sandbox portal’s successful integrators page, with the milestones each has completed. Check it before you choose a vendor that claims to be ABDM-integrated.

8. Incentives: the Digital Health Incentive Scheme

The Digital Health Incentive Scheme (DHIS) launched on 1 January 2023 and has been changed by a series of corrigenda. The most recent we found is Corrigendum 7, dated 9 April 2026, effective “from the month of April 2026 till September 2026.” NHA lists the scheme documents at abdm.gov.in/DHIS; we read Corrigendum 7 in the copy circulated by Rajasthan’s health department.

For vendors: incentives start only the month after a valid WASA report is submitted; from July 2026 nobody is paid unless the software complies with v3 of M1–M3; and Scan & Share and health-locker linking no longer earn record-linking incentives.

9. ABDM and the DPDP Act

From 13 May 2027, when the DPDP Rules’ main duties apply, a HIP or HIU is a Data Fiduciary for its own processing: standalone notice and consent, security safeguards, 72-hour breach reports to the Data Protection Board, a year of processing logs, and 90-day grievance responses. ABDM’s consent artefact governs HIP-to-HIU sharing; it does not replace your own DPDP consent. Our DPDPA page and the DPDP Rules guide cover the details, and our guide to health-data encryption applies equally to ABHA-linked records.

10. A Build Plan, and Where VertiComply Fits

1. Decide your role. Clinic or hospital software usually needs M1–M3. A diagnostics lab mostly needs M1 and M2. A doctor-facing app that only reads records needs M1 and M3.
2. Register in the sandbox and read the v3 documentation for each milestone you have chosen.
3. Model your data on FHIR first. If your internal records already map to the NRCeS profiles, M2 becomes a serialisation problem rather than a redesign.
4. Build the bridge with signature checks, retries, idempotent handlers and full audit logs of consents and transfers.
5. Harden before the audit: OWASP Top 10, TLS, encryption at rest, no debug endpoints.
6. Book functional-test demos for each milestone, file the exit application with the certificates and undertaking, and after go-live update the bridge ID in HFR.

VertiComply generates full-stack healthcare apps, for the web and native iOS and Android, with safeguards for HIPAA, GDPR, India’s DPDPA and ABDM, plus FHIR building blocks. It gives you a head start on steps 3 to 5: FHIR-shaped data models, consent capture, encryption and audit logging. VertiComply itself is not an ABDM-approved integrator. Your application still goes through NHA’s functional testing, the security audit and the exit process under your own organisation’s name. Plans are also priced in rupees (Pro ₹8,999/month, Business ₹24,900/month; see pricing). The ABDM reference page has the one-page summary.

This is general information, not legal or regulatory advice. ABDM processes change through the sandbox portal and NHA circulars, so confirm the current requirements with NHA before you plan a launch.

Frequently Asked Questions

What are the ABDM M1, M2 and M3 milestones?

M1 covers ABHA: creating, verifying and capturing a patient’s Ayushman Bharat Health Account at registration. M2 makes your system a Health Information Provider that links care contexts to ABHA and shares FHIR records when a patient consents. M3 makes it a Health Information User that raises consent requests and fetches records from other providers. The sandbox requires M1 before M2 or M3.

Is there an official ABDM certification?

Not as a single certificate. To get production access you complete milestones in the ABDM sandbox, pass functional testing by NHA, obtain a security audit and Safe-to-Host certificate from a CERT-In or STQC empanelled agency, and file a sandbox exit application. When people say “ABDM certified”, they usually mean that exit application was approved and the product is live in production.

What is WASA in ABDM integration?

WASA stands for Web Application Security Assessment. It is the security audit of your web or mobile application by a CERT-In or STQC empanelled agency that the sandbox exit process requires, leading to a Safe-to-Host certificate. NHA’s incentive scheme also requires a valid WASA report before a digital solution company can receive DHIS incentives.

Do I need all three milestones to go live on ABDM?

Not necessarily, but M1 is required before M2 or M3. ABDM’s developer forum has said at least two milestones are needed to exit the sandbox; we could not confirm this in current official documentation, so ask NHA integration support.

Which FHIR version does ABDM use?

FHIR R4. Records follow the FHIR Implementation Guide for ABDM published by the National Resource Centre for EHR Standards, version 6.5.0 at the time of review, based on FHIR 4.0.1. It defines document profiles such as OPConsultRecord, PrescriptionRecord, DiagnosticReportRecord, DischargeSummaryRecord, ImmunizationRecord, WellnessRecord, HealthDocumentRecord and InvoiceRecord.

Is the Digital Health Incentive Scheme still running?

The latest version we found, Corrigendum 7 dated 9 April 2026, covered April to September 2026. It pays for KYC-verified ABHA record linking above 100 transactions a month, consent-based sharing and NHCX claims, and requires v3 APIs from July 2026. Check abdm.gov.in/DHIS for later notices.

Last reviewed 12 October 2026. Milestone names and exit steps are from the ABDM sandbox portal, incentives from DHIS Corrigendum 7, and definitions from ABDM’s Health Data Management Policy and the July 2026 PIB backgrounder. Check NHA’s current documentation before you rely on any detail.