What is ABDM? The Ayushman Bharat Digital Mission, explained

01What ABDM is

The Ayushman Bharat Digital Mission is the Government of India’s programme for building a national digital health ecosystem. It is implemented by the National Health Authority (NHA), the same body that runs the PM-JAY health insurance scheme, under the Ministry of Health and Family Welfare.

It began as the National Digital Health Mission, piloted in six union territories from August 2020, and was launched across the country under its current name on 27 September 2021. Older documents, API paths and app names still say “NDHM”; they mean the same programme.

The easiest way to understand ABDM is by analogy with India’s payments stack. UPI did not replace banks or hold anyone’s money. It defined shared addresses, a common switch and a rule for authorising a transfer, and left the accounts with the banks. ABDM does the same for health records: the hospitals, labs and clinics keep the records; ABDM provides the identifiers, the directories and the consent rules that let a record move from one of them to another.

02The problem it addresses

A patient in India typically sees many providers over a lifetime: a government primary health centre, a private clinic, a diagnostic chain, a district hospital, a specialist in another city. Each keeps its own records, in its own software or on paper, keyed on its own registration number.

The result is familiar to anyone who has worked a hospital front desk. The patient arrives with a plastic bag of reports, or with none. Tests are repeated because the earlier result cannot be found or trusted. A discharge summary from one hospital is retyped, or photographed, into the system of the next. Allergies and long-term medication are reconstructed from memory.

Point-to-point integration does not fix this. A hospital could build an interface to one lab, but not to every lab, clinic and hospital a patient might have visited — and nobody could build them all. What is missing is shared infrastructure: a way to identify the same patient everywhere, a way to know that a facility or doctor is genuine, a common format for the record, and a trustworthy way for the patient to authorise sharing. ABDM provides those four things, and each provider integrates once.

03The building blocks

ABDM is several components rather than one system. The names come up constantly in scheme circulars and vendor conversations, so they are worth learning once.

There is also a Unified Health Interface (UHI), aimed at discovering and booking health services across apps. It is a separate strand from records exchange and most hospital integrations do not start there.

04ABHA: the patient’s identity

Every exchange on the network needs a reliable answer to “which person is this?” Hospital registration numbers cannot provide it, because each hospital issues its own. ABHA is the shared answer.

An ABHA comes in two parts, and the difference matters in practice:

• The ABHA number is a 14-digit identifier issued once and never changed. It is the account itself.
• The ABHA address is a readable handle chosen by the citizen, in the form asha.devi@abdm. It is what consent and record sharing are keyed on, and one person can hold more than one.

A citizen can create an ABHA themselves in a PHR app, or at a facility’s registration counter. The common route uses Aadhaar with an OTP to the linked mobile, which produces a KYC-verified account; a mobile-number route exists for people who do not want to use Aadhaar. At a busy OPD, facilities can also let patients share their ABHA profile by scanning a QR code at the counter instead of dictating details.

Once an ABHA is recorded against a patient in the hospital’s own system, records from that hospital can be linked to it — and the citizen can see them in their PHR app. The hospital’s own MRN does not go away; ABHA sits alongside it.

If you build or buy software that registers patients, this is the first thing it has to support. Our ABHA integration guide goes into the enrolment flows.

05The registries: HFR and HPR

A patient agreeing to share their records only means something if they know who is receiving them. The two registries exist so that every party on the network is a verified, identifiable entity rather than a URL.

Health Facility Registry

HFR lists health facilities of every kind, public and private, and every system of medicine. Each facility gets an HFR ID. That ID is not just a listing: it is what a facility’s software uses to act on the network. A lab cannot publish reports to a patient’s PHR app, or a hospital request records, unless the facility is in HFR and its services are linked to the software acting for it. Details are in the HFR integration guide.

Healthcare Professional Registry

HPR is the equivalent for people. A doctor or nurse creates an HPR ID and then files their professional record — council registration, qualifications, where they work — which is verified by the relevant council and facility. It lets a record carry a verifiable author, and lets facilities declare who practises there. See the HPR integration guide.

06How a record moves: consent

Consent is the part of ABDM that is genuinely new, and the part most often misunderstood. It is easiest to follow with an example.

Suppose a patient had blood tests at a diagnostic lab in Pune last year and is now seeing a cardiologist at a hospital in Nashik. Both are on ABDM, and both have never exchanged data before.

1. The lab links the report. When the report was issued, the lab’s software linked it to the patient’s ABHA as a care context — one episode of care. The patient could see it listed in their PHR app. The report itself stayed on the lab’s systems.
2. The hospital asks. The cardiologist’s software raises a consent request to the consent manager: this patient, for the purpose of treatment, diagnostic reports and prescriptions, from the last two years.
3. The patient decides. The request appears in the patient’s PHR app. They can approve it, refuse it, or approve a narrower version — only lab reports, only the last six months.
4. A consent artefact is issued. Approval produces a signed record of exactly what was agreed: who may receive what, from which provider, over which dates, and until when.
5. The records travel. The hospital asks for the data under that artefact. The lab checks the artefact, selects only the matching records, encrypts them for the hospital, and sends them. The consent manager and the gateway in between never see the content.
6. The patient can change their mind. A consent can be revoked from the PHR app. From then on the lab must refuse to share under it, and the hospital must stop using what it received under the terms of the artefact.

Two things follow from this design. First, the patient, not either provider, is the one who connects the two. Second, a consent is a precise scope, not a yes-or-no switch — which is why the technical work of honouring it is real. The end-to-end technical walkthrough shows what each step looks like on the wire.

07HIPs and HIUs

In that example the lab acted as a Health Information Provider (HIP): it creates records, links them to ABHAs, and shares them under consent. The hospital acted as a Health Information User (HIU): it requests records under consent and receives them.

These are roles, not types of organisation. A standalone lab is usually only a HIP; it publishes results and rarely needs anyone else’s. A hospital is usually both: a HIP for its own OPD notes, prescriptions and discharge summaries, and a HIU when a clinician wants a patient’s history from elsewhere. A PHR app sits on the citizen’s side and is neither in the same sense.

The distinction decides how much integration a product needs. We cover it in depth in ABDM HIP vs HIU, and on the HIP and HIU pages.

08What it means for hospitals, labs and software vendors

Is it compulsory?

For private providers, joining ABDM is voluntary. In practice the pressure to join comes from elsewhere: government health schemes such as PM-JAY and CGHS increasingly expect empanelled providers to be ABDM-enabled, and state programmes have their own expectations. The specifics vary by scheme and change over time, so check the current circulars for the schemes that matter to you rather than relying on a vendor’s summary.

Incentives

NHA launched the Digital Health Incentive Scheme (DHIS) in January 2023 to reward facilities and digital solution companies for ABDM-linked transactions. It has been revised several times and was last extended to March 2026. Whether it is still running, and on what terms, is something to confirm on abdm.gov.in before it enters a business case.

What the work actually is

For a facility, joining means registering in HFR, getting its key staff into HPR, and using software that speaks ABDM. For the software, it means integrating with the ABDM gateway and passing NHA’s certification. NHA certifies this in stages called milestones — ABHA first, then sharing records, then requesting them — and a product only claims the ones it needs. ABDM milestones M1 to M4 explains each and what stands between the sandbox and production.

Most facilities will not integrate directly: their HMIS, EMR or LIMS vendor does, once, for all of its customers. If you are that vendor, the guide to integrating ABDM with an HMIS is the practical starting point. If you run a hospital, the question to ask your vendor is which milestones their product is certified for in production, not whether it “supports ABDM”.

09What ABDM is not

A few misconceptions come up often enough to address directly.

• It is not an EMR or HMIS. ABDM does not provide software to run a hospital. Providers keep their own systems; ABDM connects them.
• It is not an insurance scheme. PM-JAY and ABDM share the “Ayushman Bharat” name and the same implementing authority, but an ABHA is a health account, not an insurance entitlement. A patient may have either, both or neither.
• It is not a national records database. There is no central copy of anyone’s history to be browsed or breached.
• It is not a reason to refuse care. ABHA is voluntary for citizens, and a facility’s workflow has to work for patients who decline one.
• It is not a file transfer. Records move as structured FHIR documents, so a receiving system can read a diagnosis or a lab value rather than just display a PDF. The FHIR integration page covers the formats.

10Where to go from here

If you are evaluating ABDM for a hospital, start with which roles you need — HIP, HIU or both — and which schemes you participate in. Our page for hospitals walks through the practical side; labs have a shorter path.

If you build health software, read the technical walkthrough next. It explains the gateway, callbacks, consent artefacts and encryption, and where teams most often get stuck. Swastik’s ABDM connector is one way to take that protocol work off your plate; the concepts in this guide apply however you choose to build.