DPDP Compliance for HealthTech: ABDM, Sensitive Health Data, and Clinical Consent

Health Data Under the DPDP Act Is Personal Data

The DPDP Act 2023 does not create a separate classification for “sensitive personal data.” Unlike the GDPR, which designates health data as a special category requiring elevated protections, the DPDP Act treats all personal data under one regime. A patient’s diagnosis, a prescription record, and a mailing address are all “personal data” under the statute.

This does not make health data any less consequential. It means the legal framework is uniform, but the operational burden is not.

Health data carries three characteristics that amplify compliance complexity:

1. Volume and velocity. A single hospital information system processes thousands of patient records daily. Each record contains multiple data points (demographics, vitals, diagnoses, prescriptions, imaging references) that constitute personal data under the Act.
2. Regulatory overlap. HealthTech companies in India operate under the DPDP Act, the Clinical Establishments Act, ICMR guidelines, Telemedicine Practice Guidelines, and (increasingly) the Ayushman Bharat Digital Mission framework. DPDP obligations do not replace these. They layer on top.
3. Consequence of breach. Health data exposure causes irreversible harm. A leaked financial record can be remediated with a new account number. A leaked HIV diagnosis cannot be undone. The Data Protection Board will assess penalties with this asymmetry in mind.

HealthTech companies that treat DPDP compliance as a checkbox exercise, equivalent to updating a privacy policy, will find themselves exposed on multiple fronts. The correct approach is to treat the Act as an infrastructure requirement, not a documentation exercise.

For a full overview of the DPDP Act’s scope and obligations, see the DPDP Act explainer.

ABDM and DPDP: Parallel Frameworks

The Ayushman Bharat Digital Mission (ABDM) is India’s national digital health infrastructure. Its core components include:

ABDM Component	Function
ABHA (Ayushman Bharat Health Account)	Unique health ID for every citizen
Health Information Exchange & Consent Manager (HIE-CM)	Facilitates consent-based health data sharing between providers
Health Information Providers (HIPs)	Entities that generate health data (hospitals, labs, pharmacies)
Health Information Users (HIUs)	Entities that request and consume health data (doctors, insurers)

ABDM has its own consent architecture. When a Health Information User requests a patient’s records from a Health Information Provider, the request routes through the HIE-CM, which obtains the patient’s consent before any data flows.

This raises a practical question: does ABDM consent satisfy DPDP consent requirements?

The answer is conditional. ABDM consent governs data sharing between ABDM-registered entities through the ABDM network. DPDP consent governs the lawful basis for processing personal data by a Data Fiduciary. If a healthtech platform collects patient data outside the ABDM framework (through its own intake forms, its own app, its own teleconsultation interface), ABDM consent does not cover that processing. A separate DPDP-compliant consent mechanism is required.

Where the two frameworks reinforce each other:

• Purpose specification. Both ABDM and DPDP require that data be collected for a stated purpose. A platform that already specifies purposes for ABDM data requests has a foundation to build DPDP consent notices on.
• Data access audit trails. ABDM requires logging of all data access events. The DPDP Act requires Data Fiduciaries to maintain records demonstrating consent. These audit requirements overlap significantly.
• Revocation rights. Both frameworks grant individuals the right to revoke consent. Building a unified revocation mechanism that satisfies both ABDM and DPDP requirements is more efficient than maintaining two separate systems.

HealthTech companies building on ABDM should treat DPDP compliance as an extension of their existing consent infrastructure, not a parallel track. The technical patterns are compatible. The legal obligations, however, are distinct and must be met independently.

Telemedicine and Digital Health Platforms

A single teleconsultation generates multiple data flows, each of which constitutes a processing activity under the DPDP Act:

Data Flow	Processing Activity	DPDP Implication
Patient registers on platform	Collection of name, phone, email, demographics	Consent required at registration
Patient describes symptoms	Collection of health information	Purpose must be specified (consultation)
Doctor issues prescription	Generation of medical record	Retention obligation under medical regulations
Prescription sent to pharmacy	Sharing with third party	Separate consent or lawful basis required
Lab results uploaded	Collection from third-party source	Patient must be informed of data source
Payment processed	Financial data collection	Purpose limitation applies
Platform sends follow-up notifications	Marketing or care communication	Distinct consent if purpose differs from consultation

Each of these flows must be mapped, documented, and covered by a valid consent mechanism. The consent management requirements under the DPDP Act demand that consent be specific to each purpose. A single “I agree to the terms” checkbox at registration does not cover downstream sharing with pharmacies, insurers, or analytics providers.

Retention vs Purpose Limitation

Telemedicine platforms face a tension between two obligations:

• The DPDP Act’s principle of purpose limitation requires that data be deleted once the purpose for which it was collected has been fulfilled.
• Medical record retention laws (including state-level Clinical Establishments Act rules and Telemedicine Practice Guidelines) require that consultation records be retained for specified periods (typically three to seven years, depending on jurisdiction).

When a legal retention obligation exists, the DPDP Act permits continued storage. But the data must be ring-fenced: retained for compliance purposes only, not repurposed for marketing, analytics, or model training. If a platform retains consultation records for the mandated period but also feeds that data into a recommendation engine, the retention is lawful but the secondary processing is not (unless covered by separate consent).

Clinical Trials and Research Data

Clinical trial data occupies a unique position under the DPDP Act. Trial participants provide consent under frameworks governed by the ICMR’s National Ethical Guidelines for Biomedical and Health Research, the New Drugs and Clinical Trials Rules (2019), and institutional ethics committees.

DPDP consent requirements apply in addition to these existing frameworks. A clinical trial consent form that meets ICMR standards may not meet DPDP standards if it does not:

• Specify the Data Fiduciary (the entity responsible for data processing, which may differ from the principal investigator)
• Itemise each processing purpose separately (data collection for the trial, sharing with a sponsor, submission to a regulatory authority, future research use)
• Provide a withdrawal mechanism that is as straightforward as the consent mechanism

De-identification and Anonymisation

The DPDP Act applies to personal data. Data that has been genuinely anonymised (such that no individual can be identified from it, even with additional data) falls outside the Act’s scope.

For clinical research, this creates a compliance pathway:

1. Collect data with full DPDP-compliant consent
2. De-identify the dataset for analysis purposes
3. If the de-identification is irreversible (true anonymisation), the anonymised dataset is no longer subject to DPDP obligations
4. If the de-identification is reversible (pseudonymisation), the dataset remains personal data and DPDP obligations continue to apply

The distinction matters. Many healthtech platforms claim to “anonymise” data by removing names and replacing them with identifiers. If those identifiers can be reversed (through a lookup table, through combination with other datasets, through re-identification techniques), the data is pseudonymised, not anonymised. The DPDP Act still applies.

Research organisations should document their anonymisation methodology and be prepared to demonstrate, if challenged, that re-identification is not reasonably possible.

Children’s Health Data: Additional Protections

The DPDP Act imposes specific obligations for processing the personal data of children (defined as individuals under 18 years of age). For paediatric healthtech platforms, school health programmes, and child mental health apps, these obligations add a layer of compliance that cannot be designed around.

Key requirements under the Act:

• Verifiable parental or guardian consent must be obtained before processing any child’s personal data. The platform must make reasonable efforts to verify that the person providing consent is, in fact, the child’s parent or legal guardian.
• No behavioural monitoring or tracking of children is permitted for advertising or profiling purposes.
• No processing that is likely to cause harm to a child’s well-being is permitted.

For healthtech applications, the parental consent requirement creates a practical challenge. A 16-year-old seeking mental health support through an app must have a parent or guardian provide consent before the platform can process their data. This may conflict with the clinical objective of providing accessible, stigma-free care.

The Act does allow the Central Government to exempt certain categories of Data Fiduciaries from the parental consent requirement for specific purposes. Whether healthcare will receive such an exemption remains to be seen. Until then, the obligation stands.

For a detailed analysis of children’s data protections, see the children’s data protection guide.

Data Principal Rights in Healthcare

The DPDP Act grants data principal rights that apply fully to health data. These include:

Right	Healthcare Application
Right to information	Patients can request a summary of all personal data being processed, the purposes, and any third parties it has been shared with
Right to correction and erasure	Patients can request correction of inaccurate health records or deletion of data no longer required
Right to grievance redressal	Patients can file complaints with the Data Fiduciary’s grievance officer, and escalate to the Data Protection Board
Right to nominate	Patients can nominate another individual to exercise their data rights in the event of death or incapacity

Erasure vs Retention: The Healthcare Tension

The right to erasure under the DPDP Act is not absolute. Where another law mandates retention (as medical record laws frequently do), the retention obligation prevails. However, the Data Fiduciary must:

• Inform the Data Principal that their erasure request cannot be fulfilled due to a legal retention requirement
• Specify the legal basis for continued retention
• Delete the data once the retention period expires

A healthtech platform that receives an erasure request cannot simply respond with “we need to keep your records.” It must identify the specific legal mandate, communicate it clearly, and ensure deletion occurs when that mandate no longer applies.

Building a DPDP-Compliant Health Data Architecture

Compliance is not achieved through policy documents alone. It requires architectural decisions embedded in how health data is collected, stored, processed, and shared.

Data Inventory

Before any consent mechanism can be built, the platform must know what data it holds. A health data inventory should document:

• Every category of personal data collected (patient demographics, clinical records, payment information, device data)
• The source of each data category (direct from patient, from a referring provider, from ABDM, from a lab)
• The processing purpose for each category
• The retention period and legal basis for retention
• All third parties with whom the data is shared

Consent Management

Health platforms typically process data for multiple purposes: clinical care, billing, quality improvement, research, regulatory reporting. Each purpose requires its own consent basis. A consent management system for healthtech must support:

• Granular, purpose-specific consent collection
• Easy withdrawal for any individual purpose without requiring withdrawal from all purposes
• Audit trails that record when consent was given, for what purpose, and by whom
• Re-consent workflows for existing data collected before DPDP enforcement

For implementation patterns, see the consent management guide.

Security Proportionate to Sensitivity

The DPDP Act requires “reasonable security safeguards” to protect personal data. While the Act does not prescribe specific technical measures, the expectation is that security should be proportionate to the sensitivity and volume of data processed.

For health data, this means:

• Encryption at rest and in transit for all patient records
• Role-based access controls that limit data access to authorised personnel
• Audit logging of all access to patient data
• Regular security assessments and penetration testing
• Incident response plans with defined timelines (the Act requires breach notification to the Data Protection Board)

Breach Response Planning

Health data breaches carry penalties of up to Rs 250 crore under the DPDP Act. Beyond financial penalties, a health data breach triggers mandatory notification to the Data Protection Board and, in many cases, to affected Data Principals.

A breach response plan for healthtech should include:

• Detection mechanisms (monitoring for unauthorised access, anomalous data exports, system intrusions)
• Defined escalation paths and notification timelines
• Communication templates for the Data Protection Board and for patients
• Post-breach remediation procedures
• Documentation of all actions taken (the Board will review the response, not just the breach)

Run Your Free Gap Assessment

If your healthtech platform processes patient data in India, the DPDP Act applies to you. The question is not whether you need to comply, but where your gaps are.

ConsentOS provides a free DPDP Gap Assessment that evaluates your current compliance posture across consent management, data principal rights, breach readiness, and cross-border data transfers. The assessment takes under five minutes and produces an actionable compliance report.

For healthtech-specific guidance, including ABDM integration requirements and clinical data obligations, visit the HealthTech industry page.