ABHA-Based Patient Identity: A Developer's Integration Guide

ABHA (Ayushman Bharat Health Account) is becoming the patient identity standard in India. If you're building consumer or clinical healthcare software, you'll integrate it. Here's how.

Key takeaways

• ABHA is a portable 14-digit health ID + an "abha-address" handle.
• Creation flows: Aadhaar-based (faster, requires Aadhaar), mobile-based (broader coverage, more steps).
• Verification: short-lived OTP-based confirmation each time the user proves the identity.
• Integration: via the ABDM Gateway, through your registered HIE/CM partner.
• Trade-offs: ABHA-first vs ABHA-optional dramatically changes UX and reach.

Why this matters

ABHA is being woven into PMJAY, ABDM-linked apps, and increasingly into hospital systems. Apps that support it earn portability; apps that don't will increasingly feel disconnected.

The two creation flows

Aadhaar-based

User enters Aadhaar number → consent → OTP from UIDAI → ABHA created. Fast: 60-90 seconds. Limits to users with Aadhaar (most adults).

Mobile-based

User enters mobile number → OTP verify → basic demographic entry → ABHA created. Slower but broader.

Best practice: offer both, default to Aadhaar.

Integration architecture

Your app doesn't talk directly to ABDM's central infrastructure. You integrate via a registered HIE/CM (Health Information Exchange / Consent Manager) partner. They provide SDKs and APIs that abstract the ABDM Gateway calls.

When a patient creates or links ABHA in your app:

1. Your app initiates the flow with your HIE/CM partner SDK
2. The user goes through the Aadhaar or mobile flow
3. On success, you receive the ABHA number and an authenticated session
4. You store the linkage (your user_id ↔ ABHA address) in your DB
5. For subsequent verifications, you re-trigger an OTP flow

Verification on subsequent visits

Each time you need verified ABHA identity (e.g. before fetching health records via consent), the user must do a short-lived verification, typically an OTP. Don't cache this; it expires within minutes.

Linking existing patients

If a patient already has an ABHA from another app, they can link their existing ABHA address to your app instead of creating a new one. Build this flow, it's a smoother experience for returning users.

Trade-offs to decide upfront

ABHA-first or ABHA-optional?

ABHA-first means every patient must have an ABHA. Reach is narrower but data interoperability is universal.

ABHA-optional means patients can use your app without ABHA. Reach is wider, but those users miss out on cross-system records.

Most consumer apps go optional initially, then nudge users toward creation.

Aadhaar dependency

Some users won't share Aadhaar. Build the mobile-based path so you don't exclude them.

Common pitfalls

Treating ABHA creation as a one-time event. Users link/unlink/recreate over time. Build for these flows.

Not handling Aadhaar opt-out. Some users won't. Build the alternative.

Skipping the audit log. ABDM expects you to log every ABHA-related action.

What we recommend

Integrate ABHA as an option early. Track adoption. As ABHA penetration grows in your user base, you'll feel more confident moving to ABHA-first for clinical features.

FAQs

Do users need ABDM app installed? Some flows require it. Others are direct.

Can we create ABHA on behalf of patients? No, patient must consent and complete the flow themselves.

How is ABHA secured? OTP-based authentication on each verification. ABHA itself isn't a credential, it's an identifier.

Talk to Techpuvi about ABDM-aware healthcare engineering.