How Consent Works in the ABDM Ecosystem

The Ayushman Bharat Digital Mission (ABDM) is building a connected digital health ecosystem in India where health information can be exchanged securely and interoperably across participating healthcare organizations.

At the centre of this ecosystem is an important principle: health information should be exchanged through consent-based mechanisms.

For hospitals, diagnostic laboratories, clinics, health-tech companies, and healthcare software vendors, understanding how consent works in ABDM is essential. ABDM integration is not simply about connecting two healthcare systems through APIs. Applications must also support the appropriate consent, authorization, identity, data exchange, and security workflows.

This article explains how consent works in the ABDM ecosystem, the role of patients, Health Information Providers (HIPs), Health Information Users (HIUs), and consent-related infrastructure, and what healthcare technology companies should consider when implementing ABDM.

What is Consent in the ABDM Ecosystem?

In the context of ABDM, consent refers to an individual’s authorization for their health information to be accessed, exchanged, or used for a specified purpose under the applicable digital health workflows.

The basic concept is straightforward:

The individual should have control over whether their health information is shared for an intended purpose.

For example, imagine that a patient has laboratory reports stored with a diagnostic centre. Later, the patient visits another hospital and wants the doctor to review those reports.

The hospital may initiate a request for the relevant health information. The patient can then provide the required consent through the applicable ABDM workflow.

The authorized information can subsequently be made available to the requesting application.

This creates a consent-driven model rather than an architecture based on unrestricted access to a patient’s medical history.

Why is Consent Important in Digital Health?

Healthcare information is highly sensitive.

A patient’s digital health records may include:

• Clinical consultations
• Diagnoses
• Laboratory reports
• Radiology reports
• Prescriptions
• Discharge summaries
• Immunization information
• Medical observations
• Other health-related documents

As healthcare becomes increasingly digital, multiple organizations may participate in a patient’s care.

A patient might have information distributed across:

Hospital → Diagnostic Centre → Specialist → Pharmacy → Clinic

Without appropriate controls, exchanging information across these systems could create privacy and security risks.

A consent-based architecture helps establish a controlled mechanism through which health information can be accessed for an intended purpose.

For organizations implementing ABDM, consent should therefore be treated as a core architectural component, rather than merely a user-interface feature.

The Basic ABDM Consent Flow

At a high level, a consent-based health information exchange can be understood through the following sequence:

Patient
   │
   │ Requests / authorizes access
   ▼
HIU
   │
   │ Consent request
   ▼
Consent Management Layer
   │
   │ Authorization
   ▼
HIP
   │
   │ Authorized health information
   ▼
HIU
   │
   ▼
Healthcare service / clinical workflow

The exact technical implementation depends on the ABDM specifications and the participating systems, but the conceptual model is important:

Request → Consent → Authorization → Health Information Exchange → Use

Who Are the Key Participants?

Understanding the participants makes the consent process easier to understand.

1. Patient / Individual

The patient is the individual whose health information is being accessed or exchanged.

The individual is central to the consent process because the exchange is designed around the individual’s authorization.

For example, a patient may authorize a hospital to access selected health records for treatment.

2. Health Information User (HIU)

A Health Information User (HIU) is the entity that requests and uses health information.

For example:

• Hospital
• Clinic
• Healthcare application
• Telemedicine platform
• Other eligible healthcare service

The HIU initiates the request when it needs health information.

3. Health Information Provider (HIP)

A Health Information Provider (HIP) is an entity that generates, stores, and/or provides health information.

Examples can include:

• Hospitals
• Diagnostic centres
• Clinics
• Other participating health information providers

The HIP is responsible for making the relevant information available through the appropriate ABDM workflow once the required conditions are satisfied.

4. Consent Management Infrastructure

Consent-related infrastructure facilitates the process through which consent requests and responses are managed.

It helps establish a structured mechanism between the individual, the requesting application, and the source of health information.

This is important because the HIU and HIP should not need to establish a completely independent consent mechanism for every possible data exchange relationship.

How Does ABDM Consent Work? Step by Step

Let’s consider a practical example.

A patient, Priya, visits a hospital.

The doctor wants to review her previous diagnostic reports from another healthcare provider.

Step 1: Patient has existing digital health records

Priya previously completed a diagnostic test at a participating laboratory.

The laboratory has her digital report.

The laboratory can act as a HIP for the relevant health information.

Step 2: Hospital needs the information

Priya visits another hospital.

The doctor needs her previous diagnostic report.

The hospital’s ABDM-enabled application can act as an HIU and initiate the appropriate request.

Step 3: Consent request is generated

The relevant consent request contains information necessary for the individual to understand what is being requested.

Depending on the applicable workflow, this can include details such as:

• What information is being requested
• The purpose of access
• The requesting entity
• Relevant time period
• Other consent parameters

The goal is to provide the individual with sufficient context to make an informed authorization decision.

Step 4: Patient reviews the request

Priya reviews the consent request.

She can decide whether to authorize the requested access based on the information presented to her.

This is a key distinction between consent-based access and simply giving an application permanent access to a patient’s records.

Step 5: Patient provides consent

If Priya authorizes the request, the consent workflow records the authorization according to the applicable ABDM mechanism.

The consent does not mean that the HIU automatically receives unrestricted access to every health record.

The access is associated with the relevant request and its applicable parameters.

Step 6: HIP provides the authorized information

The relevant HIP can then make the requested information available through the appropriate ABDM health information exchange process.

Step 7: HIU receives the information

The hospital’s application receives the authorized health information.

The application can then incorporate the information into the relevant healthcare workflow.

For example, the doctor may review the previous diagnostic report before deciding whether another test is necessary.

Consent Is More Than a Simple “Allow” Button

One common mistake in healthcare software design is treating consent as a simple:

Allow → Access Granted

model.

In a digital health ecosystem, consent needs to be associated with the context of the information exchange.

The system should consider factors such as:

• Who is requesting the information?
• What information is being requested?
• Why is it being requested?
• For what period is access relevant?
• Who is the information about?
• What authorization has been provided?
• How should the information be transferred?
• How should access be recorded and audited?

This is why ABDM consent workflows have implications for both product design and backend architecture.

What Information Can Be Included in a Consent Request?

A consent request needs to communicate the scope and context of the proposed data access.

Depending on the applicable ABDM workflow and implementation, relevant information can include:

Purpose

Why does the HIU need the information?

Examples could include:

• Treatment
• Diagnosis
• Care coordination
• Other permitted purposes

Data requested

The system should identify the type of health information required.

For example:

• Diagnostic reports
• Prescriptions
• Consultation records
• Discharge summaries

Time period

The request may relate to health records from a particular period.

For example:

January 2026 – June 2026

This is different from requesting a patient’s entire historical record.

Requesting organization

The individual should be able to understand which entity is requesting access.

Consent duration

Where applicable, the consent framework can include information about the period for which authorization applies.

The precise fields and implementation should follow the relevant ABDM specifications rather than being independently designed by each healthcare application.

One-Time Consent vs Ongoing Access

Another important concept is the distinction between consent for a specific request and broader or longer-duration authorization.

A healthcare application should not assume that because a patient previously authorized one request, it can automatically access unrelated information later.

For example:

Request A

A hospital requests laboratory reports for a patient’s current consultation.

Request B

The same hospital later wants access to a different category of records.

The second request may require its own appropriate consent depending on the applicable workflow and authorization.

This is important from both a privacy and product-design perspective.

Can Patients Revoke Consent?

Consent management should account for the possibility that an individual may withdraw or revoke authorization where supported by the applicable consent framework.

From a software perspective, this means applications should not treat consent as a permanent permission stored indefinitely in a database.

Instead, systems should be designed to recognize the current state and applicable scope of authorization.

This has implications for:

• Consent records
• Authorization checks
• Data-access workflows
• Audit logs
• API behavior
• User interfaces

Healthcare software vendors should implement these workflows according to the latest applicable ABDM specifications and policies.

Consent and the ABHA Ecosystem

The ABHA (Ayushman Bharat Health Account) provides a digital health identity/account framework within ABDM.

However, it is important to distinguish identity from consent.

An ABHA identifier helps associate an individual with their digital health ecosystem.

It does not mean that every healthcare organization automatically gets unrestricted access to that person’s health records.

A simplified conceptual model is:

ABHA → identity

Consent → authorization

HIP → health information source

HIU → health information requester/user

These components work together but serve different purposes.

Consent vs Authentication: They Are Not the Same

Healthcare software teams sometimes use the terms authentication and consent interchangeably.

They represent different concepts.

Authentication

Authentication answers:

“Who are you?”

For example, verifying the identity of a user or system.

Authorization

Authorization answers:

“What are you allowed to access?”

Consent

Consent answers:

“Has the individual authorized this particular use or exchange of their information under the applicable consent process?”

A secure ABDM implementation needs to address these concepts appropriately.

Consent vs Authorization

Consent and authorization are closely related but should not be treated as identical technical concepts.

For example:

A user may authenticate successfully into a healthcare application.

That does not automatically mean the application is authorized to access every health record.

Similarly, an application may have technical connectivity with another system.

That does not by itself establish the patient’s consent for a particular health information exchange.

This distinction is particularly important when designing APIs and backend services.

What Happens if Consent Is Not Granted?

If a patient does not authorize a request, the requesting application should not treat the refusal as an authorization to access the requested health information.

From a product perspective, healthcare applications should be prepared to handle outcomes such as:

• Consent granted
• Consent rejected
• Consent expired
• Consent withdrawn/revoked where supported
• Request unsuccessful
• Data unavailable
• Technical failure

This is why consent handling should be integrated into the application’s state management and error-handling architecture.

What Happens When Consent Expires?

Consent may have an applicable validity period.

Once the authorization is no longer valid, an application should not assume that the previous authorization remains active indefinitely.

For example:

Consent Created
      ↓
Consent Active
      ↓
Health Information Access
      ↓
Consent Expires
      ↓
New authorization may be required

The exact behaviour depends on the applicable ABDM consent specification and the terms of the particular authorization.

Healthcare applications should therefore track relevant consent states instead of relying on a simple Boolean value such as:

consent = true

A production implementation may need a much richer consent state model.

Technical Architecture for Consent-Based ABDM Integration

From a B2B software perspective, consent affects multiple layers of an ABDM integration.

A simplified architecture can look like:

┌──────────────────────────────┐
│       Healthcare Application │
│                              │
│  Hospital / Clinic / HIS     │
└──────────────┬───────────────┘
               │
               ▼
       ABDM Integration Layer
               │
       ┌───────┴────────┐
       │                │
       ▼                ▼
 Consent Workflow   Health Information
       │              Exchange
       │                │
       └───────┬────────┘
               ▼
        ABDM Ecosystem
               │
       ┌───────┴────────┐
       ▼                ▼
      HIP              HIU
       │                │
       └───────┬────────┘
               ▼
            Patient

A real implementation can involve additional components and services depending on the application’s ABDM role and use case.

Data Security and Consent

Consent alone does not make a healthcare application secure.

A comprehensive implementation should also address:

• Encryption
• Authentication
• Authorization
• Secure API communication
• Access controls
• Credential protection
• Audit logging
• Data minimization
• Secure storage
• Monitoring
• Incident management

For example, even when a patient has authorized access, the receiving application should still protect the information after it arrives.

This means security needs to be implemented throughout the information lifecycle:

Request → Authorization → Transfer → Processing → Storage → Access → Audit

Consent and Data Minimization

An important principle for healthcare software is requesting only the information that is necessary for the intended use case.

Suppose a doctor needs a patient’s recent blood test.

Requesting every health record the patient has ever generated may not be necessary.

A more focused request can reduce unnecessary data exposure.

For B2B healthcare applications, this principle can also improve:

• User experience
• Data processing efficiency
• Security
• Storage requirements
• Clinical usability

The application’s consent interface should therefore be designed around meaningful and understandable information requests.

Designing a Good Consent Experience

Consent is not only a backend requirement.

The user interface matters too.

A healthcare application should avoid presenting patients with complicated technical language that makes it difficult to understand what they are authorizing.

A good consent experience should clearly communicate:

Who is requesting the information?

For example:

ABC Hospital

What information is requested?

For example:

Diagnostic reports

Why is it requested?

For example:

For consultation and treatment

Which period is covered?

For example:

January 2026 – September 2026

What should the patient do?

Provide a clear option to authorize or decline the request according to the applicable workflow.

The exact UI and consent fields should follow the relevant ABDM specifications.

Common Consent Implementation Mistakes

1. Treating consent as permanent

A previous consent does not necessarily mean permanent access to future information.

2. Requesting excessive information

Applications should avoid requesting information beyond what is required for the intended use case.

3. Storing consent as a simple Boolean

A production-grade consent model may need to capture substantially more information than:

true or false.

The implementation should reflect the applicable consent specifications, including relevant scope, purpose, validity, and status information.

4. Ignoring consent expiry

Applications need to handle changes in consent status.

5. Building consent only into the frontend

A consent button in the user interface is not sufficient.

Consent-related checks and workflows need to be reflected in backend services and data-access logic.

6. Failing to maintain auditability

Healthcare systems should maintain appropriate records of relevant access and exchange activities.

7. Confusing authentication with consent

A logged-in user does not automatically have permission to access a patient’s ABDM health records.

What Healthcare Software Companies Should Consider

For software vendors integrating ABDM, consent should be considered during the architecture and product-planning stages.

1. Identify your ABDM role

Determine whether your application is acting as:

• HIP
• HIU
• Both, depending on workflows

2. Map your data

Identify:

• What records your system generates
• Where those records are stored
• Which records need to be shared
• Which records your application may need to request

3. Map consent workflows

Document when your application:

• Requests information
• Receives consent
• Receives rejection
• Receives records
• Encounters expired authorization
• Needs to initiate another request

4. Implement appropriate security

Protect information throughout the entire exchange lifecycle.

5. Build for interoperability

Healthcare records may originate from different systems.

Your application should therefore be designed to work with standardized ABDM data exchange mechanisms and applicable health-record formats.

6. Monitor ABDM specifications

Digital health standards and implementation requirements can evolve.

Development teams should build against the current applicable ABDM specifications rather than relying on outdated documentation or assumptions.

How an ABDM Connector Can Simplify Consent-Based Integration

For healthcare software vendors, implementing ABDM workflows directly into an existing product can involve significant development effort.

An ABDM connector can provide an integration layer between the healthcare application’s existing infrastructure and ABDM services.

Depending on the implementation, such a layer can help manage areas including:

• API connectivity
• HIP/HIU workflows
• Consent-related interactions
• Health information exchange
• Data transformation
• Authentication
• Error handling
• Integration monitoring
• Workflow orchestration

For example, an existing hospital management system may already handle patient registration, consultations, prescriptions, laboratory information, and discharge summaries.

Rather than rebuilding these systems, an integration layer can connect the existing workflows with the relevant ABDM interfaces.

However, the connector should not be viewed as a replacement for the healthcare organization’s responsibility for privacy, security, consent handling, data governance, and regulatory compliance.

ABDM Consent: A Practical Example

Let’s bring everything together.

Scenario

A patient visits Hospital X.

The hospital wants access to the patient’s previous laboratory reports.

1. HIU initiates request

Hospital X’s application acts as the HIU.

2. Consent request

The application initiates the appropriate consent workflow.

3. Patient reviews request

The patient sees what information is being requested and why.

4. Patient authorizes

The patient provides the required consent.

5. HIP processes the request

The relevant diagnostic centre or healthcare organization acts as the HIP and makes the authorized information available according to the applicable ABDM workflow.

6. HIU receives information

Hospital X receives the requested health information.

7. Clinical use

The doctor can review the relevant report as part of the patient’s care.

The process can be summarized as:

Patient → Consent → HIU Request → HIP → Authorized Data → HIU

Benefits of a Consent-Based ABDM Ecosystem

A properly implemented consent-driven ecosystem can support several important objectives.

Patient-centric information sharing

Patients can participate in decisions concerning the exchange of their health information.

Interoperability

Different healthcare systems can exchange information through standardized digital mechanisms.

Reduced dependency on paper

Digital records can reduce reliance on physical medical documents.

Better continuity of care

Authorized clinicians can potentially access relevant information from previous healthcare interactions.

Reduced duplication

Access to previous records can help healthcare providers understand existing information before ordering or repeating investigations, where clinically appropriate.

Better digital health infrastructure

Standardized consent and exchange mechanisms can make it easier for different healthcare applications to participate in a connected ecosystem.

Conclusion

Consent is one of the foundational principles of the ABDM ecosystem.

The objective is not simply to make healthcare records digital, but to enable them to move between participating systems through interoperable and consent-based mechanisms.

For healthcare providers and technology companies, this means ABDM implementation needs to go beyond API connectivity.

A robust ABDM-enabled application should consider:

• Patient identity
• HIP and HIU roles
• Consent requests
• Authorization
• Health information exchange
• Data interoperability
• Security
• Auditability
• Consent status and validity
• Appropriate data access

For healthcare software vendors, designing these capabilities into the product architecture from the beginning can make ABDM integration more scalable and reliable.

In short: ABDM connects healthcare systems, but consent provides the foundation for responsible health information exchange.

Frequently Asked Questions

What is consent in ABDM?

Consent in ABDM refers to the individual’s authorization for applicable health information to be accessed or exchanged through the consent-based digital health framework.

Who gives consent in ABDM?

The consent is provided by the individual whose health information is being requested, subject to the applicable ABDM workflow and rules.

Does ABHA automatically give access to health records?

No. A digital health identity and consent are separate concepts. Having an ABHA does not mean every healthcare organization automatically receives unrestricted access to the individual’s health records.

What is the role of an HIU?

An HIU requests and uses health information through the applicable ABDM workflow and requires appropriate authorization/consent for accessing the relevant information.

What is the role of a HIP?

A HIP generates, stores, and/or provides health information through the applicable ABDM health information exchange process.

Can a hospital be both HIP and HIU?

Yes. A hospital can provide its own records as a HIP and request records from another healthcare provider as an HIU.

Can consent be revoked?

The applicable ABDM consent framework can support withdrawal/revocation mechanisms. Implementations should follow the current ABDM specifications governing consent status and revocation.

Is ABDM consent the same as login authentication?

No. Authentication establishes identity, while consent relates to an individual’s authorization for a specific health information exchange or use under the applicable framework.