ABHA Linking at the Clinic: The Actual Front-Desk Workflow

At the desk, ABHA linking is usually not the clinic creating anything. The patient already has an Ayushman Bharat Health Account, they scan the clinic’s QR code, and their name, date of birth, gender, mobile, and ABHA details drop into your registration screen. That is Scan and Share, it runs on the patient’s implied consent at the moment they scan, and it is the fast lane most clinics actually use. Creating a fresh ABHA and linking clinical records are the two other jobs, and they come with rules that trip up front desks. This walks all three, in the order they happen at check-in. General information, not legal advice; confirm current steps on the NHA portal.

Key takeaways

• An ABHA number is a 14-digit identifier for a person; the ABHA address is a name@abdm username. Same account, two identifiers.
• Creating an ABHA is free, voluntary, paperless, and takes about five minutes via Aadhaar OTP, mobile OTP, or driving licence, per NHA.
• Scan and Share moves demographics at registration on implied consent. Sharing clinical records needs explicit, granular consent the patient grants in their app and can revoke.
• The most expensive front-desk mistake is making a duplicate ABHA for someone who already has one.

Source: NHA, Ayushman Bharat Digital Mission FAQ.

What is an ABHA, and why does the front desk care about two identifiers?

One account, two things people confuse for each other.

The ABHA number is a 14-digit randomly generated number that identifies the patient. The ABHA address is a readable username, formatted like name@abdm, that the patient uses to log in, view records, and share them. NHA treats both as parts of the same Ayushman Bharat Health Account. A patient can hold the number and never touch the address, or use the address every visit. Your desk staff need to recognise both, because a patient may hand you either one.

Why this matters at check-in: when someone says “I have my ABHA,” ask which one they have in front of them. A 14-digit number and a name@abdm handle are both valid, and both let you attach the visit to the right person. Keying the wrong field, or assuming the address is the number, is where the first mismatch starts. The account is free and enrolment is voluntary, so nobody can be turned away for not having one. That framing keeps the desk out of trouble.

How does a patient create an ABHA, and should the clinic do it?

The honest answer for most clinics: let the patient create it, don’t create it for them.

NHA’s own description is that ABHA creation is fast, paperless, and hassle-free, done in about five minutes with no physical documents submitted anywhere. A patient can create one themselves on the ABHA app or at abha.abdm.gov.in using any of three routes:

• Aadhaar OTP. Enter the Aadhaar number, receive an OTP on the Aadhaar-linked mobile, verify. This is the most complete path because demographics pre-fill from Aadhaar.
• Mobile number. Create with just a mobile OTP plus basic details (name, year of birth, gender, address). This makes an ABHA that isn’t Aadhaar-verified, which matters later for KYC-gated workflows.
• Driving licence. NHA has at times offered driving-licence-based creation as an alternative; availability varies, so confirm it’s live on the portal before relying on it.

Two reasons the desk shouldn’t be the one clicking. First, an ABHA made on the patient’s own phone stays in the patient’s control, with their consent captured cleanly, which is the whole point of the account. Second, front-desk creation is how duplicates happen: staff make a new ABHA for a patient who already had one from a previous hospital or a government camp, and now that patient has two accounts and a split history. If a patient genuinely has none and wants help, the cleanest move is to walk them through creating it on their own phone rather than making it on a clinic device.

What does the actual check-in flow look like, step by step?

Here is the sequence a busy Indian OPD desk runs, from the patient walking up to the record being ready to link.

Step 1, ask, don’t assume. “Do you have an ABHA?” Three outcomes: they have the number, they have the name@abdm address, or they have neither. Sort into those three buckets before anything else.

Step 2, for a patient who has one, use Scan and Share. Display your facility’s ABDM QR at the desk. The patient opens their ABHA or PHR app, scans, and shares their profile. Their demographics, name, gender, date of birth, mobile, ABHA address, and ABHA number if linked, land in your registration screen and generate the OPD token. NHA built Scan and Share specifically to cut the registration queue, and it runs on the patient’s implied consent at the point they choose to scan and share.

Step 3, for a patient with only the address or number, verify identity. If they read out a 14-digit number or a name@abdm handle instead of scanning, confirm the name and date of birth on screen match the person standing there. This one check prevents attaching a visit to the wrong ABHA, which is painful to unwind.

Step 4, for a patient with no ABHA, offer, don’t force. Enrolment is voluntary. If they want one, guide them to create it on their own phone via Aadhaar or mobile OTP. If they decline, register them the normal way. A patient without an ABHA still gets seen; they just don’t get a linked record today.

Step 5, see the patient and document the visit. The clinical encounter happens as usual. What the desk needs on the other side is a clean, structured record of that visit, because that record is what gets linked.

Step 6, link the record, with the right consent. The visit note is tagged to the patient’s ABHA through your ABDM-certified system. Demographic sharing at registration was implied consent; sharing the actual clinical record across facilities is a separate, explicit consent the patient grants in their PHR app.

What does linking a record to ABHA actually mean?

It is quieter than it sounds, and knowing that keeps staff honest with patients.

Linking tags the visit record generated at your clinic to the patient’s ABHA so it can be located and, with consent, shared through the ABDM network later. The record still lives in your clinic’s system. Linking creates a pointer, so the patient can assemble their history across the hospitals, labs, and clinics they visit. It does not, by default, dump the whole chart onto a government server the moment you link.

The consent structure is the part to get right. Per the PIB explainer on ABHA, records are not shared with a doctor or facility without the user’s consent, and that consent is granular: the patient can approve sharing only selected records, set how long the approval lasts, and revoke it at any time from their app. So there are really two consent moments at a clinic. The implied consent when a patient scans and shares demographics to register. And the explicit, revocable consent when clinical records move between providers. Treating the first as permission for the second is the compliance mistake to avoid, and it lines up with how the DPDP Act 2023 expects clinics to handle patient data: purpose-limited, consent-first.

Where does HFR registration fit into any of this?

You can’t scan-and-share into a facility that isn’t a recognised node.

To display a facility QR and act as a participant in ABDM workflows, your clinic has to be registered on the Health Facility Registry (HFR) at facility.abdm.gov.in, and the treating doctor on the Healthcare Professionals Registry. That registration is what makes your clinic a real node the patient’s app can share to, and it is the same on-ramp behind DHIS incentive eligibility. No HFR, no facility QR, no clean linking. If your clinic isn’t registered yet, the step-by-step HPR and HFR registration guide walks both portals, and the honest breakdown of what ABDM’s DHIS actually pays a clinic sets expectations on the money side before you build a workflow around it.

Getting registered is the setup cost. The recurring work, the part that decides whether linking is smooth or a daily headache, is producing a clean, structured record for every visit that is actually ready to link.

What are the front-desk pitfalls that cause bad records?

Most ABHA problems at a clinic are not technical failures. They are small process slips at the desk that surface weeks later as orphaned or mismatched records.

The duplicate ABHA is the big one. Staff create a new account for a patient who already had one, and now the patient has two ABHA numbers with history split across them. Always ask first, and prefer verifying an existing account over minting a new one.

Consent confusion is the compliance one. A patient scanning to register is not the same as a patient agreeing to share their clinical history with another provider. Keep the two separate in staff training, because conflating them is exactly the kind of thing a DPDP-era audit would flag.

Manual keying errors are the boring but common one. Typing a 14-digit number by hand invites transposed digits, which attaches the visit to the wrong or a non-existent ABHA. Scan and Share exists partly to remove this. Use it whenever the patient has the app.

Identity mismatch is the quiet one. Not confirming that the name and date of birth on the ABHA match the person at the desk means a family member’s account, or a stale profile, gets the visit. Thirty seconds of verification saves a support ticket later.

• Front-desk process (duplicates, consent, keying, identity)75%
• Genuine technical or connectivity issues25%

Where does an AI scribe fit, and what won’t we claim?

At the record, right before it gets linked, and nowhere near the ABHA itself. We’ll be precise about that boundary.

The AI Medical Scribe by Patient Square is the ambient scribe module inside Practice Copilot. It listens during the visit and hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft, ready to review and sign about two minutes after the visit. In a clinic running code-mixed Hindi and English, it captures the conversation and the note still comes out in clean clinical English. That clean, structured note is precisely the record a clinic wants when it goes to link a visit to ABHA, because you cannot link a record that was never written down properly. The ICD-10 output is suggestions and the prescription is a draft; the clinician reviews and signs everything before it becomes part of the record.

Here is the line we hold. ABDM integration is on our roadmap, not live today. We do not create ABHA numbers, we do not link records to ABHA from inside the tool, and we have not completed ABDM milestone certification (M1/M2/M3). We never call ourselves ABDM-compliant or ABDM-ready, because we aren’t. If linking records to ABHA from inside your software is a requirement right now, a vendor with live ABDM integration across the milestones is the honest pick, and we’d say so. What we do is make the per-visit documentation clean enough to feed whatever ABDM-certified system your clinic runs the linking through.

On data discipline, because a DPDP-era clinic will ask: visit audio is processed in memory and discarded once the note drafts, so there is no audio archive. Notes are in English, encrypted in transit (TLS 1.2+) and at rest (AES-256), access is role-scoped and logged, and the notes belong to your practice to export or delete anytime. We handle data to DPDP Act 2023 standards, and a SOC 2 Type II audit is underway. How we handle data residency for an India clinic is covered separately, and the full posture is on our security page.

Pricing is per clinician and ex-GST, from ₹1,599 a month on the annual Assist plan plus 18% GST (about ₹1,887 all-in), with a 7-day free trial; the current tiers are on the pricing page. If you’re setting up an ABDM-ready front desk and want the record-keeping half to be the easy part, book a short demo and bring one real visit. The test is simple: is the note that comes out clean enough to link without cleanup?