ABHA and ABDM-ready clinic software, built into patient registration
Avinya Plus is ABHA-ready clinic software: scan a patient's ABHA QR, run Aadhaar eKYC to auto-fill demographics, or create an ABHA by Aadhaar OTP, then store the ABHA ID, ABHA address, and an Aadhaar reference token against the patient, with every consent written to an append-only ledger. ABDM gateway connectivity is vendor-configured.
Your patient has a health ID. Your register can't hold it.
Patients now turn up with an ABHA card and a QR on their phone, and most clinic software has nowhere to put it, so the receptionist re-keys the name off the card, mistypes the 14-digit number, and the link to the national health ID is lost. Worse, the obvious shortcut is to photograph the Aadhaar card, which is exactly the data you should never be hoarding. You need to capture the ABHA properly, pull demographics from a verified source, and prove the patient consented, all without storing a raw Aadhaar number anywhere.
Built for how clinics actually work.
Scan an ABHA QR and validate it, no retyping the 14-digit number
Open the ABHA QR scanner, point the camera at the patient's ABHA card or app QR, and the payload is validated through the ABDM gateway in one step, with no OTP on the QR path. On success you see the verified ABHA ID and a demographic delta that pre-fills the registration form, and when you scan from inside an existing patient the ABHA ID is persisted against them automatically. The raw QR payload is never stored.
Aadhaar eKYC that auto-fills demographics and stores a token, never the number
Type the patient's 12-digit Aadhaar, the eKYC provider sends an OTP to their Aadhaar-registered mobile (never from us), the patient reads it back, and verified name, date of birth, gender, and address fill any blank fields. What gets saved is a reference token, not the Aadhaar number. The input is wiped from memory the moment the provider holds the transaction, and a server-side guard rejects any provider response that hands back a 12-digit value.
Create or link an ABHA right at the front desk via Aadhaar OTP
For a patient who doesn't have an ABHA yet, enter their Aadhaar number and the ABDM gateway sends an Aadhaar-OTP; once the patient reads back the code, ABDM issues the ABHA and the linkage completes. The issued ABHA ID, and the ABHA address when returned, are saved against that patient, and if ABDM confirms the mobile the record is marked phone-verified. Avinya never originates the OTP message itself.
Five global identifiers per patient, globally unique, stored polymorphically
Each patient carries a set of global identifiers (ABHA ID, ABHA address, Aadhaar reference token, passport, and voter ID) in one table, separate from your clinic-internal MRN. Each (type, value) pair is globally unique, so the same ABHA can't be silently duplicated across two records, and the table is documented as DPDP-critical: it holds tokens and references only, never raw Aadhaar numbers.
Every ABHA link and eKYC writes a consent record you can't quietly edit
Capturing an ABHA or running eKYC isn't just a data write. It grants the clinic access to that patient and appends a row to an append-only consent ledger, tagged with how consent was evidenced (the ABDM gateway, or the Aadhaar eKYC flow). The ledger is built with no UPDATE or DELETE policies, so a consent event, once written, stays on the record. Consent kinds are first-class: Aadhaar-token consent, ABHA-linkage consent, and patient-app data access.
ABHA/Aadhaar IDs locked to the project that actually has consent
National health IDs are sensitive, so reads are scoped to the one clinic project you're working in: a patient's ABHA, Aadhaar token, and MRN come back only when that specific project can see the patient, via an approved consent grant or a real clinical link, never just because your login belongs to some other project. The whole ABHA and eKYC capability is also feature-flag gated server-side, so it's off until your clinic turns it on.
At a glance
- Three ABHA capture flows ship: scan an ABHA QR (no OTP), Aadhaar eKYC pre-fill, and create/link an ABHA by Aadhaar OTP.
- Five global identifier types are stored per patient (ABHA ID, ABHA address, Aadhaar reference token, passport, voter ID), each globally unique; clinic MRNs live in a separate per-tenant table.
- Aadhaar eKYC stores only a reference token, never the raw Aadhaar number; the input is wiped after the OTP is sent and a server guard rejects any 12-digit value returned by the provider.
- Every ABHA link and eKYC appends to an append-only consent ledger tagged 'abdm_gateway' or 'aadhaar_ekyc'; the ledger has no update or delete path.
- ABHA/Aadhaar/MRN reads go through a function scoped to the single consenting clinic project, and the ABHA and eKYC flows are feature-flag gated server-side.
- The ABDM gateway and eKYC layer are provider-agnostic and vendor-configured; OTPs are always sent to the patient by ABDM or the eKYC provider, never originated by Avinya. The platform is ABDM-ready, not ABDM-certified.
See how it stacks up.
| Feature | Paper / Excel | Legacy EMR | Avinya Plus |
|---|---|---|---|
| Scan an ABHA QR and validate it | No | Partial | Yes |
| Aadhaar eKYC auto-fills demographics | No | Partial | Yes |
| Create / link an ABHA by Aadhaar OTP | No | Partial | Yes |
| Stores a token, never the raw Aadhaar number | Photo of card | Partial | Yes |
| ABHA ID, ABHA address, Aadhaar ref, passport, voter ID | No | Partial | Yes |
| Append-only consent ledger on every link | No | No | Yes |
| Health IDs scoped to the consenting clinic | No | Partial | RLS |
Questions, answered.
Is Avinya Plus ABDM certified or ABDM compliant?
We don't make that claim. What's real and built is ABHA support: scanning an ABHA QR, Aadhaar eKYC, and creating or linking an ABHA by Aadhaar OTP, with ABHA IDs and a consent ledger stored against the patient. The actual ABDM gateway connectivity is vendor-configured. The platform is ABDM-ready, not a regulatory certification.
Do you store the patient's Aadhaar number?
No. The 12-digit Aadhaar is forwarded to the eKYC provider to trigger the OTP and then discarded. It's wiped from the screen the moment the transaction starts and is never logged or saved. What we persist is a reference token, and a server-side guard rejects any provider response that tries to hand back a raw 12-digit number.
Can I pull a patient's details from their ABHA or Aadhaar instead of retyping?
Yes. Scan the ABHA QR or run Aadhaar eKYC and verified name, date of birth, gender, and address pre-fill the registration form. eKYC only fills fields you've left blank, so it won't overwrite details you've already entered. It turns a careful re-typing job into a scan or a single OTP.
Is the patient's consent recorded when we link an ABHA?
Yes. Linking an ABHA or running eKYC grants the clinic access to that patient and appends a row to an append-only consent ledger, tagged with how consent was evidenced: the ABDM gateway or the Aadhaar eKYC flow. The ledger has no edit or delete path, so a recorded consent event stays on the record.
Can another clinic on the platform see a patient's ABHA or Aadhaar token?
No. Those national health IDs are returned only to the specific clinic project that can actually see the patient, through an approved consent grant or a real clinical link. Belonging to some other project on your login doesn't expose them, and the whole ABHA/eKYC feature is off until your clinic enables it.
Run your clinic on Avinya Plus.
Patient records, billing, and scheduling in one system your team will actually use.