What Happens When a Patient Consents to Sharing Health Records Through ABDM

The digital transformation of healthcare is making it easier for patients and healthcare providers to access medical information electronically. However, convenient access to health records must be balanced with privacy, security, and patient control.

This is where consent management becomes a critical part of the Ayushman Bharat Digital Mission (ABDM).

ABDM is designed around a consent-based approach to health information exchange. Its privacy and security framework describes the ecosystem as using a federated architecture and consent-based processing, with individuals having control over their health records.

But what actually happens when a patient agrees to share their health records?

Does the requesting hospital immediately receive everything?

Where does the data come from?

What role do HIP and HIU play?

Can the patient withdraw consent later?

For healthcare providers, hospitals, laboratories, and health-tech companies, understanding these questions is essential for designing ABDM-compliant and patient-centric digital health workflows.

This article explains the ABDM patient consent workflow in simple terms, while also covering the technical considerations that healthcare organizations need to understand.

What Is Patient Consent in ABDM?

In the context of ABDM, consent is the mechanism through which an individual authorizes the sharing or processing of their health information for a specified purpose.

The ABDM Health Data Management Policy describes electronic consent as a digital equivalent of permission that enables relevant collection or further processing of personal data. It also describes consent artifacts used to initiate the sharing of personal data between Health Information Providers (HIPs) and Health Information Users (HIUs).

In simple terms:

A healthcare system should not assume that technical connectivity automatically gives it access to a patient’s health records. The applicable consent workflow provides the authorization for health-information exchange.

This is an important distinction for digital health applications.

Why Is Consent Important in ABDM?

Health records contain highly sensitive information, including clinical history, laboratory results, prescriptions, diagnoses, and treatment details.

If healthcare systems could freely access each other’s databases simply because they were technically connected, patient privacy would be difficult to maintain.

ABDM therefore incorporates consent into its digital health architecture.

The official ABDM privacy and security material states that consent-based processing is intended to ensure that personal health records are not shared and processed without the individual’s consent.

Consent helps address questions such as:

• Who is requesting the information?
• What information is being requested?
• Why is the information required?
• Who will receive it?
• Is the patient authorizing the request?
• Can the patient withdraw the permission?

These questions become particularly important when health information moves between independent healthcare organizations.

Who Is Involved When a Patient Shares Health Records?

An ABDM health-information exchange workflow can involve several participants.

1. Patient

The patient is the individual whose health information is being requested or shared.

The patient’s consent is central to the applicable data-sharing workflow.

2. Health Information Provider (HIP)

A Health Information Provider, or HIP, is an entity that holds health information and can provide it through the applicable ABDM exchange mechanism.

Examples may include:

• Hospitals
• Clinics
• Diagnostic laboratories
• Imaging centers
• Other participating healthcare entities

For example, if a diagnostic laboratory has a patient’s blood-test report, that laboratory may act as the HIP when the information is requested through the appropriate ABDM workflow.

3. Health Information User (HIU)

A Health Information User, or HIU, is the entity requesting or using health information.

For example:

A patient visits a specialist who needs to review previous laboratory reports.

The specialist’s healthcare organization may initiate the request as the HIU.

4. Consent Manager

The consent-management layer supports the process through which consent can be obtained, recorded, and managed.

ABDM’s Health Data Management Policy specifies that where consent is obtained through a consent manager, records of consent and revocation are maintained, including consent transaction logs that support audit and review.

What Happens When a Patient Gives Consent?

The process can be understood through the following simplified journey:

Patient visits healthcare provider

↓

Provider requires previous health records

↓

HIU initiates a health-information request

↓

Consent request is presented to the patient

↓

Patient reviews the request

↓

Patient provides consent

↓

Consent artifact is generated/used in the applicable workflow

↓

HIP processes the authorized request

↓

Relevant health information is exchanged

↓

HIU receives the information

↓

Healthcare provider uses it for the authorized purpose

Let’s examine each stage in more detail.

Step 1: A Healthcare Provider Needs the Patient’s Previous Records

Imagine that a patient visits Hospital B for a specialist consultation.

The doctor wants to review the patient’s previous:

• Blood-test reports
• Diagnostic reports
• Prescriptions
• Discharge summaries
• Treatment information

The information may already exist in another healthcare organization’s system.

Instead of asking the patient to manually collect every document, an ABDM-enabled workflow can facilitate digital health-information exchange.

The requesting organization becomes the information user in the relevant workflow.

Step 2: The Health Information User Initiates a Request

The healthcare organization requiring the information initiates a request for the relevant health records.

This request is not equivalent to unrestricted access to the patient’s entire health history.

The request should be structured around the applicable healthcare purpose and consent parameters.

For example, a request may relate to a particular category of health information or a particular period.

This distinction is important:

Requesting information ≠ automatically receiving all available information.

Step 3: A Consent Request Is Presented to the Patient

The patient is presented with a consent request through the applicable ABDM-enabled application or workflow.

The request can communicate relevant details such as:

• Who is requesting the information
• What type of information is requested
• Why the information is required
• The applicable period or scope
• Other relevant consent parameters

A well-designed consent interface should be easy for patients to understand.

This is particularly important because consent should represent an informed decision rather than a confusing technical interaction.

ABDM’s Health Data Management Policy states that privacy notices should be clear, concise, and easily comprehensible to a reasonable person.

Step 4: The Patient Reviews the Request

At this stage, the patient can review the request before deciding whether to authorize it.

For example:

A hospital may request access to recent laboratory reports to help a physician evaluate the patient’s current condition.

The patient should be able to understand the nature of the request before providing consent.

This creates an important layer of transparency between the patient and the healthcare organization.

Step 5: The Patient Provides Consent

If the patient agrees, consent is recorded through the applicable ABDM workflow.

The Health Data Management Policy explains that electronic consent can be used for data access and sharing between HIPs and HIUs, and that a consent artifact is generated to initiate sharing of personal data.

A simplified representation is:

Patient Approval

→ Consent Recorded

→ Consent Artifact

→ Health Information Exchange

The consent artifact effectively acts as the digital representation of the patient’s authorization within the applicable exchange workflow.

Step 6: The Consent Is Communicated Through the Appropriate Mechanism

Once consent is provided, the relevant consent information is communicated through the applicable consent-management and ABDM infrastructure.

This allows the health-information provider to determine that the requested exchange has been appropriately authorized.

Importantly, the consent manager is not intended to become a repository for the patient’s underlying health records.

The ABDM Health Data Management Policy specifies that a consent manager should not access, process, or store the personal data shared pursuant to consent obtained through it. It does, however, maintain records of consent transactions and revocations for audit and review.

This distinction is important:

Consent metadata ≠ patient’s medical records.

Step 7: The Health Information Provider Responds

The HIP that holds the requested health information can now process the request according to the applicable consent and exchange workflow.

For example:

Diagnostic Laboratory

→ Receives an authorized request

→ Identifies the relevant health record

→ Processes the exchange

→ Makes the applicable information available

The information is then transmitted through the appropriate ABDM health-information exchange mechanisms.

Step 8: The Health Information Reaches the Requesting Provider

The HIU receives the health information through the appropriate digital workflow.

The doctor can then use the information for the relevant healthcare purpose.

For example, the specialist may review:

• Previous blood reports
• Imaging reports
• Prescriptions
• Discharge summaries
• Other available clinical information

This can provide the physician with additional context when evaluating the patient.

Does the Patient Share Their Entire Medical History?

Not necessarily.

A consent request is not intended to mean that a healthcare organization automatically receives unrestricted access to every record associated with the patient.

The information exchange depends on the request, available records, consent parameters, and applicable ABDM workflows.

This is one of the important differences between a consent-driven exchange model and an unrestricted database-access model.

For healthcare organizations, this means that application architecture should be designed around controlled information exchange rather than simply exposing a patient’s entire record whenever a request is made.

What Is a Consent Artifact in ABDM?

A consent artifact is a digital representation of the patient’s consent that facilitates the authorized exchange of health information.

The ABDM Health Data Management Policy specifically describes the generation of a consent artifact when electronic consent is used for data access and sharing between HIPs and HIUs.

In a simplified conceptual form, it captures information necessary to establish the context of authorization.

Depending on the applicable technical implementation, this can include elements related to:

• Who is giving consent
• Who is requesting the information
• What information is requested
• Purpose of the request
• Applicable time period
• Consent validity
• Other relevant parameters

For developers, the consent artifact is an important part of understanding how ABDM-enabled information exchange differs from ordinary API authorization.

What Happens to the Health Data After Sharing?

Once the information reaches the authorized information user, it can be processed according to the applicable purpose and policies.

Healthcare organizations should continue to apply appropriate:

• Access controls
• Security safeguards
• Privacy policies
• Data retention controls
• Audit mechanisms
• Internal governance procedures

Consent does not eliminate the healthcare organization’s responsibility to protect the information.

ABDM’s privacy and security framework emphasizes privacy and security by design and the need for healthcare providers to implement appropriate technical and organizational measures.

Can a Patient Revoke Consent?

Yes. ABDM’s privacy policy provides a mechanism for users to withdraw previously granted consent.

The ABDM Health Records/ABHA privacy policy states that users can withdraw consent through the “My consent” functionality by selecting previously granted consent and choosing the revoke option.

The Health Data Management Policy also states that when consent is revoked, the consent manager has a duty to notify the relevant data fiduciary, as applicable.

This means consent should not be viewed as a permanent, irreversible authorization.

What Does Consent Revocation Mean?

Consent revocation means the individual withdraws a previously granted authorization.

However, organizations should distinguish between:

Stopping future access or processing based on the revoked consent

and

Automatically deleting every copy of information that may already have been lawfully received or processed.

These are not necessarily the same thing.

The consequences of revocation depend on the applicable purpose, retention requirements, consent terms, and legal or regulatory obligations.

Therefore, healthcare organizations should design their systems to handle revocation carefully rather than assuming that a single database-delete operation represents the entire consent lifecycle.

How Is Consent Recorded?

Maintaining an auditable consent history is an important part of the ABDM model.

The Health Data Management Policy states that consent managers should maintain records of consent shared and revoked, along with consent transaction logs that enable audit and review of data use.

A healthcare application may therefore need to track events such as:

• Consent requested
• Consent granted
• Consent declined
• Consent revoked
• Consent expired
• Data requested
• Data exchanged

This provides organizations with greater visibility into the health-information exchange lifecycle.

How Does ABDM Protect Patient Privacy During This Process?

ABDM’s digital health ecosystem was designed around privacy and security by design.

The official ABDM privacy and security documentation highlights:

• Consent-based processing
• Federated architecture
• Protection of personal health records
• Security safeguards
• Limited access based on need
• Privacy considerations built into digital health building blocks

The federated architecture is particularly important.

ABDM does not require all health records to be stored in one central repository. Instead, healthcare information can remain distributed across participating systems while interoperability mechanisms enable appropriate exchange.

Where Does ABHA Fit Into the Consent Workflow?

The Ayushman Bharat Health Account (ABHA) provides a digital health identity that helps identify individuals and connect their records across participating systems.

The ABDM ecosystem describes the Health ID as a mechanism for uniquely identifying individuals, authenticating them, and threading their health records across systems with informed consent.

This makes identity an important foundation for health-information exchange.

A simplified relationship is:

ABHA

→ Helps identify the individual

→ Helps link relevant health records

→ Supports discovery and exchange workflows

→ Consent governs appropriate access and sharing

ABHA itself should therefore not be thought of as simply a database containing every medical record.

What Is the Role of the Personal Health Record?

A Personal Health Record (PHR) is another important part of the ABDM ecosystem.

The ABDM description of PHR emphasizes that it can draw information from multiple sources and that the information can be managed, shared, and controlled by the individual. It supports functions such as health-information discovery, linking records, viewing health records, and managing consents.

This gives patients greater visibility into their digital health information.

A simplified relationship can be understood as:

ABHA → Digital Identity

PHR → Personal access and management of health information

Consent → Authorization for applicable sharing

HIP → Source of health information

HIU → Requester/user of health information

Together, these components support a connected digital health ecosystem.

Example: Patient Shares a Laboratory Report With a Hospital

Consider this practical scenario.

Before the consultation

A patient previously completed a blood test at Laboratory A.

The report is available in the laboratory’s digital system.

New consultation

The patient visits Hospital B.

The doctor wants to review the previous report.

Information request

Hospital B initiates the applicable health-information request.

Consent request

The patient receives a consent request.

Patient decision

The patient reviews the request and approves it.

Consent processing

The applicable consent artifact and exchange workflow are initiated.

HIP response

Laboratory A processes the authorized request.

Data exchange

The relevant report is exchanged through the applicable ABDM mechanisms.

Doctor reviews the report

Hospital B receives the report and the doctor can use it as part of the patient’s consultation.

Later

If the applicable consent remains active, its terms continue to govern the authorized processing. If the patient revokes the consent, the applicable revocation workflow is triggered.

This illustrates how ABDM can turn a traditionally manual record-sharing process into a digital, consent-aware workflow.

What Does This Mean for Healthcare Providers?

For hospitals, clinics, laboratories, and other healthcare organizations, patient consent should be treated as a core component of ABDM integration.

Organizations should ensure that their systems can support:

Consent-aware workflows

The application should know when consent is required and what information can be exchanged under that consent.

Patient identification

Records need to be correctly associated with the appropriate individual.

Secure data exchange

Health information must be transmitted and handled securely.

Access controls

Only authorized users should be able to access health information.

Auditability

Organizations should be able to track relevant consent and information-exchange events.

Revocation handling

Applications should be capable of responding appropriately when consent is revoked.

What Does This Mean for Health-Tech Companies?

For health-tech companies building ABDM-enabled applications, consent should not be treated as a simple checkbox.

It can affect the entire application architecture.

A typical integration may involve:

Patient Interface

↓

Consent Request

↓

Consent Management

↓

ABDM Integration Layer

↓

HIP/HIU Workflows

↓

FHIR/Health Information Exchange

↓

Healthcare Application

Each layer needs to work correctly.

For example, if an application successfully requests consent but incorrectly maps the patient record, the overall workflow can still fail.

Similarly, an application may successfully receive health information but fail to enforce appropriate internal access controls.

ABDM integration therefore requires both interoperability engineering and privacy-aware application design.

Key Technical Considerations for ABDM Consent Management

1. Patient Identity Matching

Incorrect patient matching can result in serious data-privacy and clinical risks.

Healthcare systems need robust processes for associating health records with the correct individual.

2. Consent Lifecycle Management

Applications should account for the full lifecycle:

Request → Grant/Reject → Active → Expire/Revoke → Audit

Consent should not be treated as a one-time event.

3. Data Minimization

Applications should avoid requesting or processing more health information than is necessary for the intended purpose.

ABDM’s privacy framework emphasizes limiting collection and access and using health information appropriately.

4. Secure APIs

Healthcare applications should implement appropriate:

• Authentication
• Authorization
• Encryption
• Token management
• API security
• Monitoring

5. Audit Logging

Organizations should maintain appropriate records of consent and data-exchange events.

This is important for both operational monitoring and accountability.

6. Error Handling

Real-world systems can encounter:

• Expired consent
• Revoked consent
• Invalid requests
• Missing records
• Connectivity issues
• Authentication failures
• Data-format errors

Applications need robust handling for these scenarios.

Common Misconceptions About ABDM Consent

Misconception 1: Giving consent means sharing everything

Not necessarily.

The applicable consent request defines the context and scope of the authorized exchange.

Misconception 2: Once consent is given, it cannot be withdrawn

Incorrect.

ABDM’s privacy policy provides for withdrawal of previously granted consent.

Misconception 3: Consent means the consent manager stores the patient’s medical records

Not necessarily.

The Health Data Management Policy specifically states that a consent manager should not access, process, or store personal data shared pursuant to consent obtained through it, while maintaining consent transaction records.

Misconception 4: ABDM means all health records are stored centrally

No.

ABDM’s architecture is described as federated, meaning health records can remain distributed across systems while interoperability enables appropriate exchange.

Misconception 5: API connectivity automatically means data access

No.

Technical connectivity and authorization are separate concepts.

A system may be connected to the ABDM ecosystem while still requiring the appropriate consent and authorization before health information can be exchanged.

Benefits of Consent-Based Health Information Exchange

A properly implemented consent-driven exchange model can provide benefits for multiple stakeholders.

For patients

• Greater control over health-information sharing
• Better visibility into digital records
• Easier access to records
• Reduced dependence on physical documents
• Greater transparency around data sharing

For healthcare providers

• Better access to relevant patient history
• Improved continuity of care
• Less manual record collection
• More efficient information exchange

For health-tech companies

• Standardized interoperability opportunities
• Easier integration between healthcare systems
• Ability to build connected digital health applications
• Support for patient-centric healthcare workflows

For the broader ecosystem

• Reduced information silos
• Greater interoperability
• More connected healthcare delivery
• Stronger foundation for digital health services

How an ABDM Connector Can Support Consent-Based Data Exchange

Implementing ABDM directly into an existing healthcare application can involve multiple technical components.

An ABDM Connector can act as an integration layer between existing healthcare software and ABDM infrastructure.

Depending on the architecture, this can help organizations with:

• ABDM API integration
• Patient identity workflows
• Consent-related workflows
• HIP/HIU integration
• FHIR-based health-data exchange
• Data mapping and transformation
• Authentication
• Secure communication
• Transaction monitoring
• Error handling

The goal is to reduce integration complexity while allowing the organization’s existing HIS, EMR, EHR, LIS, or healthcare application to participate in ABDM-enabled workflows.

For B2B healthcare organizations, this can be particularly useful when ABDM interoperability needs to be introduced without rebuilding the existing healthcare application from scratch.

ABDM Patient Consent Workflow: At a Glance

The entire process can be summarized as:

1. Patient has digital health records

↓

2. Healthcare provider needs relevant information

↓

3. HIU initiates a request

↓

4. Consent request reaches the patient

↓

5. Patient reviews the request

↓

6. Patient grants consent

↓

7. Consent is recorded through the applicable ABDM workflow

↓

8. HIP receives/processes the authorized request

↓

9. Relevant health information is exchanged

↓

10. HIU receives the information

↓

11. Healthcare provider uses the information for the relevant purpose

↓

12. Consent can later expire or be revoked according to the applicable workflow

This lifecycle illustrates the fundamental principle:

The patient’s authorization is an important control point between health-data availability and health-data access.

Conclusion

Consent is at the heart of patient-controlled health-information exchange under ABDM.

When a patient agrees to share health records, the process involves much more than clicking an “Approve” button. The request moves through a structured ecosystem involving the patient, consent mechanisms, Health Information Providers, Health Information Users, digital health identities, and interoperable health-information exchange infrastructure.

The process can be summarized as:

Request → Patient Consent → Consent Artifact/Authorization → HIP Processing → Secure Health Information Exchange → HIU Access

ABDM’s approach is designed to give individuals greater control over their health information while enabling healthcare organizations to exchange relevant records digitally.

For healthcare providers and health-tech companies, this means that consent management should be treated as a fundamental part of ABDM integration, alongside interoperability, security, patient identity, data quality, and auditability.

A successful ABDM implementation is therefore not simply about connecting APIs. It is about creating a secure and interoperable healthcare environment in which the right health information can reach the right healthcare participant for the right purpose, with the patient’s consent at the center of the process.

Frequently Asked Questions

What happens after a patient gives consent in ABDM?

After consent is provided, the applicable ABDM consent and health-information exchange workflow enables the authorized request to be processed. The relevant Health Information Provider can then make the requested information available to the Health Information User according to the applicable consent parameters.

Is ABDM consent permanent?

No. Consent can have applicable validity conditions, and ABDM’s privacy policy provides a mechanism for users to withdraw previously granted consent.

Can patients revoke consent?

Yes. The ABDM privacy policy describes withdrawal through the consent-management functionality, including the ability to select previously granted consent and revoke it.

Does consent give a hospital access to every health record?

Not automatically. Health-information exchange is based on the applicable request and consent workflow rather than assuming unrestricted access to every record.

What is a consent artifact?

A consent artifact is a digital representation of consent used to initiate or facilitate health-information sharing between HIPs and HIUs under the applicable ABDM framework.

What is the difference between HIP and HIU?

A HIP is the entity that holds or provides health information, while an HIU is the entity that requests or uses health information through the applicable exchange workflow.

Does the consent manager store patient health records?

The ABDM Health Data Management Policy states that a consent manager should not access, process, or store personal data shared pursuant to consent obtained through it, while maintaining records of consent transactions for audit and review.