5 · Consents & Subscriptions

Consent is the whole point of ABDM. A PHR app sits on both sides of it — it receives consent requests raised by other HIUs so the patient can act on them, and it raises its own requests when it needs to pull records on the patient’s behalf.

​

The patient’s request inbox

An ABHA address receives three kinds of request. All three land in the same inbox. Patient Requests overview →

​

Acting on a consent request

On approval, ABDM generates one consent artefact per HIP involved. Revocation is per artefact — the patient can cut off one hospital without revoking the whole consent.

​

Raising a consent request as an HIU

Your PHR app fetching records from other providers is an HIU operation. Same API a hospital or insurer would use. Specify the patient’s ABHA address, the purpose, the date range, and which HIPs to fetch from. Once the patient approves, EKA drives all the intermediate gateway callbacks for you — see Fetch & Display Records.

​

Auto-approval and the health locker

Asking the patient to approve every single record is unusable at scale. An auto-approval policy lets the patient authorise a class of requests once — this is what turns your PHR app into the patient’s health locker: new records flow in without a prompt each time. When the locker is set up, your cloud receives abha.locker_created carrying the resulting auto_approval_id and subscription_id — store both, they identify the standing arrangement.

​

Events to handle

Consents overview → · M3 flow chart →