DPDP Compliance for Healthtech and Telemedicine Platforms
Health data does not get a separate legal tier under the DPDP Act, but the consequences of getting it wrong are higher — here is what that means in practice.
No special tier, but the same rules bite harder
The DPDP Act does not carve out a distinct “sensitive personal data” category the way some earlier drafts and other jurisdictions do; health data is personal data like any other, governed by the same consent and legitimate-use framework. That said, the practical stakes of a lapse — a leaked diagnosis, a mishandled prescription history — mean the general obligations in Section 8, especially reasonable security safeguards and breach intimation, deserve a higher bar in implementation even without a separate statutory label.
Consultation booking, symptom intake forms, and video-call consultations each generate their own data set, and each needs the itemised notice under Section 5 to say plainly what is recorded, whether the consultation is stored or transcribed, and who besides the treating doctor can see it.
Medical emergencies invoke a specific legitimate use
Section 7 recognises processing necessary to respond to a medical emergency as a legitimate use that does not require consent in the moment — an unconscious patient's records can be pulled without pausing for a consent flow. That ground is narrow and situational, though, and does not extend to routine care, follow-up marketing, or wellness nudges once the emergency has passed.
Outside emergencies, a telemedicine platform needs ordinary consent for booking, consultation, and any sharing with diagnostic labs or pharmacies, and that consent should be specific enough that a patient can agree to the consultation without also being opted into promotional health content.
Prescription and lab data move through several hands
A single prescription might travel from the doctor's e-prescription system to a partner pharmacy for fulfilment and to a lab-aggregator for diagnostic tests, each a separate processor relationship that needs its own Section 8(2) contract. Patients should be told, at the point of booking, which pharmacy or lab partners will receive their prescription, not discover it only when a delivery arrives.
Electronic health records retained for continuity of care sit in tension with the erasure duty under Section 8(7): a platform needs a documented retention schedule that reflects genuine clinical need — repeat consultations, chronic condition tracking — rather than open-ended storage justified only by convenience.
Breach response for health data needs a faster clock
A breach involving diagnosis or treatment history is exactly the scenario Section 8(6) is built for: intimation to the Data Protection Board and to affected patients, on a timeline the Rules tighten with an initial fast notice followed by a more detailed report. Because a leaked health record cannot be walked back the way a leaked address can, the incident-response runbook for a healthtech platform should assume health-data breaches are treated as the most urgent category by default.
Vendor breaches — a lab partner or a cloud host suffering an incident — flow back to the platform's own notification duty, so contracts with every clinical-data processor should require immediate upstream notice, not notice on the vendor's own convenient schedule.
Where to go next
Build out a Breach Response Planner specifically for clinical data before an incident happens, since the response window for health records is unforgiving. Pair it with a Data Flow Mapper exercise tracing every consultation from intake through pharmacy and lab handoffs.