The QR code is working, the journey behind it isn’t!

An analysis of the adoption of ABDM Scan and Share.

India’s digital health stack — Ayushman Bharat Digital Mission — is already operating at scale. One of the citizen-facing use cases of ABDM is the digital OPD (Out-Patient Department) registration. Referred to as the “Scan and Share service”, this facility allows any citizen to scan the QR code in the hospital and register for OPD with an ABHA ID. It is an entry point for citizens to participate in the ABDM ecosystem and graduate to the rest of the use cases, like storing digital records and consent-based sharing. Scan and Share is live in 26,000+ health facilities, and over 22 crore tokens have been generated as of May 2026.

Even after making use of a UX element widely familiar, the QR code, half of the country’s population remains ABHA-unregistered. ABDM already has scale, utility, and distribution. The real gap appears to be at user conversion — and at the exact point where a first-time user is expected to enter the ecosystem.

The friction point

The current Scan and Share flow assumes that the user already has an ABHA ID and an ABDM-enabled app installed.

Process flow of Scan and Share. ABDM, 2026

For a first-time user in a hospital queue, the second step alone expands into four:

1. Discover what ABDM-enabled/PHR apps are
2. Discover the available apps
3. Evaluate and download one of the available apps
4. Authenticate Aadhaar with OTP

In a potentially stressful context at a hospital, that is enough friction to lose the user even before they have registered for OPD, which is the only reason they scanned the QR code in the first place.

The issue is not that ABHA creation exists in the flow, but that the product treats it as the primary task. In practice, OPD registration is the immediate user need, and ABHA onboarding is secondary. The journey is, however, designed the other way around.

A browser-first approach

The proposed recalibration is simple: bifurcate the journey based on where the user actually is, and do not block the primary task.

The potential users of OPD Scan and Share can be divided into three segments:

Segment 1: Users with an ABDM app

Scan QR → App opens → Confirm ABHA → OPD Token generated Similar to UPI deep linking, the QR code directs to a universal ABDM entry link. The device operating system identifies the installed ABDM-enabled app and redirects the user to it automatically.

Segment 2: ABHA onboarded user without an ABDM app installed

Scan QR → Browser → Login with ABHA mobile OTP → OPD Token generated In the absence of an ABDM-enabled app, the journey becomes browser-first. This eliminates the friction point of installing an additional app for OPD registration.

Segment 3: Users with no ABHA ID

Scan QR → Browser → Enter Aadhaar or Aadhaar-linked mobile number → Authenticate with OTP → OPD Token generated → Complete ABHA ID creation In case of no ABHA ID, the ID creation is initiated via OTP authentication, but the primary task is not blocked by it. The rest of the ABHA onboarding journey is taken up post OPD token generation.

Assisted Registration Mode: For citizens without smartphones or digital familiarity, hospital staff or registration desks can initiate the same browser journey using a shared device.

Why this matters beyond ABDM

Every DPI system faces the same adoption curve problem: the entry point use case has to be frictionless enough to convert a first-time user who has no prior context and no intrinsic motivation to onboard. ABDM’s Scan and Share is that entry point for ABDM. If it loses users here, they do not graduate to storing digital health records or consent-based sharing — the use cases that make the ecosystem valuable.

India has built the infrastructure. The next problem is conversion — getting the half of the population that has not yet participated in the ecosystem, one frictionless entry point at a time. That is a design and governance problem as much as a technology one. It is also, I would argue, the most interesting problem in DPI right now.

NB: Opinions expressed are from a product/user perspective. The technical and policy implications of a browser-first approach within ABDM’s architecture deserve deeper examination, and I welcome your perspective.