Does Your Platform Need ABDM Certification? HMIS, LIMS, Telemedicine and Non-HIMS Health Tech (2026)

Your platform needs its own ABDM certification only if it is the software where patients are registered or clinical records are created: HMIS, LIMS, clinic software and most teleconsultation apps must certify with at least two milestones. Billing, revenue cycle, scheduling and analytics platforms usually do not; they embed or partner with a certified stack while the facilities register in the Health Facility Registry.

"We are not a HIMS, we just want ABHA in our product. Do we really need ABDM certification?" It is one of the most common questions on the ABDM developer forum, from teams building HMIS, LIMS, PHR and teleconsultation products alike. This guide answers it by platform type, gives four questions that settle it, and shows what each path involves. Updated September 2026.

The rule that decides it: certification attaches to software, not facilities

NHA certifies software products, and the companies behind them, through the sandbox-to-production process. Hospitals and clinics are not certified; they register in the Health Facility Registry (HFR) and exchange data through certified software. Three consequences follow:

• A hospital using an already-certified HMIS is ABDM-enabled without any sandbox work.
• A software vendor whose customers need ABDM has no shortcut: its product must clear certification, with any two milestones.
• A platform that is not where clinical activity happens may not need its own certification at all; it can integrate with, or embed, a certified stack.

If your product does need to certify, our ABDM integration services team builds the milestones into it; if it does not, we can help you embed a certified stack instead.

ABDM certification by platform type: HMIS, LIMS, telemedicine and more

In short, whether you build an HMIS, a LIMS, a PHR or a teleconsultation product, the answer follows where records are born and who owns the registration desk.

Four questions that settle it

1. Are clinical records created in your software? If prescriptions, discharge summaries, lab reports or consultation notes are born in your database, you are a Health Information Provider and certification is your path, with M2 as one of your milestones.
2. Does your product own the registration desk? M1 lives where patients are registered. If front-desk staff create patients in your screens, ABHA capture belongs in your product. If you sit behind someone else's registration, ABHA is their job, or the job of a certified stack you embed.
3. Do you read records from other providers? If your product shows clinicians or payers records held elsewhere, M3 is relevant, either in your own certification (M1 + M3) or through a certified partner.
4. Do your buyers require your name on the certified list? Hospital procurement teams check whether a vendor is certified. If being absent costs you deals, certification becomes a commercial requirement even where a partner route would work technically.

If you do need to certify: what it takes

• Any two milestones. M1 alone cannot exit the sandbox; this is NHA's stated exit criterion, explained in why an M1-only certificate is not possible.
• Screens, not just APIs. NHA's testing reviews your actual user interface: ABHA creation and verification modes, Scan and Share, care context linking and consent handling. Backend-only integrations fail the demo.
• M2 is where the effort goes. Producing your records as FHIR bundles, answering callbacks on time and encrypting with Fidelius take most of the time. Read why M2 certification breaks dev teams before you plan.
• Testing and exit. Functional testing of each milestone, a WASA security audit, a demo to NHA's team and the exit form, then production credentials and mapping to your facilities. Our ABDM certification process guide covers each stage, and the ABDM integration step-by-step guide covers the build.

If you do not: the certified-stack route

For platforms that answer "no" to the questions above, the practical path is simple. Client facilities register in the HFR, and ABHA and record capability comes from a certified technology partner, embedded in your product or running alongside it. Your customers get ABDM through software that has already passed testing, and your team stays focused on what your product does.

This is not a loophole. Certification exists to validate the software that touches clinical records and the ABDM network; everything else connects to it. If you are weighing building versus embedding, our ABDM build vs buy vs SDK guide compares the options.

Is ABDM certification mandatory?

Certification is mandatory for any software that connects to ABDM in production: you cannot get production credentials without clearing the sandbox exit. Whether your organisation must connect at all depends on your customers and schemes; for hospitals, government schemes such as AB-PMJAY increasingly expect ABDM-enabled software. Our guide to ABDM compliance for AB-PMJAY hospitals covers that side.

The decision in one line

If clinical records are created in your software, certify with at least two milestones. If they are not, partner with a certified stack and skip the sandbox. Not sure which side your platform is on? Talk to our team; we have taken hospital software through all three milestones and can tell you quickly whether you need certification, which milestones, or none.