DPDP Act24 May 2026 7 min read

DPDP Act for Healthtech: Patient Data Protection

How the DPDP Act 2023 applies to Indian healthtech companies — patient consent, health data handling, telemedicine obligations, ABDM integration, and SDF classification risk.

Key Takeaways

Health data is not a separate "sensitive" category under the DPDP Act, but its inherent sensitivity makes healthtech companies high SDF candidates.
Patient consent must be specific to each processing purpose — one registration consent is not sufficient for all health data uses.
ABDM (Ayushman Bharat Digital Mission) integration creates new consent flows that must be coordinated with DPDP Act compliance.
Telemedicine platforms must meet both MCI Telemedicine Practice Guidelines and DPDP Act consent and security standards.
Health data breaches are among the most harmful — invest in security safeguards that reflect the sensitivity of the data.

In this guide

Health Data Under the DPDP Act: No Separate Category
Patient Consent: Getting It Right
ABDM Integration and DPDP Act Compliance
Telemedicine Platform Obligations
Security Safeguards for Health Data
Health Data Sharing: Research, Insurance, and Diagnostics
SDF Classification Risk for Healthtech Companies

Health Data Under the DPDP Act: No Separate Category

The DPDP Act does not create a "sensitive personal data" or "special categories" designation like GDPR's Article 9. Health data is personal data like any other — subject to the same consent, notice, security, and rights obligations. There is no enhanced consent standard or additional prohibition on health data processing in the statute itself.

This does not mean health data carries no additional weight. The Data Protection Board's penalty assessment under Section 33 considers "the type and sensitivity of personal data involved." A breach of health data will be viewed as more serious than a breach of, say, purchase history. Healthtech companies should implement security controls and consent practices that reflect the inherent sensitivity of health data, even without a formal "special category" requirement.

The SPDI Rules 2011 under the IT Act explicitly listed health data as sensitive personal data with heightened requirements. Those Rules will be superseded by the DPDP Act regime. The practical effect is that the formal distinction disappears but the operational sensitivity remains — and healthtech companies should maintain high standards throughout the transition.

Patient consent in healthtech is operationally complex. A patient creating an account on a health platform may be asked to consent to: account creation and health record storage; sharing with their treating doctor; sharing with a diagnostic lab; sending health reminders (marketing-adjacent); anonymised contribution to research datasets; and sharing with insurance providers. Each of these is a distinct purpose requiring separate, specific consent under Section 6.

The power imbalance in healthcare — patients seeking care may feel unable to freely refuse consent — is a concern that DPDP Act's "free" consent requirement addresses. You cannot condition access to healthcare on consent to non-essential secondary uses of health data. Core processing (care delivery, medical records) may be justified on a medical emergency basis (Section 7(c)) but commercial secondary uses require genuine free consent.

Implement a granular consent architecture: one consent for care delivery and medical records (clearly necessary for the service); separate opt-ins for research participation, insurance sharing, marketing, and analytics. Make each opt-in independently revocable without affecting care delivery. Design the interface so that declining secondary consents is as easy as accepting them.

ABDM Integration and DPDP Act Compliance

The Ayushman Bharat Digital Mission (ABDM) creates a national health data ecosystem built on the Health Data Management Policy (HDMP), which governs the creation, use, and sharing of health data through ABHA (Ayushman Bharat Health Account) numbers. Healthtech platforms integrating with ABDM must comply with both the HDMP and the DPDP Act.

The HDMP and DPDP Act share a consent-based framework for health data sharing. ABDM consent flows — where a patient uses their ABHA number to consent to share health records from one provider to another — are broadly consistent with DPDP Act's specific consent requirement. However, ABDM consent covers data sharing between health facilities; downstream use by the receiving facility requires additional DPDP Act-compliant consent.

For healthtech companies, ABDM integration should be designed to capture both the HDMP-required consent artefact and the DPDP Act-required consent record. Ensure your consent management system can distinguish between ABDM sharing consent (for the data transfer) and DPDP Act processing consent (for downstream use of the received data).

Telemedicine Platform Obligations

Telemedicine platforms operate under the MCI Telemedicine Practice Guidelines 2020, which require patient identification, consultation records, and prescription generation with specific data elements. These data processing requirements create a legal obligation (Section 7(b) equivalent) that provides a lawful basis for the core clinical data processing.

However, the Telemedicine Guidelines do not address secondary uses of consultation data — analytics, population health insights, training AI diagnostic models, or marketing targeted to patient conditions. These secondary uses require DPDP Act-compliant consent, which must be obtained separately from the clinical consent inherent in the consultation.

Telemedicine platforms that record video consultations face particular obligations. Video recordings are biometric/personal data; recording must be disclosed and consented to. Retention of recordings beyond clinical necessity requires a specific lawful basis. Consider whether recordings are necessary at all for clinical purposes — if they are not, a default no-recording policy is the simplest compliance position.

Security Safeguards for Health Data

Section 8(5) requires "reasonable security safeguards." For health data, the reasonable security bar is higher than for less sensitive data — a Data Protection Board considering a health data breach will expect more robust security than it would for a breach of, say, a retail loyalty programme.

Minimum security controls for healthtech: end-to-end encryption for all health records at rest and in transit; strict role-based access (doctors see their own patients' records only; administrative staff have no access to clinical data); audit logging of all access to health records; multi-factor authentication for all clinical system access; and regular penetration testing.

Build your security programme to a recognised standard — ISO 27001 or SOC 2 — and document the certification. For healthcare-specific security requirements, the NDHM (National Digital Health Mission) Security standards provide Indian-specific guidance. A certified security programme is both good practice and strong evidence for the Data Protection Board that you implemented reasonable safeguards.

Health data sharing for medical research is addressed in Section 7(d) (public interest) and Section 7(c) (health emergencies), but routine commercial research partnerships require consent. If you share patient data — even anonymised — with a pharmaceutical company, medical research institute, or health analytics firm, obtain specific consent from patients for that sharing.

Insurance data sharing is particularly sensitive. Sharing health data with insurance companies for underwriting or claims purposes requires: explicit consent from the patient (not bundled with clinical consent); disclosure of the specific information shared; and a clear statement of the consequences of sharing (e.g., affect on insurance premiums). Patients must be able to decline insurance sharing without losing access to healthcare services.

Diagnostic lab integrations — where a healthtech platform orders tests and receives results — involve sharing health data with the lab and receiving results back. Ensure that DPAs with diagnostic labs cover the DPDP Act's security and breach notification requirements, and that patients are informed of the lab sharing as part of their consent to diagnostic testing.

SDF Classification Risk for Healthtech Companies

Large healthtech platforms — telemedicine platforms with millions of users, national hospital information systems, national health record repositories — are strong SDF classification candidates. They process high volumes of inherently sensitive health data, their processing decisions can directly affect individuals' health and insurance access, and they are increasingly critical to national health infrastructure.

For healthtech SDFs, additional obligations include: a DPO with healthcare data expertise; DPIAs for AI diagnostic tools, health risk scoring models, and population health analytics; annual independent data audits; and potentially stricter data localisation for health data. Health data localisation — storing all patient data in India — is consistent with current MoHFW requirements and healthtech companies generally operate India-only data infrastructure.

Begin preparing for SDF classification now if you process health data at scale. The compliance investments required — DPO appointment, DPIA processes, audit infrastructure — are significant but the risk of being unprepared when classification occurs is existential. A health data breach in an organisation with no compliance programme will attract the maximum penalty.

Frequently Asked Questions

Does a hospital's electronic medical record system need DPDP Act compliance?

Yes. A hospital is a Data Fiduciary for patient health records. It must implement security safeguards, respond to patient rights requests (access, correction), and notify the Board of breaches. Hospitals are also subject to the Clinical Establishments Act and state health regulations, which create overlapping obligations. DPDP Act compliance must be integrated with existing healthcare regulatory compliance.

Can health data collected under ABDM be used for commercial purposes?

ABDM's Health Data Management Policy restricts the use of ABDM-linked health data to health purposes. Using ABDM-linked data for insurance underwriting, targeted advertising, or other commercial purposes outside health would breach both the HDMP and require specific DPDP Act consent. Maintain strict separation between ABDM-integrated health data and commercial data pipelines.

A patient asks to delete their medical records under Section 12. Must we comply?

Medical records retention is governed by the Clinical Establishments Act and professional medical regulations, which require retention for specified periods (typically 7 years for clinical records). A DPDP Act erasure request cannot override these legal retention requirements. Decline the erasure, explain the legal basis, and erase the data once the retention period expires.

We use AI to flag high-risk patients for proactive outreach. Does the DPDP Act regulate this?

Profiling patients using AI to make decisions that affect their care pathway involves processing personal health data for purposes beyond direct care delivery. This requires specific consent under Section 6 (consent for AI-based risk stratification as a distinct processing purpose) and, for SDFs, a DPIA. Ensure patients understand that AI tools are used in their care pathway and can opt out without losing access to basic care.

Our platform is used by both doctors and patients. What are our obligations to each?

For doctor/provider accounts: you process their professional identity data as a Fiduciary — basic DPDP Act obligations apply. For patient data that doctors upload or that flows through clinical workflows: you may be a Processor (if the hospital/clinic is the Fiduciary) or a Fiduciary (if you determine purpose and means directly). Analyse each data flow carefully and ensure DPAs with healthcare provider customers are in place.