DPDP in Healthcare: A Patient Consent and Health Data Sharing Use Case

Healthcare is one of the clearest real-world examples of why data protection cannot be reduced to a privacy-policy exercise. A patient's name, mobile number, date of birth, appointment history, diagnostic reports, prescriptions, medical images, treatment history and insurance information can move through hospitals, laboratories, pharmacies, insurers, health-tech applications and other service providers during a single healthcare journey.

The Digital Personal Data Protection (DPDP) framework applies to personal data in digital form. For healthcare organisations, the practical challenge is not simply "getting consent". It is knowing what data is being processed, for which purpose, on what basis, who it is being shared with, how long it should be retained, and how the patient's choices can be demonstrated later.

This article walks through a practical healthcare use case: a patient visits a hospital, undergoes diagnostic tests, receives treatment, and later chooses to share selected health records with an insurer or another healthcare provider. The same architecture can be extended to diagnostic laboratories, telemedicine platforms, pharmacies, health-tech applications and healthcare research workflows.

Important: This is a practical compliance and technology use case, not legal advice. Healthcare organisations should assess their processing activities against the DPDP Act, DPDP Rules and other sector-specific laws, regulations and contractual obligations applicable to them.

Why healthcare is a high-priority DPDP use case

The DPDP Act does not create a separate statutory category called "sensitive personal data" in the way some other privacy regimes do. However, health information is personal data when it relates to an identifiable individual, and its misuse can have serious consequences for privacy, dignity, employment, insurance and access to services.

The healthcare ecosystem also creates a particularly complex data-sharing environment:

The key lesson is that one patient relationship can contain many distinct processing purposes. Treating every purpose as one blanket "healthcare consent" makes it difficult to demonstrate what the patient actually agreed to.

The healthcare use case: from registration to controlled data sharing

Consider a patient, Priya, who visits a multi-specialty hospital.

Her healthcare journey could look like this:

1. Priya creates a digital patient account.
2. The hospital collects information needed for registration and delivery of healthcare.
3. A doctor records consultation and treatment information.
4. The doctor orders blood tests and imaging.
5. The diagnostic laboratory generates reports.
6. Priya later wants another specialist to access selected reports.
7. Priya also submits a health-insurance claim.
8. The hospital wants to send optional health-program or wellness communications.
9. After treatment, some information may need to be retained for applicable legal, medical, contractual or operational requirements.
10. Priya may later exercise applicable data-principal rights or withdraw consent for processing where consent is the basis.

The important DPDP question is not simply whether the hospital has "a consent form".

It is:

Can the organisation demonstrate the purpose, notice, choice, sharing, withdrawal and resulting data-processing state for each relevant processing activity?

Step 1: Separate necessary healthcare processing from optional purposes

A hospital should first map its processing activities instead of putting everything behind one consent checkbox.

For example:

This separation is critical.

A patient seeking treatment should not have to give an unrelated marketing consent merely to receive medical care where that marketing processing is not necessary for the healthcare service.

Step 2: Give a usable privacy notice

The DPDP Act requires notice about the personal data proposed to be processed and the purpose of processing. The DPDP Rules 2025 require the notice to be clear, standalone and understandable, with an itemised description of personal data and the specified purpose. The Rules also require information about how the Data Principal can withdraw consent, exercise rights and make a complaint.

For a digital healthcare journey, the notice could be structured around understandable purposes rather than a long legal document.

For example:

Purpose: Diagnostic Testing

• Data: patient identity, test order, sample information and relevant clinical information
• Purpose: performing the requested diagnostic test and providing the report
• Recipient: diagnostic laboratory / relevant service provider
• Patient choice: as applicable to the processing basis
• Withdrawal / rights: accessible through the hospital's digital privacy centre

The objective is not to make the notice longer.

The objective is to make it understandable and demonstrable.

Step 3: Record granular patient choices

Suppose Priya has four optional choices:

• Share selected records with another doctor
• Share health information for a wellness programme
• Receive health-related promotional communications
• Allow a third-party health application to access selected records

A single database field such as:

consent = true

is not enough to create a useful operational record.

A better consent record captures information such as:

• Data Principal / patient reference
• Data Fiduciary
• Purpose
• Data attributes or categories involved
• Notice/version presented
• Consent status
• Timestamp
• Consent request/reference ID
• Recipient or Data Fiduciary involved in the sharing
• Retention or validity period, where applicable
• Withdrawal/revocation timestamp
• Consent event history

The DPDP Act requires consent to be free, specific, informed, unconditional and unambiguous, with clear affirmative action, and limits consent to the personal data necessary for the specified purpose. It also gives a Data Principal the right to withdraw consent where consent is the basis of processing.

This allows the organisation to answer a much more useful question during an audit or grievance:

"What exactly did this patient authorise, when, for which purpose, and what happened after the patient withdrew it?"

Step 4: Make health-record sharing purpose-specific

Now consider Priya's second-opinion consultation.

She wants Dr. Mehta at another hospital to see:

• MRI report
• Blood-test results
• Current prescription

She does not want to share:

• unrelated previous consultations
• older psychiatric records
• insurance documents

A consent architecture should therefore be capable of representing the patient's choice at a sufficiently granular level.

A simplified logical model could be:

Patient
  |
  +-- Purpose: Second Opinion
        |
        +-- MRI Report       = ALLOW
        +-- Blood Reports    = ALLOW
        +-- Prescription     = ALLOW
        +-- Insurance Data   = DENY
        +-- Other Records    = DENY

This is materially different from a single "I consent to sharing my medical records" checkbox.

It also creates a better foundation for interoperability between hospitals, diagnostic centres and health applications.

Step 5: Connect consent with the actual data-sharing transaction

Consent should not live in isolation from the system that actually shares the data.

A practical architecture can look like:

Patient / Data Principal
          |
          v
  Consent & Notice Layer
          |
          +------> Consent Record / Event History
          |
          v
 Hospital / Health-Tech Application
          |
          +------> EHR / EMR
          |
          +------> Laboratory / Imaging
          |
          +------> Insurance Workflow
          |
          +------> Other Healthcare Provider

When an application wants to share a record, it should be able to determine whether the relevant processing is authorised under the applicable basis and whether any patient choice or consent condition needs to be checked.

The consent layer should also generate an auditable event trail for actions such as:

• Consent request created
• Notice presented
• Consent granted
• Partial consent granted
• Consent denied
• Data shared
• Consent withdrawn
• Consent expired
• Sharing blocked after withdrawal

This is where a Consent Manager or consent-management platform can become an operational control rather than simply another screen in a patient application. The DPDP Rules 2025 specifically provide for registered Consent Managers to enable Data Principals to give, manage, review and withdraw consent and to maintain records of consents and data sharing.

A real-world example: hospital → diagnostic lab → specialist

Consider the following workflow.

1. Doctor orders a test

The hospital sends the minimum information required to the diagnostic laboratory to perform the test.

2. Laboratory processes the sample

The laboratory generates a report associated with the patient.

3. Report becomes available

The patient can access the report through the hospital or health application.

4. Patient requests a second opinion

The patient chooses to share the MRI report and blood results with another specialist for a defined purpose.

5. Consent is recorded

The system stores the notice/version, purpose, selected data, recipient, timestamp and consent status.

6. Specialist accesses the information

The receiving system verifies the applicable authorisation before releasing the selected records.

7. Patient withdraws the sharing permission

The consent status changes to withdrawn/revoked for that purpose.

8. Future access is blocked

The sharing layer checks the current consent state before a subsequent access request.

This creates a traceable chain between patient choice and system behaviour.

What about children and paediatric healthcare?

Healthcare organisations also need to consider children's personal data.

The DPDP framework contains specific provisions concerning processing of a child's personal data and verifiable consent of a parent or lawful guardian, subject to the applicable rules and exemptions. The DPDP Rules 2025 also contain a specific exemption framework for certain classes of Data Fiduciaries and purposes.

For a hospital, the practical requirement is to know:

• whether the patient is a child;
• who is authorised to provide the relevant consent;
• how that relationship is verified;
• which processing purpose is involved; and
• whether a specific statutory exemption applies.

This is particularly important for paediatric hospitals, vaccination platforms, child-health applications and family healthcare accounts.

Health data and third-party processors

A modern healthcare organisation rarely processes all information itself.

It may use:

• cloud infrastructure;
• hospital information systems;
• diagnostic platforms;
• appointment platforms;
• SMS/email providers;
• payment processors;
• insurance claim platforms;
• telemedicine software;
• analytics platforms;
• AI/ML services.

The organisation therefore needs a clear data-flow map.

For every significant processing activity, it should be possible to answer:

What data?
     |
     v
For what purpose?
     |
     v
Who processes it?
     |
     v
Who receives it?
     |
     v
Where is it stored?
     |
     v
How long is it retained?
     |
     v
What happens when the purpose ends?

DPDP compliance becomes much easier to operationalise when this map is connected to actual systems rather than maintained only in spreadsheets.

The AI use case: healthcare data used by AI systems

Healthcare organisations are increasingly using AI for:

• clinical decision support;
• medical-image analysis;
• summarisation;
• patient-service chatbots;
• appointment optimisation;
• fraud detection;
• operational analytics;
• research.

The DPDP question is not simply "Is AI allowed to process health data?"

The organisation needs to identify the specific processing purpose, the data involved, the applicable lawful basis, the recipient/processor relationship, the security controls and the patient's rights and choices where applicable.

For organisations that are notified as Significant Data Fiduciaries, the DPDP Rules also introduce additional obligations around due diligence concerning technical measures, including algorithmic software, to verify that they are not likely to pose a risk to the rights of Data Principals.

That makes AI/data-governance mapping particularly important for large healthcare organisations that may eventually fall within the SDF framework.

Data retention: a common healthcare challenge

Healthcare organisations often have legitimate reasons to retain records for extended periods.

But "we may need this data someday" is not a data-retention policy.

A practical retention framework should connect:

Data → Purpose → Applicable requirement → Retention period → Deletion/archival action

For example:

The DPDP framework's erasure and retention requirements therefore need to be implemented together with sector-specific record-retention obligations rather than treated as an isolated delete button.

What should a healthcare organisation build before the DPDP operational provisions apply?

The DPDP Act and Rules have a phased commencement structure. The final Rules were notified on 13 November 2025; Rules 3, 5–16, 22 and 23 are scheduled to commence eighteen months after publication, while Rule 4 has a one-year commencement period.

Healthcare organisations should not wait until the applicable commencement date to begin mapping their systems.

A practical readiness programme can be divided into seven workstreams:

Where IndiaConsent fits

A healthcare organisation does not need another isolated compliance dashboard.

The useful model is to connect DPDP controls with the systems already processing patient data.

IndiaConsent can be used as an operational consent and privacy layer for workflows such as:

• Patient consent capture and management
• Purpose-specific consent
• Granular data-attribute choices
• Consent withdrawal and revocation
• Consent receipts and evidence
• Web and cookie consent
• Grievance management
• Personal-data discovery
• Data mapping and lineage
• PIA/DPIA and risk assessment
• Breach and incident management
• Audit-oriented reporting

The goal is simple:

When a healthcare organisation says "the patient consented", it should be able to prove what was presented, what was chosen, what data was covered, what happened afterwards, and whether the current processing still matches that choice.

That is the difference between a consent form and an operational consent-management system.

Frequently Asked Questions

Does DPDP apply to hospitals and healthcare companies?

Yes, where they process digital personal data within the scope of the DPDP Act. The organisation needs to determine its role as Data Fiduciary or Data Processor for each relevant processing activity and assess the applicable obligations.

Is health data automatically classified as "sensitive personal data" under DPDP?

The DPDP Act does not use the same separate "sensitive personal data" category found in some other privacy frameworks. Health information can nevertheless be personal data and may require strong governance because of the potential impact of its misuse.

Does a hospital need consent for every piece of patient data it processes?

Not necessarily. The DPDP Act permits processing for a lawful purpose based on consent or certain legitimate uses. Healthcare organisations should identify the applicable basis for each processing activity rather than treating every activity as identical.

Should treatment consent and DPDP consent be treated as the same thing?

They should not automatically be treated as the same thing. Clinical consent, contractual or service requirements and data-protection consent can address different questions. The organisation should map the applicable legal and operational basis for each processing activity.

Can a patient consent to sharing only selected health records?

A well-designed consent architecture can support purpose-specific and granular choices. This is particularly useful where a patient wants to share selected reports with another healthcare provider without making their entire medical history available.

What happens when a patient withdraws consent?

The organisation should update the consent state and handle future processing according to the withdrawal and applicable DPDP requirements. Withdrawal does not automatically mean that every record must be immediately erased where another lawful basis or applicable retention requirement applies. The DPDP Act specifically requires the Data Fiduciary to cease, and cause its Data Processors to cease, processing based on withdrawn consent within a reasonable time, unless processing without consent is required or authorised by the Act, Rules or another law.

Are healthcare organisations automatically Significant Data Fiduciaries?

No. SDF status is determined through notification by the Central Government under the DPDP framework. Being a hospital, laboratory or health-tech company does not by itself make an organisation an SDF.

What should hospitals do now?

Start with data discovery and data-flow mapping, identify processing purposes and lawful bases, review notices, separate optional consent from necessary healthcare processing, implement auditable consent/withdrawal workflows, establish rights and grievance processes, and connect these controls to security and incident management.

---

Related Articles & Internal Resources

• DPDP Compliance Checklist for Enterprises: 7 Critical Steps
• Navigating DPDP Compliance in India's Insurance Sector
• How to Implement Consent Management Under the DPDP Act 2023
• What is DPDP Act 2023 Explained: A Comprehensive Guide

---

Primary Sources Cited

• Digital Personal Data Protection Act, 2023 — Full Text (MeitY Official PDF)
• Digital Personal Data Protection Rules, 2025 — Official Gazette Notification (PDF)
• Digital Personal Data Protection Rules, 2025 — MeitY Policy Portal
• Explanatory Note to the Draft DPDP Rules, 2025 — MeitY