In short
- Your HMS answers each request from a patient’s PHR app on its own, through Eka.
- It searches its records with the patient’s verified details and returns what is not yet linked.
- The patient picks records and confirms them with an OTP your HMS sends by SMS.
- On a matching OTP, ABDM registers the records under the patient’s ABHA.
Who and when
A patient who visited your clinic or hospital in the past, before their visits were linked to an ABHA. They now have an ABHA and use an ABDM PHR app, such as the ABHA app, to gather their health records in one place. They pick your facility in the app and ask it for their records. Nobody at your facility is involved: your HMS, acting as a Health Information Provider (HIP), answers every request on its own, through Eka. Already in place: your software acts as a HIP, with the setup from Register a walk-in patient and link the visit. The facility has a HIP ID and is onboarded on Eka (see Onboard a facility and its professionals to ABDM). Your server can receive Eka webhooks. Your HMS holds past visits, prescriptions or reports for patients, with at least their name, gender, year of birth and mobile number.What they want
“Find the records this hospital has for me and add them to my ABHA, so I can show them to my next doctor.”The steps
- The patient opens their PHR app, chooses your facility and asks for their records. ABDM sends the request to Eka, which passes it to your HMS. The request carries the patient’s verified ABHA address, name, gender, year of birth and mobile number.
- Your HMS searches its patient records with those details. It answers with the visits and documents that belong to this patient and are not yet linked. → workflow: Answer discovery and link old records
- The PHR app lists what your facility found. The patient picks the records they want to link. This is a human action in the app.
- Your HMS sends a one-time password (OTP) by SMS to the patient’s registered mobile number and tells ABDM it has done so. → workflow: Answer discovery and link old records
- The patient reads the OTP from their SMS and types it into the PHR app. This is a human action.
- Your HMS checks the OTP against the one it sent. If it matches, it confirms the link, and ABDM registers the records under the patient’s ABHA. Your HMS marks them as linked. → workflow: Answer discovery and link old records
What they have at the end
The patient sees your facility’s past records in their PHR app, linked to their ABHA. They can share them, with consent, with any Health Information User (HIU) such as another doctor or an insurer. Your HMS holds those records marked as linked, so it leaves them out of the next discovery answer. If your HMS chose to, it also holds the patient’s verified ABHA address on their record, so new visits can be linked straight away.Branches
- Your HMS finds no matching patient. It answers the discovery with an error, and the PHR app tells the patient nothing was found. → same workflow, no-match branch of Answer discovery and link old records
- The patient enters a wrong or expired OTP. Your HMS answers the confirmation with an error and links nothing. → same workflow, OTP branch
- Your HMS saves the patient’s ABHA address on a match. Future visits for this patient are linked directly after each visit, with no discovery needed. → workflow: Link a care context as a HIP
- An HIU later asks for the linked records and your HMS keeps the data itself. Eka asks your HMS for the records on a webhook, and your HMS serves them encrypted. → workflow: Serve records on a fetch request
- All of the patient’s records are already linked. There is nothing unlinked to return, so your HMS answers as for no match. → same workflow, no-match branch