Once your clinic is ABDM-enabled, a patient’s record can travel, on their consent, to any other connected facility they visit. It feels like magic at the front desk: link a visit, and later it’s available elsewhere. Under the bonnet there’s a tidy sequence of steps. You don’t need to build any of it, but understanding it helps you ask vendors the right questions and reassure patients honestly.
The key idea: a “care context”
ABDM organises a patient’s history into care contexts. A care context is simply “one episode of care” tied to a patient’s ABHA, and for most clinics that’s a visit. When your software links a visit to a patient’s ABHA, it’s creating a care context: a labelled entry that says “this patient had this encounter here, on this date.” The actual clinical content (the consult, prescription, invoice) is attached to it.
This is why linking at the front desk matters: no care context, nothing to share later. A good system creates the care context automatically as part of the normal visit, not as a separate chore.
The sequence, step by step
1. Identify the patient (ABHA). The patient’s ABHA is created or verified, ideally right at registration. This is the anchor everything hangs off.
2. Link the visit (create the care context). Your software tells ABDM “this ABHA has a care context here”, reusing the visit as that episode of care.
3. The patient consents. Nothing is shared automatically. When another facility (or the patient) requests records, the patient approves it through a consent manager on their phone, choosing what, with whom, and for how long. This consent step is the heart of ABDM; it’s what makes the whole thing trustworthy.
4. The record is packaged. On an approved request, your software produces the clinical record in the national FHIR format: a structured, standardised package that any ABDM system can read. This is the one genuinely technical piece, and it’s entirely your software’s job.
5. It’s encrypted and delivered. The package is encrypted and routed through ABDM’s rails to the requesting facility. It’s protected in transit; the gateway just carries it.
What your clinic does vs what the software does
The division of labour is clean:
- Your clinic does: capture the visit properly (consult, prescription, bill), create/verify ABHA at the desk, and link the visit. All normal front-desk work.
- The software does: create the care context, build the FHIR record, handle consent requests, and encrypt and deliver, all invisibly.
The single thing that makes this painless is having the visit’s data in one place. If the consult, prescription and invoice already live together, there’s a complete record to package. If they’re scattered across tools, someone has to assemble it first, which is exactly where fragmented setups struggle with ABDM.
What patients should hear from you
Patients increasingly ask “is my data safe?” The honest, reassuring answers: nothing is shared without their explicit consent; they control what’s shared and can revoke it; and the record is encrypted in transit. If you want to go deeper on how you protect data day to day, our note on keeping patient data safe and the DPDP compliance checklist both help.
The takeaway
Records sharing under ABDM isn’t something you engineer. It’s something your software does for you, provided you’ve linked the visit and captured it cleanly. When you evaluate systems, ask to see a care context being created and a record being shared on consent. With OlivHealth, that flow is part of standard ABDM-enabled onboarding, because the visit, notes and bill are already one record. Find your practice type to see how it looks for you.