Every week, hospital IT teams and HMIS vendors ask us the same question: "We only need ABHA creation. Can we just do M1 and get certified?"
The short answer is no — and this article shows you exactly where that rule comes from, why it exists, and the two practical routes forward if all you actually want is ABHA in your software.
The Rule: Minimum Two Milestones to Exit the Sandbox
The National Health Authority (NHA) requires that an integrator complete any two milestones before it can exit the ABDM sandbox and receive production credentials. Completing M1 alone does not qualify.
This was stated directly by NHA's integration support team on the official ABDM Sandbox Developer Forum, in response to the question "Is it possible to get only M1 certificate?":
"The exit process criteria currently require any 2 milestones to be completed to exit sandbox and get the credentials for production environment."
— NHA Integration Support, ABDM Sandbox Forum
Where Exactly Is This Written?
Here's something most vendors won't tell you: this rule does not appear in any gazetted circular. We checked the official NDHM Sandbox Guidelines and the latest NHA sandbox FAQ document — neither states a milestone minimum.
The requirement lives in two places:
- The ABDM Sandbox Developer Forum — where NHA's integration support team answers policy questions on record (thread links above and here).
- The sandbox exit application itself — the exit process requires demonstrating working milestone functionality, and an M1-only application does not clear the exit criteria.
So if a consultant tells you "just do M1, it's enough" — they have never actually taken a product through sandbox exit. Teams discover this rule the hard way, months into the process.
A 60-Second Refresher: What the Milestones Are
The ABDM certification track has three milestones (our M1-to-M4 deep-dive guide covers each in detail):
- M1 — ABHA: Create, verify, and link ABHA (Ayushman Bharat Health Account) numbers during patient registration.
- M2 — HIP: Become a Health Information Provider — share digital health records (as FHIR documents) with the patient's consent.
- M3 — HIU: Become a Health Information User — fetch and display a patient's records from other facilities, with consent.
M1 is identity. M2 and M3 are the actual data exchange. That distinction is the key to understanding the rule.
Why NHA Won't Certify M1 Alone
ABDM exists to create a national health-data exchange, not a national ID-issuance program. An application that only creates ABHA numbers adds identities to the network but exchanges nothing — it consumes the ecosystem without contributing to it.
Requiring a second milestone forces every certified integrator to participate in interoperability itself: either publishing records to the network (M2) or consuming them (M3). It's the same logic UPI applied — you can't be "half on the network."
There's also a compliance driver: government schemes and the Digital Health Incentive Scheme (DHIS) reference linked health records, not just ABHA counts. M1-only software would leave hospitals unable to claim those benefits anyway.
Which Two Milestones Should You Pick?
In practice, the combination is almost always M1 + M2:
- M1 + M2 (recommended): The natural pair. Registration creates the ABHA (M1); your existing clinical documents — OPD prescriptions, discharge summaries, diagnostic reports — become the linked records (M2). Most of the M2 effort is FHIR document generation, which also future-proofs you for NHCX claims later.
- M1 + M3: Valid for exit, but unusual — M3 means building record-viewing workflows for clinicians, which matters most to hospitals consuming outside records. Most HMIS products have more to share than to fetch on day one.
- All three: The complete story, and what NHA's milestone-wise integrator listing rewards. If you're building for hospitals empanelled under government schemes, plan for M3 eventually.
The Route Nobody Tells You About: You May Not Need to Certify at All
Here's the part that changes the conversation for most hospitals and clinics: certification attaches to the software, not the facility.
If your HMIS vendor (or a technology partner acting as your Health Service Provider) has already cleared the milestones, your facility rides on their certified stack. You register your facility in the Health Facility Registry, plug into the certified platform, and you are ABDM-enabled — without your team ever touching the sandbox, WASA audits, or exit paperwork.
That's the honest answer to "we only want M1": you don't need an M1-only certificate (which doesn't exist) — you need ABHA capability inside software that's already certified. The 4-6 months of sandbox work only makes sense if you're a product company that needs the certificate on your own product.
Decision Framework
- You're a hospital/clinic that wants ABHA at registration: Use an already-certified HMIS or HSP. Zero sandbox effort.
- You're an HMIS/software vendor whose customers demand ABDM: You must certify — and you must plan M1 + M2 minimum. Budget for FHIR document generation; it's 70% of the M2 work.
- You want claims (NHCX) eventually: M1 is a hard prerequisite for NHCX onboarding, and M2-grade FHIR tooling is what claims bundles are built from. Doing M1 + M2 now is the shortest path to cashless-claims readiness later.
Building for ABDM and want to skip the six months of trial and error? Our team has taken multiple HMIS products through M1–M3 certification and operates production ABDM integrations today. Explore our Healthcare Interoperability Solutions, or if you need ABDM capability built into a product from scratch, our Custom Healthcare Software Development services. Talk to our team — we'll tell you in one call whether you need to certify at all.
