Milestone 1 ABHA & Ayushman Bharat
ABHA and Ayushman Bharat, wired into your software
The Ayushman Bharat Health Account is how a citizen is identified across India’s health network. Creating and verifying one from your hospital management system is the first thing any ABDM integration has to do — whether that system is an HMS, an EMR or a lab platform.
01 Identity
Two identifiers, and the difference matters
Every ABDM flow keys on one or the other. Consent and record exchange key on the address; the account itself is the number.
Fourteen digits, issued once and permanent. It is the account itself — the thing a citizen holds, not the thing they hand out.
14 digits · issued once · never changes
A human-readable handle, like an email address. This is what consent and record exchange are keyed on, and one person can hold several.
Chosen by the citizen · several per account · may be empty at creation
02 Enrolment
How an account is created
A citizen can create an ABHA from an Aadhaar number or from a mobile number alone. The Aadhaar route gives a fully KYC-verified account; the mobile route creates one that can be verified later.
-
Send the Aadhaar number, sealed
RSA-sealed with ABDM’s published public key before it leaves the server. The connector does the sealing; the plaintext never reaches a database, a log or an error report.
-
UIDAI sends an OTP
To the mobile number linked to that Aadhaar. You have 300 seconds, and UIDAI counts the attempts against it.
-
Submit the OTP, also sealed
The citizen reads it back at the counter. Attempts are tracked per session, so a doomed retry is refused here rather than burning one of the citizen’s.
-
ABDM returns the number
The account exists. The citizen then chooses an ABHA address — which may not happen in the same session, so treat the address list as possibly empty.
# step 1 — request the OTP
POST /v1/abha/enrolment/aadhaar
{
"patient_reference": "MRN-90881",
"aadhaar_number": "XXXXXXXX9012"
}
↑ sealed server-side, never stored
← the session
{
"id": "7b21e0c4-…",
"flow": "enrol_aadhaar",
"status": "otp_sent",
"masked_identifier": "XXXXXXXX9012"
}
# step 3 — verify
POST /v1/abha/enrolment/7b21e0c4-…/verify
{
"otp": "******"
}
← the account exists; the address may not yet
{
"status": "address_pending",
"abha_number": "91-1234-5678-9012",
"patient_reference": "MRN-90881"
}
03 Failure modes
Where integrations get this wrong
Three mistakes account for most of the M1 support traffic we see. All three are handled below the API you call.
- Retries
-
Retrying a failed OTP
UIDAI counts attempts per OTP and locks the citizen out after a few. Re-submitting the same code because your first request timed out burns that budget and produces “Maximum number of attempts” errors the citizen cannot clear for hours.
- Storage
-
Storing what must not be stored
Aadhaar numbers and OTPs are sealed in memory and never written to a database, a log or an error report. Log redaction covers them by name, so they cannot leak through a stack trace either.
- Assumptions
-
Assuming a new account has an address
A freshly created ABHA often has an empty address list until the citizen picks one. Code that reads the first element crashes on the most common case there is.
04Ayushman Bharat and PM-JAY
ABHA is the digital health account under the Ayushman Bharat Digital Mission. It is distinct from a PM-JAY beneficiary card, which is the insurance scheme — a patient may have either, both or neither. ABDM integration concerns the health account and the records attached to it, not claims.
05What you get
- Enrolment by Aadhaar OTP and by mobile OTP
- Verification and KYC of an existing ABHA
- ABHA address search, availability and resolution
- Profile retrieval, with identifiers masked on read
- Attempt limiting and rate limiting on every OTP endpoint
FAQ Common questions