Skip to main content

​
In short

  • The patient creates an ABHA in the app, or logs in to one they already have.
  • They link records from each facility they visited, with an OTP.
  • They answer each consent request, and a health locker policy brings in new records.
  • At a facility counter, one scan shares their profile.

​
Who and when

A patient who has installed a Personal Health Record (PHR) app built on ABDM Connect. They have visited several hospitals, clinics and labs over the years, and their records are scattered across each facility’s software. They open the app to get an ABHA, see everything in one place, and stop carrying paper files to every appointment. Already in place: your software acts as a PHR app. That usually makes it a Health Information User (HIU), when it pulls records from facilities on the patient’s behalf. It is also a Health Information Provider (HIP), when it holds records the patient uploads. You have Eka credentials (Authorization), and your cloud can receive Eka webhooks, because linking results, consent updates and subscription notifications arrive only there. No other journey has to run first.

​
What they want

“Put all my health records in one app, let me decide who sees them, and let me check in at the hospital without filling a form.”

​
The steps

  1. The patient opens the app for the first time and creates an ABHA. With Aadhaar and its linked mobile, they enter the OTP Aadhaar sends and get a KYC-verified ABHA number and ABHA address. → workflow: Create an ABHA with Aadhaar OTP
  2. A returning patient logs in instead, with their ABHA address, Aadhaar or mobile number and an OTP. → workflow: Log in to an existing ABHA
  3. The app keeps the patient’s ABHA gateway session alive. When it expires, the patient enters one more mobile OTP and carries on where they were. → workflow: Hold an ABHA gateway session
  4. The patient checks their profile, completes KYC if the app asks, and saves their ABHA card and QR code. → workflow: Manage the ABHA profile and KYC
  5. The patient searches for a hospital or lab they have visited. The app asks that facility for records it holds against the patient that are not yet linked. The patient picks the ones that are theirs and enters the OTP the facility sends to their mobile. → workflow: Discover and link records from a facility
  6. The app lists every facility the patient now has records with, and the records under each one. → workflow: List a patient’s linked records
  7. Requests from doctors, hospitals and insurers who want to see the records land in the patient’s inbox. The patient reads each one and approves it, denies it, or later revokes it. → workflow: Act on a consent request
  8. So they are not asked every time, the patient turns the app into their health locker. They approve a standing policy once, and the app is notified each time a facility links a new record, then fetches it through a consent. → workflow: Set up the health locker
  9. On their next visit, the patient scans the QR code at the registration counter. Their profile reaches the facility’s software, and the app shows the token number the counter issues. → workflow: Share a profile at a facility counter

​
What they have at the end

The patient has an ABHA number and an ABHA address, and the app holds a session for them. Records from every facility they linked appear in one list, grouped by facility. They have answered every pending consent request. Under a standing policy, the app is notified of each new record and fetches it through a consent. At a facility counter, one scan registers them and gives them a token.

​
Branches

  • The patient uploads a record of their own, such as an old lab report. The upload becomes a care context under the app’s own HIP, discoverable and shareable like any facility record.