ABDM & Compliance · 13 min read
ABHA (Ayushman Bharat Health Account) is India's national health ID — a 14-digit unique identifier that links a patient's health records across hospitals, labs, pharmacies, and apps through the ABDM (Ayushman Bharat Digital Mission) ecosystem. For HealthTech product teams, ABHA integration is no longer optional — it's becoming a requirement for government hospital partnerships, insurance claim processing, and competing for patients who expect their health history to be portable. This guide covers the integration architecture, the UX flows that actually work, and the compliance requirements that trip up most teams.
ABHA is the patient-side identifier — a 14-digit number (or an @abdm address) that a patient uses to share their health records. ABDM is the broader ecosystem: the technical standards, APIs, and consent framework that govern how health data flows between healthcare providers, payers, and patients. Think of ABHA as the patient's UPI ID, and ABDM as the UPI network — the ID is the access point, the ecosystem defines what can flow through it.
The key building blocks HealthTech teams integrate with: ABHA Number Creation: allowing users to create or link their ABHA account from within your app (via Aadhaar-based or mobile-based verification). Health Records (HIU/HIP): Health Information User (HIU) lets your app request access to a patient's health records from other providers; Health Information Provider (HIP) lets your platform publish health records to the ABDM network that the patient can share elsewhere. Health Locker: storage of patient health records linked to their ABHA ID. Consent Manager: the consent framework through which patients approve and revoke data sharing between health entities.
Most HealthTech teams don't need to build the full ABDM stack — they need specific modules based on their product type. A telemedicine platform primarily needs HIP (to publish consultation records and prescriptions to the patient's ABHA) and ABHA login (to authenticate patients and retrieve their relevant history as HIU). A diagnostic lab app needs HIP (to publish lab results to ABHA) and ideally HIU (to retrieve relevant medical history to contextualise reports). A health insurance platform needs HIU (to retrieve medical records for underwriting and claims, with patient consent) and potentially a consent manager integration. A fitness/wellness app typically needs only ABHA login for identity and potentially health record read access with very limited scope.
The starting point is registering as a Health Repository or Health Application on the NHA (National Health Authority) portal at abdm.gov.in. You'll need to specify your entity type (HIP, HIU, or both), your use case, and your technical implementation plan. After registration, you get sandbox credentials to test your integration. The sandbox environment is reasonably well-documented and available at sandbox.abdm.gov.in. Budget 2-4 weeks for registration approval in the current environment.
The user-facing ABHA creation flow has two paths. Aadhaar-based ABHA creation — the user enters their Aadhaar number, receives an OTP, and a 14-digit ABHA number is generated and linked to their Aadhaar. This is the preferred path for users who have Aadhaar linked to their mobile. Mobile-based ABHA creation — for users without a linked Aadhaar, mobile number + OTP creates a mobile-linked ABHA. This has slightly less trust weight in the ecosystem but covers the full population.
UX note: Indian patients are increasingly familiar with ABHA from government health schemes (Ayushman Bharat) and public hospital registrations. Frame ABHA creation as "Link your national health ID to carry your records everywhere" — not as "Create a new account." The former framing respects the user's existing ABHA if they have one; the latter creates confusion and duplicate accounts.
As a HIP, your platform publishes structured health records (in FHIR R4 format — Fast Healthcare Interoperability Resources) to the ABDM health locker when a clinical event occurs. Events that should trigger HIP publishing: consultation completed (publish consultation summary and prescription), diagnostic report generated (publish lab or imaging report), prescription dispensed (pharmacy records). The key technical requirement: health records must be structured in FHIR R4 format, which requires either building a FHIR transformation layer or using an SDK like the NHA's own ABHA Java SDK or third-party ABDM integration platforms (HealthStack, Clinivantage).
Every health data access in ABDM requires explicit, time-bound, purpose-specific patient consent. The consent artefact specifies: which health information types are being requested (OPD record, lab report, prescription, etc.), the date range, the purpose (self-use, treatment, payment, research), and the validity period. Patients approve consent requests through their ABHA-linked app (or the ABDM PHR app) and can revoke at any time. Your product must handle consent approval, revocation, and expiry gracefully — attempting to access records after consent revocation is a compliance violation with consequences under DPDPA and NHA guidelines.
The biggest adoption problem with ABHA integration isn't technical — it's the UX of explaining to a patient why they should share their health records and how it benefits them. The flows that work are those that surface ABHA integration at the moment of highest patient motivation: during hospital/clinic pre-registration ("Save 10 minutes at the registration desk — link your health records"), before a consultation ("Share your medical history with your doctor for a better consultation"), or when a patient is asked to repeat a test they've already done ("Your previous lab reports are available via ABHA — no need to repeat"). The flows that fail are those that introduce ABHA as a standalone onboarding step with no clear patient benefit.
Creating duplicate ABHA accounts — triggering ABHA creation flow without first checking if the user already has an ABHA ID creates phantom accounts and fragments the patient's health records. Always offer "Link existing ABHA" as the primary option, with "Create new" as secondary. Broad consent requests — requesting consent for "all health record types" from "1990 to present" for "all purposes" reads as an overreach to patients and has high rejection rates. Request the minimum necessary scope for the specific use case. No consent status visibility — patients should be able to see which consents they've approved, to whom, and for how long, directly in your app. Hiding this information erodes trust. Ignoring FHIR schema validation — publishing malformed FHIR records to ABDM creates data quality issues that affect the patient and can result in your HIP certification being revoked.
The NHA has set aggressive ABDM integration targets for government hospitals and Ayushman Bharat scheme providers — by 2027, most public healthcare touchpoints will be ABDM-enabled. For HealthTech platforms, this means: patients in government hospitals will increasingly expect their private health apps to connect to their ABDM records. Insurance companies are piloting ABDM-based claims processing, which would dramatically speed up reimbursements for ABDM-integrated providers. Corporate health programs are beginning to require ABDM integration from their HealthTech partners to enable portability for employees. The window to integrate while competitors haven't is narrowing — the strategic advantage of being an early ABDM integrator shifts from differentiator to table stakes somewhere in 2026-2027.
A team with one backend developer familiar with REST APIs and basic data transformation can implement ABHA login (authentication and account linking) in 2-4 weeks using the NHA's sandbox and SDK. HIP publishing (creating and sending FHIR-formatted health records to ABDM) adds 4-8 weeks depending on the complexity of your existing data model and how structured your clinical records already are. If your records are in unstructured text (doctor's notes, free-form prescriptions), you'll need a FHIR transformation layer that adds significant complexity. Full HIU implementation (requesting and consuming patient records from other providers) adds another 3-5 weeks. Total for a meaningful ABHA integration: 2-4 months of backend engineering, plus UX and product work.
We help HealthTech product teams scope and prioritise ABDM integration — from API strategy to patient consent UX. Book a free strategy session.
Book Free Strategy Call