As healthcare in India becomes increasingly digital, the ability to exchange health information securely across hospitals, clinics, diagnostic centres, laboratories, and healthcare applications is becoming increasingly important.

Enquery Now

Connect with our team for quick support & guidance.

The Ayushman Bharat Digital Mission (ABDM) is designed to support an interoperable digital health ecosystem where health information can be exchanged through standardized digital infrastructure and consent-based mechanisms.

For healthcare organizations, however, ABDM integration is not simply about connecting a Hospital Information System (HIS), Electronic Medical Record (EMR), Laboratory Information System (LIS), or other healthcare application to an API.

Consent management is a critical part of the overall ABDM integration architecture.

It determines how a patient’s authorization is requested, communicated, processed, and reflected in health information exchange workflows.

This guide explains ABDM consent management from a healthcare organization’s perspective, including the roles of HIPs and HIUs, the consent lifecycle, technical considerations, common implementation challenges, and how an ABDM connector can simplify integration.

What Is ABDM Consent Management?

ABDM consent management refers to the processes and technical mechanisms used to manage an individual’s authorization for health information to be accessed or exchanged through the ABDM ecosystem.

In a simplified model:

Patient → Consent → HIU Request → HIP → Authorized Health Information → HIU

Here:

  • Patient/individual is the person whose health information is involved.
  • HIU (Health Information User) requests and uses health information.
  • HIP (Health Information Provider) provides relevant health information.
  • Consent infrastructure and workflows facilitate the authorization process.

The purpose is to enable health information exchange without treating a patient’s entire medical history as automatically accessible to every connected healthcare application.

Why Consent Management Matters in ABDM

Healthcare records contain highly sensitive information.

A patient’s digital health information may include:

  • Medical history
  • Diagnoses
  • Prescriptions
  • Laboratory reports
  • Radiology reports
  • Consultation records
  • Discharge summaries
  • Other clinical information

A patient may have records distributed across multiple healthcare organizations.

For example:

Hospital A → Diagnostic Centre B → Specialist Clinic C → Hospital D

Without appropriate controls, connecting these systems could create significant privacy and security challenges.

Consent management provides a structured mechanism for controlling health information exchange.

For healthcare organizations, effective consent management can help support:

Patient-centric data sharing

The individual remains central to decisions concerning the sharing of their health information.

Controlled access

Applications can request relevant information rather than assuming unrestricted access.

Interoperability

Healthcare organizations can participate in standardized digital health information exchange.

Better data governance

Organizations can establish clearer processes around when and why health information is accessed.

Understanding the HIP and HIU Roles

Consent management becomes easier to understand when the roles of HIP and HIU are clear.

Health Information Provider (HIP)

A HIP is an entity that generates, stores, and/or provides health information.

Examples may include:

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

For example, a hospital generates a patient’s discharge summary and stores it in its healthcare information system.

The hospital can act as a HIP when providing that information through the applicable ABDM workflow.

Health Information User (HIU)

An HIU is an entity that requests and uses health information.

For example, a hospital may need a patient’s previous laboratory report from another healthcare provider.

The hospital can act as an HIU when requesting that information through the applicable ABDM workflow.

One Organization Can Perform Both Roles

The HIP and HIU roles are not necessarily tied permanently to an organization.

Consider a hospital that:

  1. Generates a patient’s consultation record.
  2. Stores the record in its system.
  3. Provides the record through the appropriate ABDM workflow.

It is acting as a HIP.

The same hospital may later:

  1. Request a patient’s previous diagnostic report.
  2. Receive the authorized information.
  3. Use it during a consultation.

It is now acting as an HIU.

This distinction is important when designing healthcare software because the same application may need to support both types of workflows.

How ABDM Consent Management Works

A typical consent-driven health information exchange can be understood in several stages.

Step 1: Identify the information requirement

The healthcare organization first determines what information is required.

For example, a doctor may need:

  • Recent blood test results
  • Previous prescriptions
  • A discharge summary
  • A radiology report

The application should identify the relevant data requirement rather than automatically requesting everything available.

Step 2: HIU initiates the request

The healthcare application acting as an HIU initiates the appropriate request.

The request should communicate the relevant context required by the applicable ABDM workflow.

This can include information such as:

  • Requesting entity
  • Purpose
  • Type of health information
  • Relevant time period
  • Applicable consent parameters

The exact fields and workflow should follow the current ABDM technical specifications.

Step 3: Patient reviews the request

The patient receives the relevant consent interaction through the applicable ABDM-enabled application or workflow.

The patient should be able to understand:

Who is requesting the information?

What information is being requested?

Why is it being requested?

What period of information is involved?

This is an important part of a patient-centric consent model.

Step 4: Patient provides authorization

The patient can authorize the applicable request.

If authorization is not provided, the requesting application should not treat the request as permission to access the requested health information.

Step 5: HIP provides the information

Once the applicable conditions are satisfied, the relevant HIP can provide the authorized health information through the appropriate ABDM exchange workflow.

Step 6: HIU receives the information

The requesting healthcare application receives the health information.

The application can then use it for the authorized purpose.

For example, a doctor may review a previous diagnostic report during a consultation.

The ABDM Consent Lifecycle

Consent should not be viewed as a single event.

For healthcare software teams, it is more useful to think about consent as a lifecycle.

A simplified lifecycle looks like this:

Consent Request
      ↓
Consent Presented
      ↓
Patient Decision
      ↓
Consent Granted / Rejected
      ↓
Authorized Data Exchange
      ↓
Consent Active
      ↓
Consent Expiry / Withdrawal

Depending on the applicable ABDM workflow, additional states and events may need to be handled.

This has important implications for software architecture.

A healthcare application should be able to distinguish between different consent states rather than storing only:

consent = true

or

consent = false

What Should a Consent Request Communicate?

A consent request needs to provide enough context for an individual to understand what they are authorizing.

Important information can include:

Requesting organization

The patient should know which healthcare organization or application is requesting access.

Purpose

The reason for requesting the information should be clear.

Examples include:

  • Treatment
  • Diagnosis
  • Care coordination
  • Other applicable healthcare purposes

Information requested

The application should identify the relevant category of health information.

For example:

  • Laboratory reports
  • Prescriptions
  • Consultation records
  • Discharge summaries

Date range

The request may be limited to a relevant period rather than the patient’s complete health history.

Consent validity

Where applicable, the request should communicate the relevant duration or validity parameters.

The exact data elements should be implemented according to the applicable ABDM specifications.

Consent Management and Data Minimization

One of the important principles for healthcare software design is data minimization.

If an application only needs a patient’s latest laboratory report, it may not need to request every medical record available.

For example:

Broad request

“Give access to all health records.”

Focused request

“Provide relevant laboratory reports for the specified period.”

The second approach can reduce unnecessary exposure of health information.

For healthcare organizations, data minimization can contribute to:

  • Better privacy practices
  • Reduced security exposure
  • More understandable consent requests
  • Improved application performance
  • Better clinical usability

Consent Is Not the Same as Authentication

This is a common area of confusion.

Authentication asks:

Who are you?

It establishes the identity of a user or system.

Authorization asks:

What can you access?

It determines whether an authenticated entity has permission to perform an action.

Consent asks:

Has the individual authorized the relevant use or exchange of their health information?

These concepts are related but serve different purposes.

A user successfully logging into a hospital application does not automatically mean the application can access every health record associated with that patient.

Consent Management vs Access Control

Healthcare organizations should also distinguish between consent management and internal access control.

Suppose a patient has authorized Hospital A to access certain health information.

The hospital still needs appropriate internal controls governing which employees, clinicians, applications, or services can access the information.

Therefore, an effective security architecture can involve multiple layers:

Patient Consent
      ↓
ABDM Authorization
      ↓
Application Access Control
      ↓
User Authentication
      ↓
Health Information

Consent does not replace an organization’s internal security controls.

Consent and Health Information Security

Consent management needs to work alongside broader healthcare security measures.

Organizations should consider controls such as:

  • Secure API communication
  • Authentication
  • Authorization
  • Encryption
  • Access control
  • Credential management
  • Audit logging
  • Monitoring
  • Secure data storage
  • Incident management

The goal is to protect health information throughout its lifecycle.

That lifecycle can be represented as:

Request → Consent → Exchange → Processing → Storage → Access → Audit

What Happens When Consent Is Rejected?

A healthcare application needs to handle consent rejection as a legitimate business outcome.

For example:

A hospital requests a patient’s previous diagnostic reports.

The patient chooses not to authorize the request.

The application should be able to:

  1. Record the appropriate status.
  2. Avoid treating the request as authorized.
  3. Inform the relevant user that the information is unavailable because authorization was not granted.
  4. Continue the healthcare workflow where possible without unauthorized access.

The user experience should be designed carefully so that a consent rejection does not create confusing application behaviour.

What Happens When Consent Expires?

Consent may have a defined validity period under the applicable workflow.

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

For example:

Consent Granted
      ↓
Consent Active
      ↓
Authorized Data Access
      ↓
Consent Expires
      ↓
New Request / Authorization

Healthcare applications should therefore maintain appropriate consent status information and respond correctly when authorization is no longer active.

What About Consent Withdrawal or Revocation?

Where the applicable ABDM consent framework supports withdrawal or revocation, healthcare applications need to handle changes in consent status appropriately.

This means that software should not be designed around the assumption that:

Once authorized = always authorized

Instead, systems should be able to respond to relevant consent state changes.

This is particularly important for:

  • API access
  • Data retrieval
  • User interfaces
  • Audit logs
  • Data processing workflows
  • Access-control decisions

The exact implementation should follow the current ABDM specifications.

Consent Management for Hospitals

Hospitals typically have complex healthcare information environments.

A hospital may have:

  • HIS
  • EMR/EHR
  • Laboratory system
  • Radiology system
  • Pharmacy system
  • Billing system
  • Patient portal
  • Mobile application

ABDM consent workflows need to operate across the relevant components.

For example:

                  Hospital
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
      HIS           EMR           LIS
       │             │             │
       └─────────────┼─────────────┘
                     ↓
             ABDM Integration
                     │
                     ↓
            Consent / Exchange

This is one reason ABDM integration can become technically complex in larger healthcare organizations.

Consent Management for Diagnostic Laboratories

Diagnostic centres are important participants in digital health information exchange because they generate significant volumes of health information.

A laboratory may generate:

  • Blood reports
  • Urine reports
  • Pathology reports
  • Imaging reports
  • Other diagnostic records

When acting as a HIP, the laboratory’s systems need to support the appropriate mechanisms for making eligible health information available through ABDM workflows.

This can require integration between:

  • LIS
  • Patient records
  • Reporting systems
  • ABDM integration layer
  • Relevant health information exchange components

Consent Management for Health-Tech Applications

Health-tech companies may have different requirements depending on their business model.

For example, an application may need to:

  • Request health information
  • Display health records
  • Store authorized information
  • Support healthcare professionals
  • Exchange information with participating healthcare providers

In such cases, consent should be integrated into the product’s core architecture.

It should not be implemented as an isolated feature added after the application’s data-access layer has already been developed.

Common ABDM Consent Management Challenges

1. Complex legacy systems

Many healthcare organizations operate multiple legacy applications.

These systems may not have been designed for consent-based interoperability.

Integrating them with ABDM can therefore require additional middleware or integration layers.

2. Inconsistent data formats

Different systems may represent health information differently.

A consent workflow can successfully authorize an exchange, but the receiving application still needs to correctly interpret the information.

Interoperability therefore requires both:

Authorization + Data compatibility

3. Multiple consent states

Real-world systems need to handle more than a simple yes/no response.

They may need to process:

  • Pending
  • Granted
  • Rejected
  • Expired
  • Withdrawn/revoked where applicable
  • Failed
  • Unavailable

The application’s state-management architecture should reflect the relevant ABDM workflow.

4. User experience

Patients may not understand highly technical consent terminology.

Healthcare organizations need to present requests in a way that is clear and understandable while remaining aligned with the applicable specifications.

5. Security

Consent does not eliminate the need for strong security.

Organizations still need appropriate protection for health information before, during, and after exchange.

6. Changing technical requirements

ABDM is a large and evolving digital health ecosystem.

Healthcare technology teams need to monitor applicable ABDM specifications, implementation requirements, and technical updates rather than building against outdated assumptions.

How Should Healthcare Organizations Design Consent Management?

A practical implementation approach can be divided into several stages.

Stage 1: Map existing systems

Identify all systems that create, store, consume, or exchange health information.

For example:

  • HIS
  • EMR
  • LIS
  • RIS
  • Pharmacy system
  • Patient application

Stage 2: Identify HIP and HIU workflows

Determine:

Which information does the organization provide?

Which information does the organization need to request?

This helps determine where HIP and HIU capabilities are required.

Stage 3: Map data requirements

Identify:

  • Data categories
  • Record types
  • Data sources
  • Data formats
  • Relevant date ranges
  • Existing patient identifiers

Stage 4: Design consent workflows

Define how the application will handle:

  • Consent requests
  • Consent decisions
  • Active authorization
  • Expiration
  • Withdrawal/revocation where applicable
  • Failed requests

Stage 5: Integrate security controls

Implement appropriate:

  • Authentication
  • Authorization
  • Encryption
  • Access control
  • Audit logging
  • Monitoring

Stage 6: Test end-to-end scenarios

Testing should go beyond successful consent.

Organizations should test scenarios such as:

  • Consent granted
  • Consent rejected
  • Consent expired
  • Consent withdrawn/revoked where applicable
  • Information unavailable
  • Invalid request
  • API failure
  • Duplicate request
  • Data-format mismatch

This helps ensure the application behaves predictably under real-world conditions.

How an ABDM Connector Can Simplify Consent Integration

For healthcare software vendors, implementing ABDM workflows directly into multiple healthcare products can increase development and maintenance complexity.

An ABDM connector can serve as an integration layer between the existing healthcare application and the ABDM ecosystem.

Depending on the architecture and capabilities of the connector, it can help simplify areas such as:

  • ABDM API connectivity
  • HIP/HIU workflows
  • Consent-related communication
  • Health information exchange
  • Data transformation
  • Authentication and secure communication
  • Error handling
  • Integration monitoring

For example, a hospital may already have an established HIS and EMR.

Instead of rebuilding those systems around ABDM, an integration layer can connect existing workflows to the relevant ABDM interfaces.

The connector does not eliminate the organization’s responsibility for appropriate consent, privacy, security, governance, and compliance. Rather, it can reduce the engineering effort involved in implementing the technical integration layer.

ABDM Consent Management: A Real-World Example

Consider a patient visiting Hospital B.

The patient previously received treatment at Hospital A.

Hospital B needs relevant records from Hospital A.

Step 1: Hospital B requests information

Hospital B’s application acts as the HIU.

Step 2: Consent request is initiated

The application initiates the appropriate consent workflow.

Step 3: Patient reviews the request

The patient receives information about the requested health records and the purpose of the request.

Step 4: Patient provides authorization

The patient authorizes the request through the applicable ABDM consent mechanism.

Step 5: Hospital A provides the information

Hospital A acts as the HIP and makes the authorized information available through the applicable exchange workflow.

Step 6: Hospital B receives the records

The records become available to Hospital B’s application.

Step 7: Doctor uses the information

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

The complete flow can be summarized as:

Patient → Consent → HIU → ABDM Exchange → HIP → Authorized Records → HIU

Best Practices for ABDM Consent Management

Healthcare organizations should consider the following practices when implementing consent-based workflows.

1. Make consent explicit and understandable

Patients should be able to understand what they are authorizing.

2. Request only necessary information

Avoid unnecessarily broad information requests.

3. Treat consent as dynamic

Consent can have a lifecycle and should not be treated as a permanent Boolean permission.

4. Keep consent separate from authentication

A successful login does not automatically establish permission to access health information.

5. Maintain appropriate audit trails

Record relevant consent and data-access events according to applicable requirements.

6. Protect information after access

Once health information reaches an HIU, the organization remains responsible for protecting it under its applicable privacy and security obligations.

7. Design for failure scenarios

Consent rejection, expiration, unavailable information, and technical failures should be expected and handled gracefully.

8. Follow current ABDM specifications

Technical implementation should be based on the latest applicable ABDM documentation and specifications.

ABDM Consent Management Checklist

Before implementing consent-based ABDM workflows, healthcare organizations can review the following checklist

  • Identify HIP and HIU use cases
  • Map health information sources
  • Identify health information consumers
  • Define data categories
  • Map existing healthcare systems
  • Implement applicable consent workflows
  • Handle consent status changes
  • Support appropriate authorization checks
  • Implement authentication and access control
  • Secure API communication
  • Protect stored health information
  • Maintain appropriate audit logs
  • Test consent rejection
  • Test consent expiry
  • Test applicable withdrawal/revocation scenarios
  • Test API and integration failures
  • Validate interoperability
  • Monitor integration performance
  • Review ABDM specification updates regularly

Conclusion

ABDM consent management is a fundamental part of India’s interoperable digital health ecosystem.

For healthcare organizations, consent should not be treated as simply a button that a patient clicks before data is transferred. It is a broader workflow involving the individual, HIU, HIP, consent mechanisms, authorization, health information exchange, security, and auditability.

A successful implementation therefore requires coordination between:

Business workflows + Healthcare data + Consent + APIs + Security + Interoperability

Hospitals, diagnostic centres, clinics, and health-tech companies should design ABDM integration with these requirements in mind from the beginning.

For healthcare software vendors, an ABDM connector can help simplify the technical integration layer by connecting existing healthcare applications with the relevant ABDM interfaces and workflows.

Ultimately, the goal is not just to exchange health records digitally. It is to enable secure, interoperable, and appropriately authorized health information exchange while keeping the individual at the centre of the process.

Frequently Asked Questions

What is ABDM consent management?

ABDM consent management refers to the mechanisms and workflows used to obtain, process, maintain, and enforce an individual’s authorization for applicable health information exchange within the ABDM ecosystem.

Why is consent important in ABDM?

Consent helps establish a controlled, patient-centric approach to health information exchange instead of giving healthcare applications unrestricted access to patient records.

Who gives consent?

The individual whose health information is being requested provides the relevant authorization through the applicable consent workflow.

What is the role of an HIU?

An HIU requests and uses health information for an applicable purpose and participates in the required consent and exchange workflow.

What is the role of a HIP?

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

Is an ABHA number the same as consent?

No. An ABHA is associated with digital health identity/account functionality, while consent relates to authorization for applicable health information access or exchange.

Does consent provide unrestricted access to all medical records?

No. Consent should be understood in the context of the relevant request, scope, purpose, validity, and applicable ABDM workflow.

Can a healthcare organization be both a HIP and HIU?

Yes. An organization can provide its own records as a HIP and request records from another participating entity as an HIU.

Is consent management only a frontend feature?

No. It affects the entire application architecture, including backend services, authorization logic, API workflows, data access, auditability, and security.