PHR app
You are the citizen's own app. You hold their identity, show them their records, and are the place where every consent decision is taken.
Who you are in ABDM
A PHR application acts for the citizen, and a citizen and a facility sit on opposite sides of the HIE-CM. That position is fixed for the life of your product.
You hold no registry identifier of your own. Your users hold the ABHA numbers and addresses, and everything routes on the address. Your own credentials are the client id and client secret issued at sandbox signup, which you exchange for a session token.
Within that position the citizen takes both directions through your app. Your user is the HIU whenever you fetch their records, and the HIP the moment they link or push one from your app.
To be listed for deep links, submit three things at sandbox exit: your application name, your Play Store URL and your App Store URL.
What you can do
| Build | What it gives the user |
|---|---|
| P1 | Create or link an ABHA address, four login routes, profile, card and QR code |
| P2 | Scan and share at a facility, discover old records, link care contexts |
| P3 | Subscriptions, notifications, consent decisions, auto approval, fetching and storing records |
Accepting uploads makes you a health locker, and that needs M2 as well.
Why it is worth it
You are the only participant the citizen actually sees. Every consent request raised anywhere on the network arrives in your app, and the decision is made there.
The HIE-CM tells you when a care context is created or updated for a subscribed address, so records reach your user without them chasing a facility. You then store those records for the long term, which no other participant does on the citizen's behalf.
Next
PHR applications is the build guide, screen by screen.