ABDM Full Form, ABHA and the Building Blocks

ABDM stands for the Ayushman Bharat Digital Mission. It is the Government of India’s programme, run by the National Health Authority, to give every citizen a health account and let health records move between providers — with the patient’s consent, and never without it.

ABHA stands for Ayushman Bharat Health Account, and it is the piece a hospital meets first. It has two halves: an ABHA number, fourteen digits identifying one person, and an ABHA address in the form name@abdm, which is where that person’s records are delivered. The components around it are the two registries that identify the provider — the Health Facility Registry (HFR) for hospitals and the Healthcare Professionals Registry (HPR) for clinicians — and the Health Information Exchange and Consent Manager (HIE-CM), which moves a record only once the patient has agreed. Everything travels as HL7 FHIR R4.

That is the short answer. The rest of this page is the detail a hospital needs before it talks to a vendor: what the milestones mean, who is actually on the other end, and which of it is a requirement as opposed to a good idea.

ABDM full form, and what the words are doing

Ayushman Bharat is the umbrella name for the government’s health programmes, the best-known of which is the PM-JAY insurance scheme. Digital Mission is the part that concerns software. It was launched nationally in September 2021 after a pilot in six union territories, and it was called the National Digital Health Mission (NDHM) before that — you will still find the old acronym in older documents and in some vendors’ brochures.

What ABDM is not is a piece of software. There is no ABDM application a hospital installs. It is a set of specifications, registries and APIs that other people’s software connects to, which is why a hospital’s practical question is never “do we have ABDM” but “does our system speak it, and how far”.

Key components of ABHA, block by block

The diagram above in one list, with what each one is for:

• ABHA number — fourteen digits, one per person, usually created against Aadhaar or a driving licence. This is the identity everything else keys off.
• ABHA address — name@abdm, chosen by the person, and the destination records are sent to. One person may hold several addresses against one number.
• Health Facility Registry (HFR) — the national list of health facilities. A hospital registers here first; nothing else in ABDM is available to a facility that has not.
• Healthcare Professionals Registry (HPR) — the equivalent for clinicians, so that the identity of the doctor who signed a record travels with the record.
• Health Information Exchange and Consent Manager (HIE-CM) — the consent machinery and the route a record takes. It is the block that makes the whole thing a network rather than a filing cabinet.
• HL7 FHIR R4 — the format. Records that are not structured to it cannot be exchanged, whatever else a system does well.

Alongside these sit the Unified Health Interface for booking and teleconsultation, a drug registry, and the health claims exchange for insurance. A hospital buying its first system does not need to have an opinion about those yet.

ABDM M1, M2 and M3: what the milestones mean

The milestones are stages a software product is tested against in the ABDM sandbox before it is allowed into production. They describe the vendor’s system, not the hospital.

• M1 — identity. The product can create and verify an ABHA number and attach it to the right patient at registration.
• M2 — Health Information Provider (HIP). The product can create a care context after a visit, answer a discovery request from a consent manager, honour a consent artefact and hand over an encrypted FHIR bundle. This is the one that makes a hospital’s records shareable.
• M3 — Health Information User (HIU). The product can ask for consent and pull records that another provider holds, so a clinician can read a history created elsewhere.

There is a fourth stage, M4, concerning digital claims over the health claims exchange, which matters to hospitals doing volume insurance work.

The useful thing to do with this list is to ask a vendor which milestones their product has passed, and when — not whether they “support ABDM”, which is a sentence with no content. The demo questions post has the same treatment for the rest of the feature list.

What it takes to build an ABDM HIP

For the reader who is evaluating rather than building, this is the shape of the work behind an M2 claim, and it is worth knowing because it explains why the claim is often thinner than it sounds:

1. Register the facility on the HFR and obtain the identifiers the APIs key off.
2. Link a visit to the patient’s ABHA address as a care context — the record is not shared at this point, only announced.
3. Answer discovery and link requests from a consent manager, matching the patient the consent manager is asking about to the patient in your own database.
4. Accept a consent artefact, check it is valid and in date, and refuse when it is not.
5. Assemble the record as a FHIR R4 bundle, encrypt it and transmit it to the requester.

Step 3 is where most of the real difficulty lives, and it is a data-quality problem rather than an API problem: a hospital whose patient records carry inconsistent names, ages and phone numbers cannot reliably match them to anything. That work has to happen before the integration, and it is the single best argument for getting the basics of registration and record-keeping right early.

Who are the end users of ABDM?

Four groups, with different stakes:

• Patients hold the ABHA number, choose the address, and grant or refuse every consent. They are the only party that can move a record.
• Health facilities register on the HFR and act as the provider of records, the user of records, or both.
• Healthcare professionals register on the HPR so that their verified identity attaches to what they sign.
• Software companies do the integration and meet the sandbox. They are not served by the mission; they exist to make it work for the other three.

If you are reading this as a hospital, you are the second group, and almost everything you are asked to do is either a registration or a procurement decision.

What people mean by “ABDM compliance”

The phrase is used loosely, and usually means some combination of three separate things: the facility is registered on the HFR; the hospital’s software has passed the relevant milestones; and clinical records are being kept in a structured, FHIR-compatible form rather than as scanned paper. Only the first is entirely within a hospital’s own control.

Obligations are a different question from capability, and they depend on which government schemes a facility takes part in rather than on ABDM in the abstract. Those rules change. Check the current position with the National Health Authority or your state health authority rather than relying on any vendor’s summary of it, this one included. This post explains a government standard; it is not legal advice, and nothing here tells you what your hospital is obliged to do.

ABDM insights: checking the numbers yourself

The National Health Authority publishes a public dashboard of adoption — ABHA numbers created, facilities on the HFR, professionals on the HPR, records linked — with a state-level breakdown. It is worth ten minutes before any vendor conversation, for one reason: it lets you check an adoption figure you are quoted against the published one. That applies to figures we quote as much as to anyone else’s.

What a hospital can usefully do now

Nothing on this list requires a purchase.

1. Register on the HFR. It is free, it is the prerequisite for everything else, and it can be done from the ABDM portal with the facility’s basic details.
2. Look at your own data quality. Pull fifty recent registrations and count how many have a usable name, age and phone number. That number predicts how the eventual integration will go far better than any feature list does.
3. Find out where your records actually are. Structured fields in a database can be mapped to FHIR. Scanned images and free-text notes cannot, and that is a migration, not a setting.
4. Ask your current vendor the milestone question — which milestones, certified when, in production with how many facilities. Write the answers down.
5. Train registration staff on ABHA before you need to. Verifying an ABHA number at the counter is a workflow change, and workflow changes are slower than software changes.

If you are also choosing a system, the buyer’s guide and the features checklist cover the rest of the decision, and the glossary covers the vocabulary.

Where Arko Care sits, precisely

Arko Care is ABDM-ready: clinical records are structured to HL7 FHIR R4, which is the part that has to be true before any exchange is possible. ABHA number creation, Health Locker and Consent Manager are not available today, and we make no claim to any milestone. Our integrations page states the same thing in the same words, and will change when the position changes.

We are telling you this on a page that ranks for ABDM questions because the alternative — a vaguer sentence that lets you assume more — is how hospitals end up buying an integration that does not exist. If you want to talk about where ABDM fits into a system you are choosing, get in touch.