ABDM milestones M1, M2, M3 and M4, explained

01What a milestone is

A milestone is NHA’s unit of ABDM certification: a defined set of capabilities, a published specification, and a sheet of test cases that software must pass before it may use that capability in production.

Milestones are cumulative in dependency but separate in certification. Everything on the network keys on a patient’s ABHA, so later milestones assume the first. Beyond that, each is claimed on its own, and most products never need all of them.

The specifications are living documents. At the time of writing the M2 document on NHA’s sandbox site is dated August 2025 and the M3 document March 2025, and both reflect the v3 APIs. Test-case sheets and write-ups older than that often describe v1 or v2 flows, so check the date on anything you build against.

If you want the ecosystem first, read what ABDM is; for the wire-level detail of each flow, see how ABDM integration works. This guide is about scope and certification.

02M1 — ABHA creation and verification

M1 is the patient identity milestone. It covers the software’s ability to:

• create an ABHA, most commonly from Aadhaar with an OTP, and from a mobile number;
• let the citizen choose or create an ABHA address;
• verify, or log in with, an existing ABHA by number, address or mobile;
• read the profile and show the ABHA card and QR code;
• record the ABHA against the patient in the facility’s own system, alongside its MRN.

The last item is easy to overlook and is part of the milestone: an ABHA created at the counter and not stored on the patient record is of no use to the flows that follow.

Older test sheets organise M1 into families such as creation (CRT_ABHA), verification (VRFY_ABHA) and linking to the patient (LINK_ABHA). Confirm the current numbering with your testing agency. Many M1 cases have a user-interface half — the consent text shown to the citizen, the resend-OTP timer, how the card is displayed — so they are tested in the product a facility uses, not just at the API.

Technically M1 is the most self-contained milestone: synchronous APIs, no callbacks, but strict rules about encrypting Aadhaar numbers and OTPs and never storing them. See the ABHA integration guide.

03M2 — Health Information Provider

M2 is everything a facility needs to provide records to the network. It has two halves, and both are in the milestone.

Linking

• HIP-initiated linking: the facility links a new care context (a visit, an admission, a lab order) to a patient whose ABHA it already holds.
• User-initiated linking: the patient finds the facility in a PHR app, the HIP discovers matching records, and the link is confirmed with an OTP.
• Notifications: telling ABDM that new records exist, and the SMS that invites a patient to link.

Sharing under consent

• receiving and storing consent artefacts that concern the facility’s records, including revocation and expiry;
• answering a health information request by building FHIR bundles, encrypting them, and pushing them to the requester;
• sharing only what the artefact covers: the right patient, health information types and date range.

That last point is where M2 is actually judged. A functional tester will grant consent for a narrow slice and check that nothing outside it arrives, then revoke and check that a later request is refused.

Because linking and sharing are asynchronous, M2 is where integration effort jumps. It is also the milestone that most needs clean clinical data: bundles are built from your records, so a product whose prescriptions are free text will spend time on mapping. The HIP integration page covers the build.

04M3 — Health Information User

M3 is the other side of the exchange: requesting records from other providers. It covers:

• raising a consent request for a patient, with a purpose, health information types and a date range;
• tracking its status, and handling grant and denial;
• fetching the resulting consent artefacts and respecting their actual terms, which may be narrower than the request;
• requesting health information under an artefact, and receiving, decrypting and validating the pushed bundles;
• honouring revocation, expiry and the data-retention date, so that records stop being available when the consent says so;
• presenting what was received to the clinician in a usable form.

M3 carries its own share of asynchronous work, plus a human wait: the patient may approve a request in a minute or in three days, and the product has to make that state visible rather than leave a clinician refreshing a screen. See the HIU integration page.

05“M4”: the inconsistent one

M1, M2 and M3 are used the same way by NHA and by integrators. “M4” is not, and it is worth being plain about that before it causes a misunderstanding in a contract.

• Some integrators and write-ups use M4 for NHCX, the National Health Claims Exchange: digital insurance claims, eligibility checks and pre-authorisation. NHCX has its own specifications, onboarding and credentials, separate from the ABDM gateway.
• Others use M4 for the registries: searching and registering facilities in HFR, and looking up and registering professionals in HPR. Swastik’s connector uses it in this sense. HPR has its own official test-case sheet.

Neither usage is wrong so much as unofficial, and they describe entirely different work. When a vendor, a tender or a testing agency says “M4”, ask which is meant. And whatever your product does with the registries, a facility still has to be in HFR, with its services linked to your software, before M2 and M3 work for it at all — see HFR and HPR integration.

06Which milestones your product needs

Start from what the product does with records, not from how many milestones a competitor lists. Typical scopes:

Milestones can be added later. A lab platform that launches with M1 and M2 can add M3 when a customer asks, without redoing the first two — although it will go back through testing for the new milestone. Hospital and lab specifics are on the hospital and lab pages.

07From sandbox to production

The sandbox is open to any registered integrator. Production is not. The route between them, as NHA’s process describes it:

1. Sandbox registration. Register the software and receive sandbox credentials.
2. Build and self-test every milestone you will claim, against the real sandbox, including callbacks from a real PHR app.
3. Start the exit by filling in the exit form in your sandbox account. It is the current word on what is required; check it before relying on any guide, this one included.
4. Functional testing by a testing agency NHA has empanelled. The agency runs the test-case sheets for your claimed milestones against your deployment and issues a functional testing report. This is paid for and booked in advance.
5. Security audit by a CERT-In empanelled auditor, ending in a Safe-to-Host certificate once findings are closed. Integrators commonly call this the WASA, for web application security audit.
6. Submission to NHA: the functional testing report, the Safe-to-Host certificate and NHA’s production keys template, for review.
7. Production access, with production credentials, production bridge registration and a production consent manager id.
8. Per-facility linkage. Each facility going live must be verified in HFR and have its services linked to your production bridge. For an HMIS vendor this step repeats for every customer.

Some integrators also report a demonstration of workflows to an NHA panel. Whether or not you are asked for one, record an end-to-end walkthrough of each milestone in the sandbox, showing the patient’s PHR app as well as your product. It costs an afternoon and doubles as evidence for the agency. abdm.gov.in and the sandbox portal carry NHA’s current guidance.

08How long it takes

Timelines depend heavily on the state of the product going in and on queues outside your control. These are typical ranges, not promises.

The first three rows include their own sandbox testing, and are the alternatives to the fourth rather than additions to it: a connector that already speaks the protocol shortens the build, but none of the stages after it. The security audit is usually the long pole: it is sequential, it depends on an external calendar, and a finding that needs a code change restarts part of it. Start the conversation with an auditor before functional testing finishes.

09Scoping pitfalls

• Claiming more than you need. Every claimed milestone adds test cases, audit surface and support. A lab that claims M3 because it sounds complete has taken on consent state and decryption it will never use.
• Forgetting the user-interface half. Test cases check screens: consent language, OTP timers, card display, token display at the counter. An API that works is not a milestone that passes.
• Treating consent as a switch. Scope and revocation are where M2 and M3 fail. Test a narrow grant and a revocation yourself before the agency does.
• Arriving at the agency with open questions. Their time is billed. Every flow should already have run against the real sandbox, with the request ids noted so you can answer “what did you send?”.
• Leaving HFR until go-live. Facility registration, verification and bridge linkage take time of their own, and a duplicate HFR entry can only be merged by NHA.
• Assuming certification transfers. Building on a connector removes integration work, but the product a facility uses is still what gets tested and audited. Nobody can take certification off your plate.

If you are scoping an HMIS integration, the HMIS integration guide is the natural next read. Swastik’s ABDM connector implements M1, M2, M3 and the registries behind one REST API, and you can exercise each milestone in the sandbox before deciding what to claim.