ABDM Milestone 3 is the stage where a software product proves it can fetch and view a patient’s existing health records from other providers, with the patient’s consent, acting as a Health Information User. It builds on M1 (create and link ABHA) and M2 (share and link records). The exact requirements are defined by the NHA’s current milestone guidelines, so treat the descriptions here as the well-known structure and confirm the specifics on the official ABDM sandbox.
Key takeaways
- ABDM milestones (M1, M2, M3) are a vendor-certification path run by the NHA, not something a clinic passes.
- M1 broadly covers creating and linking ABHA. M2 broadly covers sharing and linking records. M3 broadly adds the Health Information User side: fetching and viewing records under consent.
- There are 2 gaps to close, not 1: passing a milestone, and running it live. Sandbox is not production.
- Under the DHIS as revised by NHA Corrigendum 6, dated 20 November 2025, eligible facilities can receive ₹20 per KYC-verified ABHA-linked transaction above a 100-transaction monthly baseline.
- Patient Square is not ABDM-certified at any milestone today; ABDM support is on the roadmap.
Create and link ABHA
Share and link records
Fetch and view records (HIU)
Source: ABDM and NHA portals; confirm current milestone definitions there.
Where M3 sits in the milestone ladder
If you read the Milestone 2 explainer, you already know the shape. The NHA certifies software against staged milestones, and each one opens up a bit more of what “ABDM” actually does for a patient sitting in front of you.
Here is the ladder in plain terms. M1 is the entry point: create an ABHA and link it. M2 is where records start moving, sharing and linking a patient’s health data so it can travel with consent. M3 is the other half of that exchange. Where M2 is largely about a system putting records into the ecosystem, M3 is about a system pulling records out of it, on the patient’s behalf and with the patient’s permission.
That distinction is the whole point of this post. The person who wired up M2 built the outbox. M3 is the inbox.
What Milestone 3 requires
The precise checklist lives with the NHA and gets revised, so we will describe M3 conservatively and point you to the source. Broadly, M3 is the record-retrieval milestone, the Health Information User capability.
A Health Information User, or HIU, is a system that requests and consumes health records held elsewhere. To reach M3, a product generally has to demonstrate the consented-fetch flow end to end: raise a consent request for a specific patient and record type, let the patient grant or deny it through a Consent Manager, and then fetch and display the records that come back. Depending on the vendor’s role and how the NHA frames the current path, M3 can also fold in maturity on the linking and scan-and-share flows that earlier milestones introduced.
The consent handshake is the part worth understanding. Nothing gets fetched because a clinic wants it. A record request goes to the patient, the patient approves it through their own consent manager, and only then does the data flow. That is by design. ABDM is built so the patient, not the provider, holds the key to their history. If you want the mechanics of how ABHA identity anchors that consent, the ABHA number versus ABHA address explainer clears up the two identifiers patients constantly mix up.
Why a clinic or its vendor pursues M3
M1 gets a patient onto ABDM. M2 lets a clinic contribute records. Neither, on its own, lets a doctor see what happened at the last hospital.
M3 is what changes that. Picture a Pune OPD at 8pm: a new patient arrives, no file, a vague history, a stack of old prescriptions they forgot at home. With M3-class capability live, the clinician can request that patient’s prior records through ABDM, the patient consents on their phone, and the earlier discharge summary or lab reports surface at the point of care. That is the version of “interoperability” most people imagined when they first heard about the digital health mission.
So a vendor pursues M3 because it is the milestone that makes the ecosystem feel like a network instead of a filing cabinet. And a clinic cares because M3 is where ABDM starts saving clinical time and reducing repeat tests, not just generating IDs. There is also a financial nudge in play. The NHA runs the Digital Health Incentive Scheme (DHIS), and under the DHIS as revised by NHA Corrigendum 6, dated 20 November 2025, eligible facilities can receive ₹20 per KYC-verified ABHA-linked transaction above a 100-transaction monthly baseline. The ABDM incentives for doctors post has more context; treat that ₹20 figure as the one number worth quoting, since the broader scheme details sit with the NHA and change over time.
The sandbox-to-production path
Every ABDM milestone is earned twice. First in the sandbox, then in production. Clinics get burned when a vendor conflates the two.
Here is the rough sequence a vendor follows for M3:
- Build against the sandbox. The ABDM sandbox is the test environment. The vendor registers, gets test credentials, and implements the HIU consent-and-fetch flows against simulated data.
- Demonstrate the milestone flows. The vendor runs the required scenarios, showing that consent requests, grants, denials, and record retrieval all behave as the NHA’s guidelines specify.
- Go through NHA’s process for production. Passing in the sandbox is a checkpoint, not the finish line. The vendor then works through NHA’s steps to enable the same capability in the live environment real patients use.
- Run it live. Only at this stage can a doctor at your clinic actually fetch a real patient’s records under consent.
The gap between step 2 and step 4 is where “we support ABDM” often lives. A product can demo an immaculate M3 flow in the sandbox and still do nothing for your Tuesday clinic. That is not the vendor lying, exactly. It is the vendor answering a different question than the one you meant.
Sandbox certified versus production live
| Question to ask | Sandbox-only answer | Production-live answer |
|---|---|---|
| Which milestone? | ”We’ve built toward M3" | "We’re certified at M3” |
| Where does it run? | ”In our test environment" | "In production, with live patients” |
| Can a doctor fetch records today? | ”Once we go live" | "Yes, with patient consent” |
| Can you show current status? | Screenshots of a demo | Verifiable certified status |
| How is consent captured? | ”The flow exists” | Consent Manager, per NHA spec |
That last row is not optional politeness. Fetching a patient’s records under M3 sits squarely inside consent-based, lawful data handling. Under the DPDP Act framework, the patient’s grant is what makes the retrieval legitimate. Our DPDP guide for clinics covers the consent and data-protection obligations that ride alongside any ABDM record exchange.
What M3 does and does not mean for a clinic
Let’s be precise, because the label oversells easily.
What M3 means, when it is live: your software can pull a patient’s consented history from across the ecosystem and show it to the treating clinician. Fewer blind consultations. Fewer repeat investigations because the last report is right there. A genuine step up from an ID-and-linking setup.
What M3 does not mean: it does not turn ABDM into a magic universal record where everything a patient ever did appears automatically. Records only surface for providers who are themselves on ABDM and have shared data, and only after the patient consents each time. It does not remove your DPDP obligations. And it does not, by itself, make a product good at everything else a clinic needs, from scheduling to notes. M3 is a specific interoperability capability, not a quality badge for the whole product. If you are weighing whether to sort out records exchange or documentation first, which to buy first, an AI scribe or an EMR works through that trade-off for an Indian practice.
One more honest note. Even a vendor certified at M3 in production is not automatically a fit for your clinic. An ABDM-ready EMR still has to handle your OPD flow, your billing, and your front desk. Milestone status answers one question well. It does not answer all of them.
Where Patient Square fits in all this
Straight answer: Patient Square is not ABDM-certified at any milestone today, M3 included, and we will not imply otherwise. ABDM support is on our roadmap, not shipped. We do not claim Health Information User, HFR, HPR, or NHCX integration, and we do not assert any milestone status for the product.
What the scribe does is separate from certification. It listens during the consult and drafts a structured SOAP note, ICD-10 suggestions, and a prescription draft, all in clinical English, about two minutes after the visit ends. Those ICD-10 entries are suggestions for you to confirm, never auto-applied codes. The prescription is a draft you review and sign, not an e-prescription sent anywhere. Visit audio is processed and discarded, not stored. You stay the author of the record.
So the M3 conversation is one you have with your HMS or EMR vendor about record retrieval and consent. The scribe is about getting the clinical note written fast and accurately, without an integration project on your side. If you want the note-drafting picture on its own, the scribe overview for Indian doctors covers it.
The short version
Milestones belong to vendors, not clinics. M1 is create-and-link ABHA. M2 is share-and-link records. M3 is the Health Information User side: fetching and viewing a patient’s records under consent, the milestone that lets a doctor actually see prior history at the point of care. The exact scope is set by NHA’s current guidelines, so verify it on the ABDM sandbox rather than trusting a marketing line. And remember the two-gap rule: ask which milestone, and ask whether it is live in production.
Want to see how a signed clinical note comes together in about two minutes, with no ABDM integration required on your side to start?