Sanvro Tech · Milestones
M1, M2, M3, and PHR integration
A hospital system and a personal health record app do not finish the same list. M1 creates the ABHA. M2 links the visit and shares the record. M3 asks for consent and fetches. A PHR app also runs P1 registration and login, P2 consents management, P3 subscription, and P4, the live Sanvro digital health locker.
The order a product finishes
M1 Identity creates and verifies an ABHA: the 14 digit number and the ABHA address. M2 is the health information provider. Link this visit, the care context, and share the record that belongs to it. M3 is the health information user. Consent, then fetch.
PHR integration sits beside that. P1 is registration and login. The person has an ABHA number and an ABHA address. P2 is consents management. The app requests or displays consent so a record can move. P3 is subscription. The app asks to be notified when new records are linked. P4 is the locker. The Sanvro digital health locker is live and easy to connect. The PHR app connects to it. Sanvro ABDM Bridge does the ABDM calls.
Sanvro has already run these flows on the bridge. The partner keeps the screens. Sanvro handles sessions, headers, Fidelius, the bridge URL, certificates, callbacks, one API, and a signed webhook. The journeys are create an ABHA, link a visit, share a record, and consent then fetch.
Step names: ABDM milestones.
M1, M2, and M3
Select M1, M2, or M3. Each panel says what the product must do, what the patient sees, and what Sanvro carries. Arrow keys move between the milestones.
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.
What the product must do
Your personal health record (PHR) app or hospital information system (HIMS) collects what the journey needs, shows the person the check, and keeps the number and address against their profile. You choose the moment: a front desk, a patient app, or both. The account is not a replacement for the visit you already store.
What the patient sees
The person confirms it is them. They can then see the 14 digit number and the address later sharing will use. They are not asked to release a prescription, a lab report, or a discharge summary here.
What Sanvro carries
On the Sanvro ABDM Bridge, your app makes one call. Sanvro holds the gateway session, sets the headers, follows the callback, and returns the result on a signed webhook. The person still sees your screens.
You build
- The screen where someone creates or confirms an ABHA
- When your PHR or HIMS asks, and how the number and address appear afterwards
- The profile inside your own product
Sanvro handles
- The ABDM gateway session
- Headers on the create and verify calls
- The callback, and a signed webhook when the account is ready
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.
What the product must do
The HIMS already knows the consultation, the report, or the discharge. M2 does not ask you to rewrite it. You name the facility, name the care context, and point at the record. Linking tells the network that this visit belongs to this ABHA address.
What the patient sees
The visit can show against their account, in a PHR app or a health locker they use. A link is not a blanket release. The record still waits for consent before another organisation can read it.
What Sanvro carries
Sanvro carries the HIP side: headers, Fidelius, the bridge URL, certificates, and the callback. Your app sends the visit. A signed webhook tells you when the link or the share has settled.
You build
- The visit, and the record that belongs to it
- The facility and the care context to link to the ABHA address
- The clinical workflow your staff already use
Sanvro handles
- The HIP link and the share
- Fidelius, the bridge URL, and certificates
- Callbacks, and a signed webhook when the link or the share settles
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.
What the product must do
Your PHR, HIMS, or other health app states what it is asking for. It waits. It does not treat silence as a yes. When the record arrives, you show it inside the product you already built.
What the patient sees
They read the request in an app they control. They can agree, narrow the request, or refuse. If they use a health locker, records they have agreed to store can be waiting there for the next visit.
What Sanvro carries
Sanvro sends the consent request, waits, fetches, and posts a signed webhook when the record is ready. The Sanvro health locker is live. Connecting it does not mean standing up locker infrastructure. HIP, HIU, and health locker are roles in this flow, not three products to choose between.
You build
- The reason for the request, in language the person can read
- The choice to wait until they have agreed
- What your product does with the record after it arrives
Sanvro handles
- The consent request and the wait
- The fetch, then a signed webhook when the record is ready
- A live health locker a partner can connect
PHR
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.
Select P1, P2, P3, or P4. Each step splits what the partner app still does from what Sanvro handles. Arrow keys move between the steps.
P1 registration and login
Register and log in the PHR app
P1 is registration and login. The personal health record app registers the person against ABDM and signs them in. They have an ABHA number and an ABHA address. The app holds that profile. No clinical record moves in this step.
The partner app
- Registration and login screens in the PHR app
- The ABHA number and the ABHA address on the person's profile
- The moment they confirm the account is theirs
Sanvro handles
- The ABDM session for registration and login
- Headers on those calls
- The callback, and a signed webhook when the number and address are ready
- One API. The person still sees the partner app
P2 consents management
Request or display consent
P2 is consents management. The PHR app requests consent, or displays a request, so a record can move. The person agrees, narrows it, or refuses. Silence is not a yes.
The partner app
- The consent written so the person can read it
- The choice to agree, narrow the request, or refuse
- What the app does after they decide
Sanvro handles
- The consent request, and the wait while they decide
- Sessions, headers, and callbacks
- A signed webhook when consent settles
- One API
P3 subscription
Ask to be notified when records are linked
P3 is subscription. The PHR app asks to be notified when new records are linked to the person's ABHA. The person sees that ask in the app.
The partner app
- The ask: notify this app when a new record is linked
- Where that notice shows up in the PHR
- The person's choice to allow it
Sanvro handles
- Sessions, headers, and callbacks for that subscription
- The bridge URL the network posts back to
- One API and a signed webhook to the partner app
- Certificates on that path
P4 locker
Connect the live health locker
P4 is the locker. The Sanvro digital health locker is live and easy to connect. A PHR app connects to it instead of building locker infrastructure. Sanvro ABDM Bridge does the ABDM calls. Records stay tied to the person's ABHA. The personal health record experience stays in the partner app.
The partner app
- The place in the PHR app where the person opens their records
- The connection from that app to the Sanvro health locker
- The ABHA number and ABHA address the locker is tied to
Sanvro handles
- The live health locker, and the ABDM calls that serve it
- Sessions, headers, Fidelius, the bridge URL, and certificates
- Callbacks, one API, and a signed webhook
- Locker infrastructure stays with Sanvro
The partner app, and what Sanvro handles
The partner builds the PHR app or the HIMS. The patient stays in that product. Sanvro ABDM Bridge is one API and a signed webhook. Across M1, M2, M3, and the PHR steps, Sanvro handles sessions, headers, Fidelius, the bridge URL, certificates, and callbacks.
| Step | The partner app | Sanvro handles |
|---|---|---|
| M1 | The screen where someone creates or confirms an ABHA. When your PHR or HIMS asks, and how the number and address appear afterwards. The profile inside your own product. | The ABDM gateway session. Headers on the create and verify calls. The callback, and a signed webhook when the account is ready. |
| M2 | The visit, and the record that belongs to it. The facility and the care context to link to the ABHA address. The clinical workflow your staff already use. | The HIP link and the share. Fidelius, the bridge URL, and certificates. Callbacks, and a signed webhook when the link or the share settles. |
| M3 | The reason for the request, in language the person can read. The choice to wait until they have agreed. What your product does with the record after it arrives. | The consent request and the wait. The fetch, then a signed webhook when the record is ready. A live health locker a partner can connect. |
| P1 | Registration and login screens in the PHR app. The ABHA number and the ABHA address on the person's profile. The moment they confirm the account is theirs. | The ABDM session for registration and login. Headers on those calls. The callback, and a signed webhook when the number and address are ready. One API. The person still sees the partner app. |
| P2 | The consent written so the person can read it. The choice to agree, narrow the request, or refuse. What the app does after they decide. | The consent request, and the wait while they decide. Sessions, headers, and callbacks. A signed webhook when consent settles. One API. |
| P3 | The ask: notify this app when a new record is linked. Where that notice shows up in the PHR. The person's choice to allow it. | Sessions, headers, and callbacks for that subscription. The bridge URL the network posts back to. One API and a signed webhook to the partner app. Certificates on that path. |
| P4 | The place in the PHR app where the person opens their records. The connection from that app to the Sanvro health locker. The ABHA number and ABHA address the locker is tied to. | The live health locker, and the ABDM calls that serve it. Sessions, headers, Fidelius, the bridge URL, and certificates. Callbacks, one API, and a signed webhook. Locker infrastructure stays with Sanvro. |
Sandbox, then production
On the gateway yourself
Implement the milestones your role needs. Prove create, link, share, and consent then fetch in the sandbox, then point the same product at production. You own sessions, callbacks, the bridge URL, certificates, and Fidelius.
Through the Sanvro bridge
Your PHR or HIMS calls Sanvro. Sandbox and production are the same journeys: create an ABHA, link a visit, share a record, consent then fetch. The live health locker connects on this path. P1, P2, P3, and P4 use that same API and signed webhook.
M4 is registry integration: registering healthcare professionals and health facilities from your own software. A facility still needs an identifier before M2 can be tried end to end. Many products register that facility outside the app and never build M4. Get the facility identity in place before you expect a linked visit to succeed.
Related guides
ABHA
The number, the address, and what a PHR is.
The map
What ABDM is, and the two ways to integrate, on one page.
The bridge
One API, a signed webhook, and the live health locker.
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 do M1, M2, and M3 mean?
These names match the ABDM developer milestones page. M1 is identity: create and verify an ABHA number and ABHA address. M2 is the health information provider: link a visit, called a care context, and share a record with that ABHA. M3 is the health information user: ask for consent, then fetch the records the person allowed.
What are P1, P2, P3, and P4?
These are the PHR integration steps. P1 is registration and login: the person has an ABHA number and an ABHA address. P2 is consents management: the app requests or displays consent so a record can move. P3 is subscription: the app asks to be notified when new records are linked. P4 is the locker. 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.
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.
What does the partner still build?
The product. Screens, the moment you ask for an ABHA, the visit in the HIMS, the words the person reads before they consent, and what you do with a record after it arrives. With the Sanvro ABDM Bridge, that product talks to one API and receives a signed webhook.
What does Sanvro carry on the bridge?
Sessions, headers, Fidelius, the bridge URL, certificates, callbacks, one API, and the signed webhook. The journeys are create an ABHA, link a visit, share a record, and consent then fetch. The same surface covers PHR registration and login, consent, subscription, and the live health locker.