India’s digital health stack is reshaping how records move between providers. Here’s a practical guide to ABHA linking, consent and FHIR exchange — without the jargon.
India’s Ayushman Bharat Digital Mission (ABDM) is quietly rewiring how health information moves between providers. For hospitals and clinics, the practical questions are simple: what is ABHA, what does “linking” actually mean, and what do you have to do to be ready? Here’s a plain-language guide.
What ABHA and ABDM actually are
ABDM is the national framework for digital health in India. ABHA (Ayushman Bharat Health Account) is a unique health ID that lets a patient’s records be linked and shared — with their consent — across participating providers. Think of ABHA as the patient’s portable identity across the health system, and ABDM as the rules and rails that move records between systems.
The three things that matter for a facility
- ABHA linking: associating a patient’s ABHA number with their record in your system, usually verified by a one-time password.
- Consent: nothing moves without the patient’s explicit, revocable consent — captured and logged for every exchange.
- FHIR exchange: records are packaged in the FHIR R4 standard so any compliant system can read them.
The single biggest readiness gap we see is consent handling. If your system can’t capture, store and honour consent per exchange, you’re not ABDM-ready — no matter how good your records are.
What “ready” looks like in practice
A facility is ABDM-ready when it can: link an ABHA at registration, request and record consent for an exchange, generate a valid FHIR R4 bundle from its clinical data, and transmit or receive that bundle through the ABDM gateway. Crucially, this should happen inside normal workflow — not as a separate portal your staff have to remember to use.
How ArogyaSutra handles it
ArogyaSutra treats ABDM as a first-class part of the patient record. ABHA linking sits in registration, consent is captured and logged automatically, and FHIR R4 bundle generation is built in. In development you run against a mock gateway; switching to the ABDM sandbox is a configuration change, not a rewrite — so you can pilot quickly and go live when your onboarding milestones are approved.