The DPDPA does not publish a static list of "sensitive categories" the way GDPR does. Instead, Section 10(1) empowers the Central Government to designate Significant Data Fiduciaries based on a set of criteria, and "sensitivity of personal data" is explicitly one of them. Health data clears that bar without ambiguity.

Consider a mid-size private hospital chain processing 50,000 patient records monthly: diagnostics, discharge summaries, prescription histories, and insurance claims. Once the government notifies thresholds for SDF designation, that hospital qualifies. Not a large chain. Not a national platform. A mid-size regional network doing ordinary clinical operations.

That designation carries additional obligations that most hospitals have not begun to prepare for. The sections below break down exactly where compliance gaps exist and what fixing them actually requires.

The Consent Problem Hiding in Every Admission Form

Walk into any private hospital in India. You will be handed a two-page admission form. Somewhere in the fine print, you are consenting to diagnosis and treatment, insurance claim submission, data sharing with affiliated labs, and sometimes medical research. You sign it because refusing means you don't get admitted.

That form fails every test Section 6(1) sets.

Section 6(1) requires consent to be free, specific, informed, unconditional, and unambiguous. A bundled admission form is none of these. Refusal blocks access to care. It is non-specific; multiple purposes are collapsed into a single signature. It is uninformed; no notice was provided in a language the patient understands. And it is conditional; the service is tied to the consent.

Section 5(1) makes it worse. Notice must precede consent. Not accompany it. Not follow it in discharge paperwork. Before. Handing a patient a consent form at the admission desk, while they are in pain or accompanying an emergency case, is not prior notice. It is an administrative cover.

Section 6(4) is the provision almost no hospital is operationalizing: withdrawing consent must be as easy as giving it. If consent was given at a registration desk, withdrawal must be possible at the same desk or through an equivalent digital channel. There is no hospital management system in routine use today that has a "withdraw consent" button for a specific data purpose.

The telemedicine context is arguably worse. A platform that bundles location data collection, health history access, and contact-list sharing under a single "I Agree" checkbox at signup has created a Section 6 violation in its onboarding flow. That checkbox is not specific. It is not purpose-segregated. And there is no withdrawal mechanism short of deleting the account.

A compliant consent flow for a hospital looks like this: separate notices for clinical care, insurance submission, research participation, and third-party lab sharing. Each notice in the patient's preferred language; DPDPA mandates accessibility, and each consent is independently revocable. Each revocation is logged with a timestamp in an auditable record.

No paper form achieves this. No generic EHR checkbox achieves this. It requires purpose-level consent architecture.

Significant Data Fiduciaries: Who Qualifies and What the Extra Obligations Look Like

Section 10(1) lists four classification triggers for SDF designation: volume of personal data processed, sensitivity of that data, risk to data principals, and potential impact on national security or public order. Health data scores high on at least three of these by default.

Large private hospital networks processing millions of patient records annually across multiple states are SDF candidates. National telemedicine infrastructure like eSanjeevani, which handled crores of consultations during and after the pandemic, qualifies on volume alone. Health aggregators that consolidate diagnostic reports, prescription histories, and doctor interactions across their user base are SDF candidates on both volume and sensitivity.

The obligations under Section 10(2) go beyond standard DPDPA compliance. SDF-designated entities must conduct periodic Data Protection Impact Assessments. They must appoint a Data Protection Officer, and that DPO must report directly to the board, not to the CTO or the legal function.

That last requirement is the gap that will catch the most organisations off guard. At most Indian hospital groups today, whoever holds the data privacy title sits inside IT or legal. Section 10(2) requires board-level accountability. The DPO must have direct access to the board and independence from the business units whose practices they are auditing. That is a structural change, not a job description update.

SDF obligations also extend to algorithmic transparency. Hospital networks and HealthTechs deploying AI-driven diagnostic tools like imaging analysis, sepsis prediction, and readmission risk scoring must be able to explain how those systems process personal data.

ABDM Interoperability vs. DPDPA Consent

The Ayushman Bharat Digital Mission was designed to make health records portable. A patient's discharge summary from a hospital in Pune should be accessible to a specialist in Chennai. FHIR-standard data exchange, linked via ABHA IDs, is the mechanism.

ABDM has its own consent framework. Health Information Providers (HIPs) and Health Information Users (HIUs) operate under a consent artifact model. Patients grant access, access expires, and requests are logged. It is technically sophisticated, but it is not DPDPA-compliant on its own.

Section 6(1) requires consent that is purpose-specific and free. An ABDM consent artifact grants access to a health record for a defined period. But it does not necessarily specify what the HIU will do with that data; whether it feeds an insurance underwriting model, a pharma research database, or a clinical second opinion. Those are different purposes. DPDPA treats them as requiring separate consent.

Section 7 lists processing that is permitted without consent: medical emergencies, disease surveillance under public health law, and functions performed under a statute. Routine record sharing between a diagnostic lab, an attending specialist, and an insurance HIU does not fall under Section 7. It requires valid Section 6 consent.

The concrete gap: a DPDPA-linked PHR app that auto-shares records with an insurance HIU upon policy purchase, without presenting a fresh, purpose-specific consent notice, is operating in a legal grey zone. The ABDM consent artifact authorised data access. DPDPA requires consent tied to a specific processing purpose. These are not equivalent.

The fix is not to tear down ABDM interoperability. It is to map each ABDM data-sharing event to a DPDPA purpose and to ensure the consent artifact captures that purpose in terms the data principal understands.

Children's Health Data: Section 9 Has Zero Tolerance

Section 9(1) is unambiguous: processing a child's personal data requires verifiable parental or guardian consent before any processing begins. Section 9(3) prohibits behavioral tracking and targeted advertising on children's personal data. No exceptions for health contexts.

The scope here is broad. Pediatric hospital chains. School health programs that track vaccination records, BMI, and vision test results. Children's diagnostic platforms. Mental health apps serving adolescents. Every one of these is processing a child's personal data.

The technical gap is significant. Most EHR systems and hospital management platforms in India have no mechanism to flag a data subject as under 18 at registration and automatically route consent collection to a parent or guardian. The field exists, date of birth is captured, but the consent workflow does not branch on it. A pediatric patient is processed identically to an adult patient from a consent architecture perspective.

The Erasure Paradox: Patient Rights vs. Retention Mandates

Section 12(3) gives data principals the right to erasure of their personal data once the purpose for which it was collected has ended.

The Clinical Establishments (Registration and Regulation) Act mandates medical record retention for a minimum period. The Consumer Protection Act creates liability timelines that require hospitals to retain treatment records. These obligations do not disappear because a patient submits an erasure request.

This is a genuine legal conflict, and the wrong response is to ignore either side.

A hospital that auto-deletes records upon erasure request exposes itself to clinical liability and regulatory non-compliance. A hospital that silently rejects erasure requests without explanation violates Section 12. The correct response is documented, auditable, and time-bound: acknowledge the request, cite the specific statutory retention obligation, specify the date on which erasure will occur, and log the entire exchange.

Section 8(7) supports this approach. It requires data to be deleted once the retention purpose ends, not stored indefinitely as a default. A hospital that retains records beyond the statutory period, without a documented legal basis, violates Section 8(7), whether or not an erasure request was ever submitted.

Section 12 also creates a right to correction. A patient who disagrees with a recorded diagnosis can request that it be corrected. This is clinically complex. A DPO cannot override a physician's clinical judgment. Hospitals need a documented adjudication process; one that distinguishes factual data errors (wrong date of birth, wrong medication listed) from clinical disagreements, and handles each appropriately with a clear audit trail.

Third-Party Data Sharing: Where Most Breaches Actually Happen

The hospital is not the only entity with your patient data. Labs, insurance TPAs, pharmacy chains, pharma research partners, and diagnostic aggregators all receive patient data downstream. Section 8(2) makes the originating data fiduciary responsible for ensuring that every processor and sub-processor it engages complies with DPDPA.

A Business Associate Agreement does not satisfy Section 8(2). Contractual language that says "the vendor will comply with applicable law" does not constitute compliance verification. Section 8(2) requires the fiduciary to actively ensure compliance through audit rights, contractual purpose limitations, and retention controls.

IRDAI's health insurance data sharing framework requires insurers to protect policyholder data. But the hospital or HealthTech sharing discharge summaries with an insurance TPA is equally accountable as the originating fiduciary. The fact that the data left the hospital's servers does not transfer the compliance obligation.

A hospital sending bulk discharge summaries to an insurance TPA via unencrypted email is a Section 8(6) violation of data security. If specific consent for that insurance sharing was not obtained at admission, it is also a Section 6 violation. Both can be true simultaneously. Both will be enforceable once the Data Protection Board begins operating.

Data-sharing agreements with downstream parties need purpose clauses that match the consent obtained, retention limits that align with the data's original purpose, and breach notification timelines. 

FAQ

Q: Does DPDPA explicitly classify health data as sensitive personal data the way GDPR does?

No. The DPDPA does not publish a static sensitive-categories list equivalent to GDPR Article 9. Instead, Section 10(1) uses the sensitivity of personal data as one of the criteria for SDF designation. Health data meets that criterion. The government will operationalize this through rules and threshold notifications, but organisations processing health data should not wait for a formal list before treating it as high-risk.

Q: Is a standard hospital admission consent form legally valid under Section 6?

No. A standard bundled admission form fails Section 6(1) on multiple grounds: it is not purpose-specific, it is not free (refusal blocks access to care), and it is not preceded by a compliant Section 5(1) notice. It also fails Section 6(4) because there is no mechanism for purpose-level withdrawal. Hospitals need to replace bundled forms with purpose-segregated, digitally-managed consent flows.

Q: How does DPDPA consent apply to ABDM-linked PHR applications, and do they need separate consent artifacts?

ABDM consent artifacts and DPDPA Section 6 consent are not the same instrument. ABDM consent governs record access by HIPs and HIUs. DPDPA consent must be tied to specific processing purposes, underwriting, research, and specialist referral. PHR apps sharing records with insurance HIUs need a DPDPA-compliant consent notice that specifies the processing purpose, in addition to the ABDM consent artifact. Current implementations generally do not map these two frameworks together.

Q: Can a hospital refuse a patient's erasure request on grounds of medical record retention law?

A hospital cannot ignore an erasure request. It also cannot delete records that are subject to a statutory retention obligation. The correct response is to acknowledge the request in writing, cite the specific retention statute and duration, commit to a deletion date once the retention period expires, and log the entire exchange in an auditable trail. Section 8(7) requires deletion once the retention purpose ends, so the process must include a mechanism to trigger deletion at that date.

Q: At what data volume or patient count will a hospital be designated a Significant Data Fiduciary?

The Central Government has not yet notified the specific thresholds for SDF designation. Section 10(1) identifies volume, sensitivity, risk to data principals, and national security implications as the classification criteria. Once thresholds are notified, hospitals processing health data at significant volume, a mid-size chain handling tens of thousands of patient records monthly, is a reasonable working assumption and will qualify. Preparing for SDF obligations now is the correct posture.

Run CoTrust's consent gap audit on your patient data flows and get a section-by-section DPDPA compliance report in 48 hours.

This content is for informational purposes and does not constitute legal advice. Consult qualified legal professionals for advice specific to your circumstances.