ABHA on UHI
ABHA is the patient's account: a 14 digit number and a readable
address such as name@abdm. UHI uses the address, never the number, and only as a name for the
person the booking is for.
Where it appearsโ
| Field | Service | Required | Example |
|---|---|---|---|
order.customer.id | Physical consultation | Yes | rahul.k001@sbx |
order.customer.id | Ambulance booking | Mandatory | 91XXXXXXXXXX@sbx |
chat.sender.person.id | Physical consultation | Yes | The ABHA address of the sender, or the doctor's HPR ID when the doctor sends |
chat.receiver.person.id | Physical consultation | Yes | The other side of the same pair |
The @sbx suffix in both examples is the sandbox one. Production addresses end @abdm, so an
address hardcoded from a sandbox test will fail once you are promoted.
What UHI does not do with itโ
Nothing is verified here. UHI carries the address through the booking; it does not check that it exists, does not authenticate the person behind it, and creates no ABHA of its own. A patient who has no ABHA gets one through M1 on HIE-CM, which is where creation, login and KYC live.
Nor does an ABHA address in a UHI message give anyone a right to the patient's records. Records move on HIE-CM, under a consent artefact, and never as part of a booking. See Consent on HIE-CM if that is what you are building.
Nextโ
- HPR on UHI, the practitioner side of the same booking
- Physical consultation, where both appear in full