Back to Blogs
Healthcare

What ABDM stack integration actually takes

Oct 5, 2026| 8 min read|Nextdot Digital Solutions Pvt. Ltd.
<!-- SEO title: What ABDM Stack Integration Actually Takes Subtitle: Building on top of a government HMIS: what ABDM stack integration actually takes Primary query: what does ABDM stack integration involve, HFR HPR ABHA Vertical and Buyer: AI Engineering (Healthcare AI). Everyone: hospital CIO, CTO, Head of Digital, Group COO. Written as informed analysis, not field notes. Sources used: NRCES, FHIR Implementation Guide for ABDM v6.5.0, published 8 May 2025 (nrces.in/ndhm/fhir/r4); NHA ABDM sandbox integration and exit process, as reproduced in the Open Healthcare Network ABDM implementer documentation (docs.coronasafe.network), including the 5 August 2022 move of functional testing to NHA-empanelled agencies, and its guidance on facilities using more than one ABDM-compatible system (docs.coronasafe.network, implementers guide, accessed 2026-09-30); e-Sushrut@Clinic launch by the Union Health Minister, 29 June 2026 (PIB release, pib.gov.in PRID=2278996). Exit process primary NHA page (sandbox.abdm.gov.in) returned 503 on 2026-09-30; reconfirm before publishing. Status: FINAL DRAFT 2026-09-30, decisions applied, ready for Ayush read --> # What ABDM stack integration actually takes ABDM stack integration means taking a health software system through three milestones in the National Health Authority sandbox: M1 to capture and verify ABHA numbers against a facility registered in the Health Facility Registry, M2 to act as a Health Information Provider that shares consented FHIR records, and M3 to act as a Health Information User that requests them. After that comes an exit process of functional testing, a security audit and a committee review before production credentials are issued. The APIs are the easy part. The hard part is mapping your data model onto the national one and deciding which system in the hospital holds the ABDM role. Our earlier piece, "ABDM and e-Sushrut: What the Government Stack Now Expects From Every AI Vendor", covered what ABDM expects from an AI vendor. This one goes a layer down, into the build. It is informed analysis: Nextdot has not completed HFR, HPR or ABHA linkage work, including in the sandbox. It is the map we would want before starting one, and the map a CIO should hold any vendor to. ## The milestones, in the order they break The NHA structures integration as milestones, and each one changes what your system is. M1 makes your system an identity participant. At registration, it captures a patient's ABHA number or ABHA address, verifies it, and stores the linking token the gateway returns. The facility itself has to exist in the sandbox Health Facility Registry first, because every later transaction is attributed to a facility. M2 makes your system a Health Information Provider, or HIP. After a consultation or an investigation, it creates a care context: a labelled bundle of records the patient can later discover and share. It answers discovery requests from the consent manager, acknowledges consent artefacts, and pushes encrypted health records in FHIR format to whoever the patient approved. M3 flips the role. Your system becomes a Health Information User, or HIU, that raises consent requests, receives records from other facilities, and presents them to a clinician. M1 alone gives you identity and puts no record on the national rails. M2 is where documentation becomes portable, and where most of the engineering lives. ## Where M2 actually hurts M2 looks like an API exercise on paper. In practice it forces four decisions that most HMIS data was never designed to answer. The first is the FHIR mapping. The NRCES FHIR Implementation Guide for ABDM, version 6.5.0, published on 8 May 2025, defines seven clinical document profiles (OP consultation, prescription, diagnostic report, discharge summary, immunization, wellness and a general health document record) plus an invoice profile, built on FHIR R4 (Source: NRCES, FHIR Implementation Guide for ABDM v6.5.0, 8 May 2025). A discharge summary usually lives as a free-text template in the HMIS, while the profile expects structured sections, coded diagnoses and a practitioner reference. Someone has to decide, field by field, what maps and what stays narrative. That is clinical informatics work, and it needs clinician time as well as developer time. The second is care context granularity. Is a care context one visit, one admission or one lab order? The answer shapes what another hospital sees, and it is painful to change once production data exists. The third is identity reconciliation. The same patient arrives with an ABHA number at one visit, an ABHA address at the next, and nothing at the third. The HMIS already has its own medical record number. Merging those without attaching one person's discharge summary to another's ABHA is the defect that matters most, because on a national rail a misattributed record travels. The fourth is the asynchronous architecture. ABDM runs through a gateway with callbacks. Your system sends a request and receives the answer later, at an endpoint you expose. Timeouts, retries, duplicate callbacks and consent artefacts that expire mid-transfer all need explicit handling, and each needs a log line you can find when a patient complains. ## The exit process is a project of its own Passing the milestones in the sandbox does not put you in production. The NHA's published exit process has four stages. Functional and non-functional testing against NHA test cases, which since 5 August 2022 has been carried out on a chargeable basis by NHA-empanelled agencies. Security testing by an STQC or CERT-In empanelled agency, ending in a Safe-to-Host certificate. A review by the approval committee, with the testing report, the certificate and a summary template. Then production access, registration of the partnering facility in the Health Facility Registry, and an update of the production bridge ID in that facility's HFR profile (Source: NHA sandbox exit process, via Open Healthcare Network ABDM documentation, accessed 2026-09-30). Two things follow for a buyer. Any change to ABHA, consent or record exchange flows after certification is a change to a certified system, and your vendor's release process should treat it that way. And the exit process depends on outside agencies and a committee, so a vendor quoting an ABDM go-live date without naming where they sit in that queue is guessing. We do not publish a timeline for this path because we have not run it. ## HFR and HPR are the parts people call simple HFR and HPR onboarding is the facility's and the clinician's job. What the software owns is using those identifiers correctly. A practitioner reference in a FHIR bundle should resolve to a real HPR identity. A record should carry the HFR identity of the facility that produced it, which matters when one HMIS instance serves several sites. Storing an HPR number as free text on a user profile is different from binding every signed document to it, and procurement questionnaires should ask which one a vendor does. ## The question nobody asks: whose HIP is it? In most hospitals the HMIS is the system of record, so it is the natural HIP. It holds the encounter, the orders and the signed documents. An AI layer produces or reads clinical content but usually does not own the encounter. That leaves two architectures. In the first, the AI layer writes its output back into the HMIS, the clinician signs it there, and the HMIS shares it through its own M2 integration. The AI vendor never touches the ABDM gateway directly. In the second, the AI product registers as its own HIP software for the facility and pushes records itself. The first is simpler, easier to audit and keeps one source of truth per record. The second risks the same encounter appearing as two care contexts from two systems, with two slightly different versions of the note. ABDM does allow one facility to use more than one compatible system, for example one for OPD records and another for the lab, but registering a second system against the same facility is not handled through the APIs and goes through NHA integration support (Source: Open Healthcare Network ABDM implementer documentation, accessed 2026-09-30). Running several HIP systems side by side is a design decision the hospital should make deliberately. Nextdot's position is that the system that owns the encounter should own the ABDM role, and everything else should write into it. This is also why e-Sushrut changes the integration question for the small clinics and sub-centres it targets. e-Sushrut@Clinic, launched by the Union Health Minister on 29 June 2026 (Source: Press Information Bureau, Ministry of Health and Family Welfare release, 29 June 2026), arrives ABDM-enabled. In a facility running it, the HIP role is already taken by a government system. An AI product in that facility has one sensible path, which is to write into e-Sushrut and let e-Sushrut carry the ABDM exchange. How hard that is depends on what interfaces e-Sushrut exposes to third-party software, so a buyer should ask any vendor claiming e-Sushrut compatibility to show the interface they used and who granted access to it. ## Where Nextdot stands Nextdot's architecture position is interoperability with the systems a hospital already runs. We build integration through MCPs and open APIs that connect to legacy and open HMIS, including a system of record the hospital did not choose. That position fits the first architecture above: the HMIS owns the encounter and the ABDM role, and the AI layer writes into it. On ABDM itself, we have not completed HFR, HPR or ABHA linkage work, including sandbox. Our WhatsApp-first appointment booking for small clinics is live and handles volumes up to roughly 100,000, and it is a separate thing from ABDM integration. The checks below apply to every vendor, including us. ## What to ask a vendor before you sign Ask which milestones, M1, M2 or M3, the product has completed in the sandbox, and ask to see the flows run live against the sandbox. Ask whether the product has cleared the NHA exit process, and for the functional testing report and Safe-to-Host certificate if it has. Ask which system holds the HIP role for your facility after go-live, and how the vendor prevents one encounter from surfacing as two care contexts. Ask how the product reconciles ABHA numbers, ABHA addresses and your own medical record numbers, and what happens when they conflict. Ask which NRCES FHIR profiles and which IG version the product emits, and who on the vendor's side signs off the clinical mapping. ## FAQ **What does ABDM integration involve?** ABDM integration means taking health software through three NHA milestones in the ABDM sandbox: M1 for capturing and verifying ABHA numbers at a facility registered in the Health Facility Registry, M2 for acting as a Health Information Provider that shares consented FHIR records, and M3 for acting as a Health Information User that requests records from other facilities. After the milestones, the software goes through functional testing by an NHA-empanelled agency, a security audit by an STQC or CERT-In empanelled agency ending in a Safe-to-Host certificate, and a committee review before production credentials are issued. **What is HFR and HPR onboarding?** HFR onboarding registers a health facility in the Health Facility Registry and gives it an HFR ID, which every ABDM transaction is attributed to. HPR onboarding registers a professional in the Healthcare Professional Registry so documents they sign carry a verifiable identity. The software's job is to bind records to those identifiers correctly. **How do you link an ABHA number?** At registration, the hospital system captures the patient's ABHA number or ABHA address, verifies it, usually by OTP or a QR scan, and stores the linking token returned by the ABDM gateway. After each visit, the system creates a care context linked to that ABHA identity, which the patient can later share through a consent manager. **How hard is e-Sushrut integration?** e-Sushrut is already ABDM-enabled, so in a facility running it, e-Sushrut holds the ABDM exchange role. An AI product should write its output into e-Sushrut and let e-Sushrut share it, which avoids duplicate records. The difficulty depends on the interfaces e-Sushrut exposes to outside software, so ask any vendor claiming compatibility to show the interface they used.

ABDM stack integration means taking a health software system through three milestones in the National Health Authority sandbox: M1 to capture and verify ABHA numbers against a facility registered in the Health Facility Registry, M2 to act as a Health Information Provider that shares consented FHIR records, and M3 to act as a Health Information User that requests them. After that comes an exit process of functional testing, a security audit and a committee review before production credentials are issued. The APIs are the easy part. The hard part is mapping your data model onto the national one and deciding which system in the hospital holds the ABDM role.

Our earlier piece, "ABDM and e-Sushrut: What the Government Stack Now Expects From Every AI Vendor", covered what ABDM expects from an AI vendor. This one goes a layer down, into the build. It is informed analysis: Nextdot has not completed HFR, HPR or ABHA linkage work, including in the sandbox. It is the map we would want before starting one, and the map a CIO should hold any vendor to.

The milestones, in the order they break

The NHA structures integration as milestones, and each one changes what your system is.

M1 makes your system an identity participant. At registration, it captures a patient's ABHA number or ABHA address, verifies it, and stores the linking token the gateway returns. The facility itself has to exist in the sandbox Health Facility Registry first, because every later transaction is attributed to a facility.

M2 makes your system a Health Information Provider, or HIP. After a consultation or an investigation, it creates a care context: a labelled bundle of records the patient can later discover and share. It answers discovery requests from the consent manager, acknowledges consent artefacts, and pushes encrypted health records in FHIR format to whoever the patient approved.

M3 flips the role. Your system becomes a Health Information User, or HIU, that raises consent requests, receives records from other facilities, and presents them to a clinician.

M1 alone gives you identity and puts no record on the national rails. M2 is where documentation becomes portable, and where most of the engineering lives.

Where M2 actually hurts

M2 looks like an API exercise on paper. In practice it forces four decisions that most HMIS data was never designed to answer.

The first is the FHIR mapping. The NRCES FHIR Implementation Guide for ABDM, version 6.5.0, published on 8 May 2025, defines seven clinical document profiles (OP consultation, prescription, diagnostic report, discharge summary, immunization, wellness and a general health document record) plus an invoice profile, built on FHIR R4 (Source: NRCES, FHIR Implementation Guide for ABDM v6.5.0, 8 May 2025). A discharge summary usually lives as a free-text template in the HMIS, while the profile expects structured sections, coded diagnoses and a practitioner reference. Someone has to decide, field by field, what maps and what stays narrative. That is clinical informatics work, and it needs clinician time as well as developer time.

The second is care context granularity. Is a care context one visit, one admission or one lab order? The answer shapes what another hospital sees, and it is painful to change once production data exists.

The third is identity reconciliation. The same patient arrives with an ABHA number at one visit, an ABHA address at the next, and nothing at the third. The HMIS already has its own medical record number. Merging those without attaching one person's discharge summary to another's ABHA is the defect that matters most, because on a national rail a misattributed record travels.

The fourth is the asynchronous architecture. ABDM runs through a gateway with callbacks. Your system sends a request and receives the answer later, at an endpoint you expose. Timeouts, retries, duplicate callbacks and consent artefacts that expire mid-transfer all need explicit handling, and each needs a log line you can find when a patient complains.

The exit process is a project of its own

Passing the milestones in the sandbox does not put you in production. The NHA's published exit process has four stages. Functional and non-functional testing against NHA test cases, which since 5 August 2022 has been carried out on a chargeable basis by NHA-empanelled agencies. Security testing by an STQC or CERT-In empanelled agency, ending in a Safe-to-Host certificate. A review by the approval committee, with the testing report, the certificate and a summary template. Then production access, registration of the partnering facility in the Health Facility Registry, and an update of the production bridge ID in that facility's HFR profile (Source: NHA sandbox exit process, via Open Healthcare Network ABDM documentation, accessed 2026-09-30).

Two things follow for a buyer. Any change to ABHA, consent or record exchange flows after certification is a change to a certified system, and your vendor's release process should treat it that way. And the exit process depends on outside agencies and a committee, so a vendor quoting an ABDM go-live date without naming where they sit in that queue is guessing. We do not publish a timeline for this path because we have not run it.

HFR and HPR are the parts people call simple

HFR and HPR onboarding is the facility's and the clinician's job. What the software owns is using those identifiers correctly. A practitioner reference in a FHIR bundle should resolve to a real HPR identity. A record should carry the HFR identity of the facility that produced it, which matters when one HMIS instance serves several sites. Storing an HPR number as free text on a user profile is different from binding every signed document to it, and procurement questionnaires should ask which one a vendor does.

The question nobody asks: whose HIP is it?

In most hospitals the HMIS is the system of record, so it is the natural HIP. It holds the encounter, the orders and the signed documents. An AI layer produces or reads clinical content but usually does not own the encounter.

That leaves two architectures. In the first, the AI layer writes its output back into the HMIS, the clinician signs it there, and the HMIS shares it through its own M2 integration. The AI vendor never touches the ABDM gateway directly. In the second, the AI product registers as its own HIP software for the facility and pushes records itself.

The first is simpler, easier to audit and keeps one source of truth per record. The second risks the same encounter appearing as two care contexts from two systems, with two slightly different versions of the note. ABDM does allow one facility to use more than one compatible system, for example one for OPD records and another for the lab, but registering a second system against the same facility is not handled through the APIs and goes through NHA integration support (Source: Open Healthcare Network ABDM implementer documentation, accessed 2026-09-30). Running several HIP systems side by side is a design decision the hospital should make deliberately. Nextdot's position is that the system that owns the encounter should own the ABDM role, and everything else should write into it.

This is also why e-Sushrut changes the integration question for the small clinics and sub-centres it targets. e-Sushrut@Clinic, launched by the Union Health Minister on 29 June 2026 (Source: Press Information Bureau, Ministry of Health and Family Welfare release, 29 June 2026), arrives ABDM-enabled. In a facility running it, the HIP role is already taken by a government system. An AI product in that facility has one sensible path, which is to write into e-Sushrut and let e-Sushrut carry the ABDM exchange. How hard that is depends on what interfaces e-Sushrut exposes to third-party software, so a buyer should ask any vendor claiming e-Sushrut compatibility to show the interface they used and who granted access to it.

Where Nextdot stands

Nextdot's architecture position is interoperability with the systems a hospital already runs. We build integration through MCPs and open APIs that connect to legacy and open HMIS, including a system of record the hospital did not choose. That position fits the first architecture above: the HMIS owns the encounter and the ABDM role, and the AI layer writes into it.

On ABDM itself, we have not completed HFR, HPR or ABHA linkage work, including sandbox. Our WhatsApp-first appointment booking for small clinics is live and handles volumes up to roughly 100,000, and it is a separate thing from ABDM integration.

The checks below apply to every vendor, including us.

What to ask a vendor before you sign

Ask which milestones, M1, M2 or M3, the product has completed in the sandbox, and ask to see the flows run live against the sandbox.

Ask whether the product has cleared the NHA exit process, and for the functional testing report and Safe-to-Host certificate if it has.

Ask which system holds the HIP role for your facility after go-live, and how the vendor prevents one encounter from surfacing as two care contexts.

Ask how the product reconciles ABHA numbers, ABHA addresses and your own medical record numbers, and what happens when they conflict.

Ask which NRCES FHIR profiles and which IG version the product emits, and who on the vendor's side signs off the clinical mapping.

Frequently asked questions

What does ABDM integration involve?

ABDM integration means taking health software through three NHA milestones in the ABDM sandbox: M1 for capturing and verifying ABHA numbers at a facility registered in the Health Facility Registry, M2 for acting as a Health Information Provider that shares consented FHIR records, and M3 for acting as a Health Information User that requests records from other facilities. After the milestones, the software goes through functional testing by an NHA-empanelled agency, a security audit by an STQC or CERT-In empanelled agency ending in a Safe-to-Host certificate, and a committee review before production credentials are issued.

What is HFR and HPR onboarding?

HFR onboarding registers a health facility in the Health Facility Registry and gives it an HFR ID, which every ABDM transaction is attributed to. HPR onboarding registers a professional in the Healthcare Professional Registry so documents they sign carry a verifiable identity. The software's job is to bind records to those identifiers correctly.

How do you link an ABHA number?

At registration, the hospital system captures the patient's ABHA number or ABHA address, verifies it, usually by OTP or a QR scan, and stores the linking token returned by the ABDM gateway. After each visit, the system creates a care context linked to that ABHA identity, which the patient can later share through a consent manager.

How hard is e-Sushrut integration?

e-Sushrut is already ABDM-enabled, so in a facility running it, e-Sushrut holds the ABDM exchange role. An AI product should write its output into e-Sushrut and let e-Sushrut share it, which avoids duplicate records. The difficulty depends on the interfaces e-Sushrut exposes to outside software, so ask any vendor claiming compatibility to show the interface they used.