ABDM & ABHA
ABDM integration in an HMIS —
what it actually means.
'ABDM-ready' is claimed by almost every hospital software vendor in India and means something different each time. This page sets out what the programme requires of a hospital system, and states plainly where our own work stands.
Our status, stated plainly
Polynexus is not ABDM-certified, ABDM-approved or ABDM-empanelled. Polynexus is developing Polynexus HMIS’s integration with the ABDM ecosystem.
The platform’s backend has API endpoints for ABHA linking, consent requests, health record fetch and NHCX transactions, along with FHIR export — that is a fact about what has been built into the system, not a claim that ABDM workflows are a finished, supported, customer-ready feature today. A hospital evaluating us should treat ABDM as in progress, ask us for the current position on your specific requirement, and not plan a compliance deadline around it without that conversation.
In short
The Ayushman Bharat Digital Mission (ABDM) is the Government of India programme for a national digital health ecosystem. It defines a health account for each citizen (ABHA), a consent framework governing who may access a person’s health records, registries of health facilities and professionals, and standard data formats — principally FHIR — so records can move between systems.
For a hospital, ABDM integration means the hospital’s own system can link a patient to their ABHA, request and honour consent before sharing records, and express those records in a form other systems can read.
The pieces
What a hospital system has to be able to do
These are the capabilities the programme is built around. The exact specification is set by the National Health Authority and changes over time — always check a vendor's claims against the current version.
ABHA linking
Associate a patient in the hospital system with their Ayushman Bharat Health Account. In practice this means initiating a link with an identifier, verifying an OTP the patient receives, and being able to check whether the link succeeded.
Consent
Records are not shared because a hospital has them. A consent request is raised, the patient grants or refuses it, and access follows that decision. A system that shares records without this is not ABDM-aligned regardless of what it claims.
Health record fetch
Where a patient has consented, records held elsewhere can be fetched into the treating hospital’s view — which is the actual point of the programme for a clinician.
FHIR
FHIR is the standard the ecosystem is expressed in. A hospital system that cannot produce its records as FHIR resources cannot participate meaningfully, whatever else it supports.
NHCX
The National Health Claims Exchange handles insurance claims in a standard form between hospitals, insurers and TPAs, instead of each payer running its own portal and format.
Identifier handling
The identifiers used to initiate a link — mobile number or Aadhaar — are sensitive. Good practice is to forward them to the gateway without persisting them. That is how it is handled here: the identifier is write-only and is never stored.
Workflow
How an ABHA link works from the counter
This is the sequence the endpoints in the platform implement.
- 01
The patient offers an identifier
At registration the patient provides their ABHA number, or a mobile number or Aadhaar to look one up. The identifier is passed to the ABDM gateway and not written to the hospital database.
- 02
A link is initiated
The system initiates the link request with the gateway, which triggers an OTP to the patient.
- 03
The OTP is verified
The patient shares the OTP, which is verified back through the gateway. The verification — not the identifier — is what establishes the link.
- 04
Link status is confirmed
The system checks link status rather than assuming success, so a failed link is visible at the counter instead of surfacing later as a missing record.
- 05
Consent is requested before anything is shared
To see records held elsewhere, a consent request is raised and its status checked. Access follows the patient’s decision — there is no path that skips this.
- 06
Records move in a standard form
Records fetched or shared are expressed as FHIR resources, and claims, where applicable, go over NHCX rather than through a payer-specific portal.
Evaluating vendors
Questions worth asking any vendor — including us
'ABDM-ready' on a brochure is not a fact. These questions turn it into one.
- Are you certified, or are you building toward it? These are different answers and a vendor should give the specific one. Ours is: building toward it.
- Show me an ABHA link happening. Not a settings screen — an actual link initiated, an OTP verified and a status checked.
- What happens when consent is refused? If the system has a path that shares records without a granted consent, it is not aligned with the framework.
- Can you export my records as FHIR today? Interoperability that depends on future work is not interoperability.
- Where is the ABHA identifier stored? The correct answer is that it is not stored.
- Who carries the cost when the specification changes? ABDM is an evolving programme. Get the answer in the contract, not in a meeting.
The same discipline applies to the rest of a purchase — our guide to choosing hospital management software covers data ownership, exit terms and the questions that expose weak products.
Sources
Where to check this for yourself
ABDM requirements are set by the National Health Authority and change over time. Nothing on this page should be treated as a substitute for the official specification. The authoritative sources are the ABDM programme site and the National Health Authority sandbox and developer documentation, which publish the current integration requirements, the consent framework and the NHCX specification.
We deliberately do not reproduce the specification here, because a stale copy of a government requirement is worse than none. Ask us for the current position and we will tell you where our implementation sits against it.
FAQ
ABDM and ABHA — common questions
- Is Polynexus ABDM-certified or ABDM-approved?
- No. Polynexus is developing Polynexus HMIS’s integration with the ABDM ecosystem and holds no ABDM certification, approval or empanelment from the National Health Authority. The platform’s backend has API endpoints for the building blocks described on this page, but that is not the same as a finished, customer-ready ABDM feature. Treat ABDM readiness as work in progress with us and ask for the current position before making a commitment that depends on it.
- What is ABDM, in plain terms?
- The Ayushman Bharat Digital Mission is the Government of India programme for a national digital health ecosystem. Its core ideas are a health ID for each citizen (ABHA), a consent framework that controls who may see a person’s records, registries of health facilities and professionals, and standard formats — principally FHIR — so records can move between systems.
- What is ABHA and how does it relate to an HMIS?
- ABHA is the Ayushman Bharat Health Account — the identifier a patient uses to link and access their health records. For a hospital system, ABHA is what lets a patient’s record at your hospital be associated with their national health record, subject to their consent.
- What does ABDM integration actually require of a hospital system?
- In broad terms: the ability to link an ABHA number to a patient with OTP verification, to raise and honour consent requests rather than sharing records on assumption, to fetch records a patient has consented to share, to expose your own records in FHIR form, and — where claims are in scope — to exchange them over NHCX. The precise requirements are set by the National Health Authority and change over time, so any vendor claim should be checked against the current specification.
- What is NHCX?
- The National Health Claims Exchange is the ABDM component for exchanging insurance claims in a standard form between hospitals, insurers and TPAs, rather than through each payer’s own portal.
- What exists in Polynexus HMIS today?
- The platform’s backend has API endpoints for initiating an ABHA link, verifying the OTP, checking link status, raising and checking consent requests, fetching health records and handling NHCX transactions, plus FHIR export. The identifier used to initiate a link is write-only and is forwarded to the ABDM gateway rather than stored. That describes what has been built into the system — it is not a claim of certification, and not a claim that ABDM workflows are a finished, supported feature you can deploy today. Ask us for the current status against your specific requirement.
Ask us where our ABDM work actually stands
We will show you what is implemented, what is not, and what a realistic timeline looks like for your hospital — without the brochure language.