Sanvro Tech · Guides
Ayushman Bharat for the product you ship
Ayushman Bharat Digital Mission (ABDM) is how a person's health information moves between a clinic, a lab, an insurer, and the app they control. This page is the map. ABHA, milestones M1, M2, and M3, and PHR integration sit one click away. Sanvro connects a live digital health locker on that map.
What the mission is for
ABDM is a government digital health effort. The National Health Authority publishes the specifications. The point, for a product team, is narrower than the policy language: a person has one account, a facility can attach a visit to it, and another organisation can read a record only after that person agrees.
The account is an Ayushman Bharat Health Account, usually called ABHA. The work of attaching a visit, sharing a record, and fetching with consent is grouped into milestones. You do not have to build every milestone on day one. You do have to know which role your product is playing.
Three roles show up again and again. A health information provider (HIP) holds a record and can share it. A health information user (HIU) asks for a record. A health locker keeps copies the person has agreed to store. They are roles on one network, not three competing products.
Three milestones
M1 creates and verifies the ABHA. M2 links a visit and shares the record. M3 asks for consent and fetches. Select a milestone. The milestones page has the build split for each one, and the PHR steps beside it.
M1 Identity: create and verify ABHA
Create and verify an ABHA
M1 is the identity milestone. A product creates and verifies an Ayushman Bharat Health Account: a 14 digit ABHA number and an ABHA address. No clinical record moves in this step.
M2 Health Information Provider: creation, linking, and sharing of health records
Link a visit and share a record
M2 is the health information provider milestone. A HIP links this visit, called a care context, to the ABHA address, and can share the record that belongs to that visit.
M3 Health Information User: health information exchange with consent
Ask for consent, then fetch
M3 is the health information user milestone. A HIU requests consent and, if the person agrees, fetches the records they allowed. A health locker is easy to see here: it keeps those records for the person, tied to the ABHA.
A PHR app also finishes P1 registration and login, P2 consents management, P3 subscription, and P4 locker. P3 subscription means the app asks to be notified when new records are linked. The Sanvro health locker is live. Open the PHR steps. What a PHR is.
Two ways to integrate
A personal health record (PHR) app or a hospital information system (HIMS) reaches ABDM in one of two ways. Both start in the sandbox, where you prove create, link, share, and consent then fetch, and only then move to production.
Path one
Build against the ABDM gateway
Your team implements the milestones that match your role. You own the gateway session, the headers, the callbacks, the bridge URL, certificates, and Fidelius. Prove create, link, share, and consent then fetch in the sandbox, then run the same product in production.
Path two
Integrate through the Sanvro ABDM Bridge
You build the PHR app or the HIMS. Sanvro handles sessions, headers, Fidelius, the bridge URL, certificates, and callbacks. Your product uses one API and a signed webhook. The journeys already on the bridge are create an ABHA, link a visit, share a record, and consent then fetch.
The Sanvro digital health locker is live and easy to connect. Locker infrastructure stays with Sanvro. The experience the person opens stays in your app.
Where to go next
ABHA
The 14 digit number, the address records are sent to, and why a PHR or HIMS needs both.
Milestones and PHR
M1, M2, and M3, then PHR integration: P1 registration and login, P2 consents management, P3 subscription, and P4 locker.
ABDM Bridge
The live product: one API, a signed webhook, and a health locker a partner can connect.
Build M1, M2, M3, and the PHR flows
Build these M1, M2, M3, and PHR flows with Sanvro, and connect the live health locker.
Questions worth asking first
What is Ayushman Bharat Digital Mission?
Ayushman Bharat Digital Mission (ABDM) is how a person's health information moves between organisations when that person agrees. The account is an Ayushman Bharat Health Account (ABHA). A product plays a health information provider (HIP), a health information user (HIU), a health locker, or more than one of those roles.
What is an ABHA?
An ABHA is the person's account on that network. It has a 14 digit ABHA number, issued once the person is verified, and an ABHA address that records and consent requests are aimed at. A personal health record (PHR) app and a hospital information system (HIMS) both need those identifiers before a visit can be linked or a record can be fetched.
Should a product call the ABDM gateway directly?
Some teams do. They implement the milestones their role needs, prove them in the sandbox, and move to production when the journeys hold. Other teams keep the PHR app or HIMS as their product and use the Sanvro ABDM Bridge: one API and a signed webhook. Sanvro then handles sessions, headers, Fidelius, the bridge URL, certificates, and callbacks.
Where does a health locker fit?
A health locker is a role, not a rival to a HIP or a HIU. It keeps records against the person's ABHA after they agree. The Sanvro digital health locker is live and easy to connect, and a partner can connect it without building locker infrastructure. The personal health record experience stays in the partner app.
What is a PHR in ABDM?
A personal health record (PHR) app is the app the person uses to hold an ABHA address, see linked records, grant consent, and keep records in a health locker. PHR integration is P1 registration and login, P2 consents management, P3 subscription, and P4 locker. P3 subscription means the app asks to be notified when new records are linked. The Sanvro digital health locker is live and easy to connect. A PHR app connects to it, and Sanvro ABDM Bridge does the ABDM calls.