> ## Content Index
> Fetch the complete content index at: https://carexaos.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# ABDM consent flows, explained in plain English
- URL: https://carexaos.com/blog/abdm-consent-flows-explained-in-plain-english/
- Published: 2026-11-02T18:32:24.000Z
- Updated: 2026-11-02T18:32:24.000Z
- Description: How consent requests, consent artefacts and record sharing work, and what they mean for your front desk.
- Author: Carexa OS
- Tags: ABDM

The Ayushman Bharat Digital Mission (ABDM) lets a patient's health records move between hospitals, labs and apps, but only when the patient agrees. That agreement is called *consent*, and it is the part of ABDM front-desk teams ask about most. Here is how it works, without the jargon.

## The people in the picture

- **The patient**, identified by an **ABHA number** (a 14-digit health ID) and an **ABHA address**, which works like an email address for health records.
- **Health Information Providers (HIPs):** hospitals, clinics and labs that hold records about the patient.
- **Health Information Users (HIUs):** anyone who wants to see those records, such as a doctor at another hospital.
- **The consent manager:** the service, used through the patient's health records app, that asks the patient for permission and keeps track of what they agreed to.

## Step 1: records are linked to the patient's ABHA

When a patient with an ABHA visits your hospital, the visit's records can be *linked* to their ABHA. ABDM calls each set of linked records a *care context*, for example an OPD visit or an admission. Linking does not send the records anywhere; it only lets the patient's app know that your hospital holds them.

Linking can start from your side, after registration or discharge, or from the patient's side, when they find your hospital in their app and ask to link records held there.

## Step 2: someone asks to see the records

Say the patient is now seeing a specialist at another hospital. That hospital (the HIU) raises a **consent request**. The request says:

- **why** the records are needed (for example, care management);
- **which kinds** of records: prescriptions, discharge summaries, diagnostic reports and so on;
- **from which period**;
- and **how long** the permission should last.

## Step 3: the patient decides

The patient sees the request in their app and can approve it, narrow it, or deny it. Nothing moves without their say-so. Once they approve, the consent manager creates a **consent artefact**, a digitally signed record of exactly what the patient agreed to, and sends it to the hospitals involved.

## Step 4: the records move, encrypted

Your hospital, as the HIP, checks the artefact and sends only the records it covers, encrypted so that only the requesting hospital can read them. The consent manager arranges the exchange but does not keep a copy of the health records.

## Step 5: the patient stays in control

A consent has an expiry date, and the patient can revoke it in their app. After that, no more records can be fetched under it.

## What this means for your front desk

- Ask every patient for their ABHA, or help them create one. It is what makes linking possible.
- With **Scan & Share**, a patient scans your counter's QR code with their app and their details arrive at registration, which shortens the queue.
- Explain consent simply: *"Your records are shared only when you approve it in your app, and only what you approve."*

## How Carexa OS handles it

Carexa is built for ABDM. ABHA creation and verification, Scan & Share registration, consent-based record sharing and HPR and HFR lookups are part of the everyday workflow, not a separate module. ABHA-linked sharing happens only with the patient's consent, captured through the ABDM consent flow. See [Built for India](https://carexaos.com/india?ref=carexaos.com) for more.