ABDM and ABHA, without the acronym soup.

The four registries, and why the order matters

ABDM is built on registries. Nothing else in it works until the relevant ones are in place, and hospitals routinely discover this in the wrong order, usually after buying software.

ABHA (Ayushman Bharat Health Account)

The patient’s identity. A 14-digit number, plus an address that looks like an email. Everything about a patient in ABDM hangs off it, and it is created or verified at your registration desk.

HFR (Health Facility Registry)

Your facility’s identity. Without a Facility ID, records cannot be attributed to you, and no incentive can be paid to you. This is the first thing to do and the one most often left until last.

HPR (Healthcare Professionals Registry)

Your clinicians’ identities. A record signed by a registered professional is worth something; one signed by an unregistered account is not. Enrollment needs each doctor’s own verification, so start early, because it is not an administrative task you can complete on their behalf.

PHR (Personal Health Record)

The patient’s own app, where they see what has been shared and grant or refuse consent. You do not control it, and that is the point.

The milestones, in plain terms

ABDM integration is described in milestones. They are not marketing tiers; each one is a different technical capability with its own certification.

Milestone 1: identity

Create or verify an ABHA number at registration, and link it to the patient’s record in your system. This is where every hospital starts.

Milestone 2: Health Information Provider

Publish “care contexts” so a patient’s app knows you hold records for them, and produce those records as standard FHIR bundles when consent is granted.

Milestone 3: Health Information User

Request records from other facilities. The request carries a named clinician’s registration number to the patient, which is what they read when deciding, so asking is a doctor’s act rather than a receptionist’s.

Milestone 4: registries

Facility and professional registry enrollment, verification and amendment, handled from inside your software rather than on a separate portal.

What “ABDM ready” means when a vendor says it

Very little, on its own. The phrases in circulation, ABDM enabled, ABDM ready, ABDM compliant and ABDM certified, are not interchangeable, and only the last one has a definition anybody can check.

Certification requires functional testing with the National Health Authority, a security audit certificate from a CERT-In empanelled auditor, and Health Tech Committee approval. A vendor that has all three can name them. A vendor that says “certified” and cannot produce them is telling you something else.

The question worth asking is narrower and harder to dodge: has a health record ever been exchanged through your system in production, in either direction? Sandbox verification is real engineering work and it is not the same answer.

Our own position, since you will ask

Nirogix has built Milestones 1 to 4 and verified them in the NHA sandbox. None of it is certified. No health record has been exchanged with ABDM in production, in either direction, in any environment.

That is why every ABDM capability on this site is marked planned rather than built. Availability here means you can use it, not that we wrote it. We would rather lose a comparison on that sentence than win one and be found out during implementation.

Consent is the part people underestimate

ABDM is consent-first, and the design consequences run deeper than a checkbox. Consent is re-checked at the moment records are sent, not at the moment they were requested. Records received from another facility are held under the consent that brought them and are meant to be deleted when it ends.

There is a subtler point that good implementations get right: what your front desk is allowed to see about a consent request. Knowing that a request is pending is operationally useful. Knowing which facility it went to is a clinical disclosure, because a source name like “oncology center” is a diagnosis by implication, and so is a record count, which is a proxy for how ill someone has been.

A practical order of work

If you are starting from nothing, this sequence wastes the least time.

1. Register the facility in the HFR

Everything else attributes to this. Do it first even if software is months away.

2. Get your doctors into the HPR

It needs each of them individually, so it takes calendar time rather than effort.

3. Complete KYC and bank details

Required before any incentive can be paid, and easy to leave undone.

4. Make ABHA part of registration

A workflow change more than a software one. Front-desk training decides whether it happens.

5. Then worry about record sharing

Milestones 2 and 3 matter once the first four are real. Before that they are theoretical.