Skip to main content

​
In short

  • The receptionist logs the patient in to their ABHA, or creates one, with an OTP.
  • The HMS saves the ABHA number, ABHA address and oid on the patient record.
  • After the visit, the HMS links it to the ABHA as a care context.
  • Confirmation of the link arrives on a webhook.

​
Who and when

A receptionist at a clinic or hospital whose HMS is integrated with Eka as a Health Information Provider (HIP). A patient walks in for an OPD visit. They have no ABHA, do not know whether they have one, or have one but have never used it on this system. The clinic wants every visit linked to the patient’s ABHA so the records can be found and shared later, with the patient’s consent. Already in place: your software acts as a HIP. The facility has a HIP ID and is onboarded on Eka (Onboard a facility to ABDM), and your server can receive Eka webhooks.

​
What they want

“Get this patient an ABHA, or find the one they already have, register today’s visit against it, and don’t hold up the queue.”

​
The steps

  1. The receptionist asks whether the patient has an ABHA and what they can offer as identity: an ABHA address, their Aadhaar, or a mobile number. Most walk-ins do not know whether they have one.
  2. If the patient has an ABHA, the receptionist logs them in with an OTP to the patient’s mobile. → workflow: Log in to an existing ABHA
  3. If not, the receptionist creates one. With Aadhaar and its linked mobile, the patient reads out the OTP and gets a KYC-verified 14-digit ABHA number. → workflow: Create an ABHA with Aadhaar OTP
  4. The HMS saves the ABHA number, ABHA address and Eka’s user id (oid) on the patient record. It prints the ABHA card if the patient wants one.
  5. The consultation happens. The doctor records the prescription or visit summary in the HMS as usual.
  6. After the visit, the HMS links the visit to the patient’s ABHA as a care context. Confirmation arrives on a webhook; the HMS marks the visit as linked. → workflow: Link a care context as a HIP

​
What they have at the end

The patient has an ABHA number and an ABHA address, and knows them. The HMS holds abha_address, abha_number and oid on the patient record, so every later ABDM call for this patient needs no new lookup. Today’s visit is a linked care context, discoverable from any PHR app the patient uses and shareable with any HIU the patient grants consent to.

​
Branches

  • The Aadhaar OTP finds an existing ABHA. The verify step reports an existing profile; the flow logs the patient in rather than creating a duplicate. → same workflow, auto-login branch of Create an ABHA with Aadhaar OTP
  • The Aadhaar mobile is not linked. The flow asks for a separate mobile verification before creating. → same workflow, mobile verification branch
  • The patient refuses Aadhaar, or needs assisted registration without an OTP. → the alternatives in Create an ABHA with Aadhaar OTP
  • A later call for the patient returns 491. The patient’s ABHA Gateway session has expired; renew it with a mobile OTP and retry. → workflow: Hold the ABHA Gateway session
  • The patient wants their ABHA card, or KYC on a mobile-created address. Fetch the profile, show the card and QR code, or run KYC. → workflow: Manage the ABHA profile and KYC
  • The patient shows a Scan and Share QR at the counter. Their PHR app has already sent the profile. The HMS receives it on a webhook and replies with a token, skipping steps 1 to 3. → workflow: Receive a scanned profile as a HIP
  • The HMS keeps the clinical data itself rather than on Eka. When the patient later shares records, Eka asks the HMS for them on a webhook and the HMS serves them encrypted. → workflow: Serve records on a fetch request
  • The patient visited before this integration existed. Old visits are not linked. The patient can find and claim them from their PHR app, which the HMS answers on webhooks. → workflow: Answer discovery and link old records