ABDM compliance for an AI vendor is not one certificate. It is the ability to identify the facility you deploy in through the Health Facility Registry, identify the clinician who signs your output through the Healthcare Professional Registry, and, where your product touches a longitudinal record, link that record to a patient's ABHA number under consent. The registries are the entry gate. ABHA linkage is the harder, later work. Get the sequence wrong and your product sits outside the national health stack while a lighter tool that got the sequence right wins the account.
That is the shift a hospital CIO needs to price into the next procurement cycle. Two years ago ABDM readiness was a line item a vendor could promise and defer. It is now becoming the thing the procurement committee checks first, because the government has put a working reference implementation on the table and made it free.
What ABDM compliance actually asks of a vendor
Strip away the acronyms and ABDM asks three questions of any software that wants to operate inside the national health stack.
First, where are you running? Every facility that participates in ABDM carries a Health Facility Registry identifier, the HFR ID. It is the prerequisite for connecting a software system into ABDM rails, for appearing in national facility searches, and increasingly for meeting state directives and accreditation conditions. A vendor deploying into a hospital does not own this, the facility does, but the vendor's product has to be able to operate against it.
Second, who is signing? The Healthcare Professional Registry, the HPR, identifies the clinician. HPR onboarding is what lets a professional issue ABDM-recognised prescriptions, lab orders and discharge summaries. If your AI drafts a note that a doctor signs, the identity of that doctor inside HPR is what makes the signed artefact legible to the rest of the stack.
Third, whose record is this? ABHA, the Ayushman Bharat Health Account, is the patient's 14-digit health identity. Linking a clinical document to an ABHA number under the patient's consent is what turns a note trapped inside one hospital's HMIS into part of a portable, longitudinal record. This is the deepest layer of integration and the one most vendors quietly skip.
The mistake CIOs make is reading these three as a single compliance stamp. They are three separate pieces of engineering with three different owners and three different failure modes. HFR and HPR are registry lookups and onboarding flows. ABHA linkage is consent management, document packaging to the required FHIR profiles, and reconciliation when the same patient shows up under two different ABHA numbers.
Why e-Sushrut moved the goalposts
For most of ABDM's life the counterfactual to a compliant vendor was a non-compliant vendor. The buyer chose between products that all needed the same integration work, so the work could be negotiated. That changed when the government shipped its own compliant HMIS.
The National Health Authority and the Centre for Development of Advanced Computing signed a memorandum of understanding to roll out e-Sushrut@Clinic, a lightweight, cloud-based, ABDM-enabled hospital management system aimed at small and medium providers (Source: NHA and C-DAC, MoU coverage via PIB and ANI, 2025 to 2026). It is built down from C-DAC's flagship e-Sushrut HMIS, which is already in use at 17 AIIMS and more than 4,000 health facilities across the country (Source: C-DAC via NHA, 2025). Under the MoU, C-DAC maintains and upgrades the software while NHA provides facilitation and financial support, including cloud hosting and patient SMS costs.
Read what that does to a procurement conversation. A tier-2 hospital or a clinic chain now has a government-backed HMIS that already speaks ABDM, already handles HFR and HPR onboarding as part of getting started, and costs the facility nothing to host. Any AI vendor pitching into that segment is no longer competing against nothing. It is competing against a free, ABDM-native system of record that the health ministry is actively pushing.
This is why e-Sushrut compatibility is turning into a de facto procurement requirement rather than a nice-to-have. If a hospital has adopted or is evaluating e-Sushrut, the first question the committee asks an AI vendor is not "how accurate is your model." It is "does your product write into e-Sushrut, and does it respect the ABDM linkage e-Sushrut already establishes." A vendor who cannot answer that is asking the hospital to run two systems of record. No CIO signs up for that voluntarily.
The scale that makes this non-optional
The reason none of this can be deferred any longer is that the national record is no longer a pilot. ABDM has crossed 100 crore ABHA-linked health records, with the National Health Authority reporting that linked records doubled from roughly 50 crore in early 2025 to over 100 crore within about fifteen months (Source: National Health Authority, reported via DD News, 2026). Nearly 10 crore records are now being linked every two to three months [verify].
At that volume the longitudinal record stops being an aspiration and becomes the substrate. An AI product that generates clinical documentation but cannot contribute that documentation back into a patient's ABHA-linked record is producing orphan data. It works inside one building and dies at the building's edge. For a single-site clinic that might be tolerable. For a hospital group whose patients move between its own sites, and between its sites and the wider system, orphan data is a defect the buyer will eventually be forced to fix, and they would rather not buy it twice.
Where Nextdot sits, honestly
The temptation for any vendor writing this piece is to imply it has already done the hard part. Nextdot has not, and stating it plainly is more useful to a CIO than a claim that will collapse in the first technical call.
Nextdot's architectural position is interoperability rather than displacement: adaptable integration through MCPs and open APIs that connect to legacy and open HMIS, including a system of record a hospital did not choose and cannot replace. That is the correct posture for a market where e-Sushrut is now a live system of record for a growing share of facilities. An AI layer that assumes it will be the system of record is building for a world that no longer exists in this segment.
On the specific ABDM registries, Nextdot has not completed HFR, HPR or ABHA linkage integration, including sandbox work. WhatsApp-first appointment booking and management is built and live with small clinics at volumes up to roughly 100,000, and that is real, but it is not ABDM integration and should not be read as such. The honest map is this: the interoperability approach is proven, the registry and linkage engineering is analysis and roadmap, not deployment. A buyer evaluating any vendor, Nextdot included, should ask for the sandbox evidence and treat its absence as unfinished work rather than a formality.
What a CIO should actually require in the contract
Turn the above into procurement language and it comes down to four checks.
Require the vendor to state, per module, whether it operates against HFR and HPR identifiers or merely stores a text field that looks like one. These are different things and only one of them is ABDM-legible.
Require a demonstrated ABHA linkage flow in the ABDM sandbox before production, including consent capture and the document packaging to the required FHIR profiles. If the vendor cannot show it in sandbox, it does not exist yet, whatever the slide says.
Require a written answer on system-of-record coexistence. If the hospital runs e-Sushrut or any government HMIS, the AI product must write into it and respect its ABDM linkage, not shadow it.
Require the liability split to be named. Registry accuracy and consent are shared obligations. The hospital owns its HFR and HPR onboarding and its clinicians' identities. The vendor owns whether its product handles those identifiers correctly and whether its output packages into the record without corrupting it.
None of this is exotic. It is the difference between a product that lives inside the national health stack and one that produces data the stack cannot read.
Frequently asked questions
What is required for ABDM compliance?
For an AI or software vendor, ABDM compliance means operating correctly against three things: the Health Facility Registry (HFR) that identifies the facility, the Healthcare Professional Registry (HPR) that identifies the clinician signing output, and, where the product touches a longitudinal record, ABHA linkage that connects clinical documents to a patient's health identity under consent, using the FHIR profiles ABDM specifies. It is not a single certificate. It is three separate pieces of engineering with different owners and different failure modes.
What is HFR and HPR onboarding?
HFR onboarding registers a health facility in the Health Facility Registry and issues it an HFR ID, the prerequisite for connecting software into ABDM rails and appearing in national facility searches. HPR onboarding registers a healthcare professional in the Healthcare Professional Registry so they can issue ABDM-recognised prescriptions, lab orders and discharge summaries. The facility owns HFR onboarding, the professional owns HPR onboarding, and an AI vendor's product has to be able to operate against both.
Is e-Sushrut compatibility mandatory for hospital procurement?
It is not a written legal mandate, but it is becoming a de facto procurement requirement for the small and mid-size segment. The National Health Authority and C-DAC rolled out e-Sushrut@Clinic, a free, ABDM-enabled HMIS, and C-DAC's e-Sushrut is already in use at 17 AIIMS and more than 4,000 health facilities (Source: NHA and C-DAC, 2025). Where a facility has adopted it, an AI product that cannot write into e-Sushrut and respect its ABDM linkage forces the hospital to run two systems of record, which is a reason procurement committees now reject vendors early.
Does my AI product need ABHA integration?
It depends on what the product does. If it only handles a self-contained task inside one facility, such as appointment booking, it can function without ABHA linkage. If it generates clinical documentation that should become part of a patient's longitudinal record, then yes: without ABHA linkage that documentation is orphan data that lives inside one building and cannot travel. With ABDM having crossed 100 crore ABHA-linked health records (Source: National Health Authority via DD News, 2026), a multi-site hospital group will increasingly treat the absence of ABHA linkage as a defect to fix rather than a feature to skip.