"We're not a HIMS. We just want ABHA in our product. Do we really need ABDM certification?"
If you run a health-tech platform in India — a revenue-cycle tool, a LIMS, a teleconsultation app, a clinic-management overlay — you've probably asked some version of this. It's also one of the most common questions on the official ABDM developer forum, where integrators building for "HMIS, LIMS, PHR, and Teleconsultation" all show up asking the same thing.
The answer depends on one distinction most vendors never explain: ABDM certification attaches to the software, not to the healthcare facility. Get that right, and you'll know whether you need a 4–6 month certification journey — or none at all.
The One Rule That Decides Everything
NHA certifies software products (and the companies behind them) through the sandbox-to-production pipeline. Hospitals and clinics don't get certified — they get registered in the Health Facility Registry (HFR) and then transact through certified software.
Three consequences follow:
- A hospital using an already-certified HIMS is ABDM-enabled today, with zero sandbox work.
- A software vendor whose customers demand ABDM has no shortcut: the product must clear certification.
- A platform that isn't the system where clinical activity happens may not need its own certification at all — it can integrate with, or embed, a certified stack.
Quick Answers by Platform Type
- HIMS / HMIS / clinic-management software: Yes — certify. You're the system of record where patients register and clinical documents get created. Minimum two milestones (M1 + M2 in practice).
- LIMS / diagnostic-lab software: Yes — certify. Diagnostic reports are one of ABDM's core health-information types; labs are HIPs. M1 + M2 applies to you the same way it does to a HIMS.
- Teleconsultation platforms: Usually yes. If consultations produce prescriptions or OP consult records in your system, you're creating linkable health records — that's HIP territory.
- Revenue-cycle / billing / front-office overlays: Usually no. If the clinical record lives in the provider's HIMS and you handle money, scheduling, or analytics, you're not the HIP. Your customers' need for ABHA is better served through a certified stack you partner with or embed.
- PHR / patient-facing health apps: Different track entirely — the PHR app pathway (consent-manager side), not the M1–M3 HIP/HIU track. Don't apply for the wrong one.
- Health-tech services companies: You can certify once as a technology partner / health service provider and take multiple client facilities live on your certified stack.
Three Questions That Settle It
Work through these in order:
- 1. Where does the patient's clinical record get created? If it's your database — prescriptions, discharge summaries, lab reports, OP consult notes — you're a Health Information Provider and certification is your path. If records live elsewhere and you only reference them, you're not.
- 2. Who owns the registration desk? M1 lives where patients get registered. If your UI is where front-desk staff create patients, ABHA capture belongs in your product. If you sit behind someone else's registration flow, ABHA is their job — or the job of a certified stack you embed.
- 3. Do your customers need your name on the certified-integrators list? Hospital procurement teams increasingly check NHA's listing. If being absent costs you deals, certification is a commercial requirement even where a workaround technically exists.
If You Do Need to Certify: What It Actually Takes
The short version (our certification process guide has the full detail):
- Minimum any two milestones — M1 alone cannot exit the sandbox. This is NHA's stated exit criterion, and it catches teams months into the process.
- ABDM is a UI integration, not just APIs. Certification demos review your actual screens: ABHA creation modes, verification flows, scan-and-share, care-context linking. Backend-only integrations fail demos.
- The pipeline after development: NHA SPOC demos (typically 3–4 rounds) → functional testing by an empanelled agency → WASA security audit (CERT-IN empanelled) → Safe-to-Host certificate → validation demo → final committee demo → production keys → HFR bridge mapping. Budget roughly as much time for approvals as for development.
- M2 is where the effort is — FHIR document generation for your clinical records. Most Indian HIMS stacks don't have FHIR tooling; this is why M2 breaks most dev teams.
If You Don't: The Certified-Stack Route
For platforms that fail the three questions above, the practical path is: your client facilities register in the HFR, and ABHA/record capability comes from a certified technology partner — embedded in your product or run alongside it. Your customers get ABDM compliance in weeks; you get to stay focused on what your product actually does; nobody spends six months in the sandbox unnecessarily.
This isn't a loophole — it's how NHA designed the ecosystem. Certification exists to validate the software that touches clinical records and the ABDM network. Everything else plugs in.
The Decision in One Line
If clinical records are born in your software, certify (M1 + M2 minimum). If they aren't, partner with a certified stack and skip the sandbox entirely.
Not sure which side of the line your platform falls on? That's genuinely a 20-minute conversation — we've taken multiple products through M1–M3 certification and run production ABDM integrations, so we can tell you quickly whether you need certification, which milestones, or none at all. Explore our Healthcare Interoperability Solutions, and talk to our team.
