Health records sit in a category of their own. A leaked shopping history is an inconvenience; a leaked diagnosis or psychiatric history can end a marriage, a job, or a career. Hospitals, diagnostic chains, HealthTech platforms, and Electronic Health Record (EHR) vendors operating in India now sit inside the Digital Personal Data Protection Act, 2023 (DPDP Act), and healthcare has a pattern of harm unlike a typical SaaS company: the costliest breaches are rarely outside attackers, they are staff or contractors looking at records they had no clinical reason to open.
A hospital network processes identifiers, diagnoses, prescriptions, billing, insurance, and increasingly biometric data, often spread across a dozen systems and third-party vendors. Getting the basics right -who is the Data Fiduciary, how consent works for the very young and the unconscious, who can see a record, and how long you must keep it -is what separates a defensible programme from a Data Protection Board complaint waiting to happen. For the wider compliance sequence, see our 90-day roadmap.
1. Who Is the Fiduciary -Hospital or Vendor?
The DPDP Act draws a hard line between the Data Fiduciary and the Data Processor, and healthcare is one of the sectors where the line gets misread most often. The Fiduciary is whoever determines the purpose and means of processing -not whoever holds the contract, and not whoever wrote the software.
In the common arrangement, the hospital is the Data Fiduciary: it decides why a record is created, who can access it for treatment, and how long it is kept clinically. The EHR or hospital-management-software vendor that stores and processes those records on the hospital's instructions is typically the Data Processor -it has no independent right to use the data for its own purposes.
Calling a vendor a "processor" in an agreement does not make it one if that vendor actually decides why patient data gets processed -for example, if it sells de-identified data for analytics on its own account. Map the actual data flow, not the contract's vocabulary.
A telemedicine platform wears two hats
Consider a HealthTech company that licenses its consultation software to hospitals and also runs its own consumer app where patients book doctors directly. For the hospital-licensed deployment, it is usually a Data Processor. For its own app, where it directly onboards patients and decides what data to capture, it is the Data Fiduciary for that relationship.
The same company can be a Processor in one flow and a Fiduciary in another. Map each product line separately -do not assume one designation covers the whole business.
2. Why Health Data Needs Extra Care
Unlike GDPR, the DPDP Act does not formally carve out a special category of "sensitive personal data" with its own heightened statutory conditions. Health data is protected the same way as any other personal data -through the general obligations of lawful processing, notice, consent or another legitimate basis, and reasonable security safeguards under Section 8.
That absence of a named category is not a shortcut. The consequence of a health-data breach is disproportionate to almost any other kind of leak: it can affect employability, insurance, family relationships, and physical safety, and the sector already carries its own confidentiality expectations through clinical ethics and professional-conduct regulations that predate DPDP. A hospital that reasons "DPDP does not single out health data, so our baseline security is enough" is reading the absence of a special category as permission -it is not.
Build your safeguards as if every patient record carried the highest protection tier available, regardless of how the Act formally classifies it. Encryption at rest and in transit, strict access controls, and vendor due diligence are the same Section 8 obligations that apply to every fiduciary -health data simply has the least room for error.
3. Consent, Guardians & Emergencies
Healthcare consent under DPDP splits into three distinct scenarios, and conflating them is where most hospital privacy notices go wrong.
Ordinary patient consent follows the standard rules under the DPDP consent framework -clear notice in an understandable form, a genuine opt-in, and the ability to withdraw as easily as it was given. For a minor patient, Section 9 requires verifiable consent from a parent or lawful guardian before processing the child's personal data, and prohibits behavioural tracking or targeted advertising directed at children -see our dedicated piece on DPDP and children's data for the mechanics of a verifiable guardian-consent flow. Paediatric registration, school-health programmes, and vaccination platforms all need this built in from day one, with a clear process for the point at which the patient turns eighteen and consent shifts to them directly.
The third scenario is the emergency. Section 7 recognises legitimate uses that do not require consent at the point of processing, including action necessary to respond to a medical emergency involving a threat to life or immediate health, and processing necessary for providing medical treatment during an epidemic or other threat to public health. This is what lets an ER team treat an unconscious patient without pausing for a consent form. It is scoped tightly to the emergency itself -once the patient is stabilised, the ordinary consent and notice obligations resume for anything beyond immediate treatment, such as sharing data for research or marketing.
| Scenario | Legal Basis | What To Build |
|---|---|---|
| Routine OPD visit | Consent | Clear notice at registration, opt-in capture, easy withdrawal |
| Minor patient | Guardian consent (Section 9) | Verifiable parental consent flow, age-transition handling at 18 |
| Unconscious ER patient | Legitimate use (Section 7) | Proceed with treatment; backfill notice once stabilised |
| Secondary research or analytics reuse | Fresh consent | Cannot reuse treatment consent -capture a new, specific consent |
4. Access Control & Insider Risk
The single most common health-data incident is not a hacker breaching a firewall -it is a member of staff opening a record they had no clinical reason to view. Curiosity about a colleague, a relative, a celebrity patient, or a neighbour is a recurring pattern across hospital systems everywhere records are broadly accessible, and it is entirely preventable with access design rather than trust.
Least-privilege access means role-based permissions tied to an actual, current clinical assignment -a nurse sees patients on her ward during her shift, not the entire hospital's patient list. Access should expire automatically when a patient is discharged or transferred out of a department, and every record view should be logged with the viewer's identity, timestamp, and where possible a reason code. A "break glass" mechanism for genuine emergency access is reasonable, but every break-glass event should trigger a mandatory post-hoc review, not a shrug.
A confirmed instance of a staff member browsing records outside their duties is a personal data breach in its own right. It triggers your obligation to assess and, where required, notify the Data Protection Board and affected patients within the timelines set under the DPDP Rules -see our guide on DPDP breach notification. Audit logs that can tell you within minutes, not weeks, exactly which records were touched and by whom are not a nice-to-have here.
The audit review that actually catches insiders
Generic quarterly access reviews rarely catch insider misuse -they check whether permissions match job roles, not whether those permissions were abused. A more effective pattern layers three specific checks on top of standard access review:
- Self-access flags -any staff member viewing their own record, or a record sharing their surname or address
- VIP-access flags -any view of a record tagged as high-profile or high-sensitivity, cross-checked against the viewer's active care assignment
- Off-hours and volume anomalies -bulk record access or access well outside a staff member's rostered shift
5. Retention vs the Right to Erase
Erasure is one of the eight rights DPDP gives every data principal, and patients will ask for it -after a course of treatment ends, after a second opinion elsewhere, or simply because they are uncomfortable with a hospital holding their history indefinitely. Healthcare is also one of the sectors where that request most often collides with a separate legal duty to retain the same record.
A validly raised erasure request does not override a retention period imposed by another law. Hospitals typically operate under medical-record-keeping obligations that sit outside DPDP entirely -for example, professional-conduct regulations from the Medical Council of India that require indoor-patient records to be kept for a defined minimum period, with medico-legal cases frequently retained longer given the possibility of future litigation. Where a statutory retention duty applies, it controls; DPDP is not a mechanism to force early deletion of a record another law requires you to keep.
The practical answer is a retention schedule built per record type -outpatient notes, inpatient charts, surgical records, medico-legal cases, billing and insurance documentation -each mapped to its own minimum retention period under the relevant sectoral rule. Apply erasure requests only once the mandated window has lapsed, or for categories of data that were never subject to a statutory hold in the first place. Keep records that are past their active clinical use but still inside the retention window in a separate, more tightly access-controlled archive rather than leaving them in the live system indefinitely -see our piece on handling erasure and deletion requests for the broader mechanics.
6. DPDP Meets ABDM & Sectoral Rules
DPDP is the horizontal law that applies to every sector, but healthcare in India already carries its own layer of sector-specific frameworks that a compliance programme cannot ignore. The Ayushman Bharat Digital Mission (ABDM) issues Health IDs, maintains a Health Facility Registry and Health Professional Registry, and runs a consent-manager architecture designed specifically for sharing health records between providers. Telemedicine practice guidelines issued jointly by the medical regulator and the health ministry separately govern how remote consultations must be conducted and documented.
None of this replaces DPDP -it sits alongside it. A HealthTech platform integrated with ABDM needs its DPDP consent mechanism and its ABDM consent-manager flow to interoperate rather than contradict each other, and where a sectoral rule imposes a stricter requirement than DPDP alone would -a specific documentation duty under telemedicine guidelines, for instance -the toughest applicable rule controls. Treat DPDP as the floor, not the ceiling, and map every sectoral overlay against it before assuming a single compliance checklist covers the whole picture.
7. Compliance Checklist
A working DPDP programme for a hospital or HealthTech platform comes down to a short list of concrete build items, not a policy document that sits unread in a shared drive.
| Area | Action |
|---|---|
| Roles | Determine Fiduciary vs Processor status separately for every product line and data flow |
| Notice | Publish a patient-facing DPDP notice in plain, understandable language at every point of collection |
| Guardian consent | Build a verifiable parental-consent flow for paediatric registration, with an age-transition process at 18 |
| Emergency processing | Document the Section 7 legitimate-use basis relied on for emergency treatment, and when ordinary consent resumes |
| Access control | Implement role-based access, automatic expiry, audit logging, and reviewed break-glass emergency access |
| Retention | Map statutory retention periods per record type before applying any erasure request |
| Sectoral overlay | Reconcile ABDM consent-manager flows and telemedicine guidelines against your DPDP programme |
| SDF readiness | Assess likely Significant Data Fiduciary exposure and prepare to appoint a DPO if designated |
| Vendors | Run a DPA review with every EHR, billing, and HealthTech vendor touching patient data |
Patient data is unforgiving of shortcuts. It carries penalties up to ₹250 crore paid to the Consolidated Fund of India rather than to the patient directly -which means the real cost of getting this wrong is never the fine alone, it is the trust a hospital or HealthTech platform loses the moment patients learn their records were not handled with care. Get the Fiduciary-Processor mapping right, build consent flows that actually account for guardians and emergencies, close off insider access with real controls, respect retention law rather than fighting it, and reconcile DPDP with the sectoral rules layered on top. That is what handling patient data the right way looks like in practice.
Need a DPDP programme built for a hospital or HealthTech platform?
SecComply maps your Fiduciary and Processor roles across every product line, builds guardian-consent and emergency-processing flows, hardens access controls against insider risk, and reconciles your retention schedule with medical-record law and ABDM.
Book a healthcare DPDP review →FAQ
Not explicitly. Unlike GDPR, the DPDP Act does not carve out a formal special category of sensitive personal data with extra statutory conditions. But the general obligation to implement reasonable security safeguards under Section 8 applies with the same force to every record, and the consequences of a health-data leak -reputational, medical, and personal -are severe enough that hospitals and HealthTech platforms should treat every patient record as if it carried the highest protection tier, regardless of what the Act formally requires.
It depends on who decides why and how the data is processed, not on what a contract calls either party. A hospital treating a patient is almost always the Data Fiduciary for that clinical relationship. An EHR or hospital-management software vendor that stores and processes records purely on the hospital's instructions is typically the Data Processor. But a HealthTech platform that runs its own consumer-facing app -a telemedicine service or diagnostics app that onboards patients directly -is the Data Fiduciary for that separate patient relationship, even while acting as a Processor for hospital clients elsewhere.
Yes, within limits. Section 7 of the DPDP Act recognises legitimate uses that do not require consent, including processing necessary to respond to a medical emergency involving a threat to the life or immediate health of the data principal or another individual, and processing necessary for providing medical treatment during an epidemic, outbreak of disease, or other threat to public health. This covers an unconscious patient arriving in the ER, but it is scoped to the emergency itself -once the patient is stabilised, ordinary consent and notice obligations resume for any further processing.
A validly raised erasure request does not override a retention period mandated by another law. Hospitals are typically bound by separate medical-record-keeping rules -for example, Medical Council of India professional-conduct regulations that require indoor-patient records to be retained for a defined period, with medico-legal cases often held longer given potential litigation. Build a retention schedule per record type, honour the statutory minimum first, and apply erasure only once that mandated window has lapsed or for data that falls outside it.
Possibly. Section 10 lets the Central Government designate Significant Data Fiduciaries based on factors including the volume and sensitivity of personal data processed, risk to data principals, and impact on sovereignty and public order. Large hospital networks and HealthTech platforms processing sensitive health data at scale are plausible candidates, but the designation itself comes through official notification, not self-assessment -track the Board's guidance and prepare as though the obligations, including appointing a DPO, could apply to you.