7 DPDPA Guidelines for Healthcare & Hospitals in India (2026)

A patient walks into a hospital, registers at the front desk, sees a doctor, gets a lab test, picks up medicine at the pharmacy, and pays through an insurance desk. By the time that visit is over, their phone number, diagnosis, and payment details exist in five or six different systems — registration software, the EMR, the lab portal, the pharmacy system, the insurer's API, and probably a WhatsApp or SMS reminder tool.

Under the Digital Personal Data Protection Act (DPDPA), 2023, that patient has the right to ask what data is held, correct it, or withdraw consent. Most hospitals cannot answer that question today — not because they don't care, but because no one traced the data flow before writing the privacy policy.

This matters right now because the compliance timeline is no longer theoretical. Section 2 and the Data Protection Board provisions are already active. Consent Manager provisions come into force on November 13, 2026, and the Act's core operational duties — notice, consent, safeguards, breach reporting — apply from May 13, 2027. Hospitals that start mapping now will not be scrambling in the final quarter before enforcement.

This guide breaks down 7 practical DPDPA guidelines for hospitals and healthtech companies — written as operational steps, not legal summaries. Each one ends with the evidence a regulator or auditor would actually ask to see.

• Map one patient journey end-to-end before writing another policy
• Replace blanket admission-form consent with purpose-specific notices
• Make consent withdrawal propagate to every connected system, not just the intake screen
• Separate genuine medical emergencies from routine secondary use of patient data
• Put access control, vendor contracts, and breach response around every patient record
• Run one unified queue for patient rights requests and children's data verification
• Treat every policy as a testable evidence trail, not a document that sits in a folder

Under the Act, a hospital is almost always the Data Fiduciary — the entity that decides why and how patient data is processed. Diagnostic labs, billing software vendors, cloud hosting providers, and SaaS tools used for appointments or teleconsultation are typically Data Processors, acting on the hospital's instructions.

That distinction matters because the hospital carries the compliance and penalty exposure even when a vendor's system is the one that leaks or mishandles the data. A processor agreement does not transfer legal accountability — it only assigns operational responsibility.

One point trips up almost every hospital compliance team: a DPDPA erasure or correction request does not override retention duties imposed by other laws. The Clinical Establishments Act, insurance regulations, and medical record retention rules can require hospitals to keep records for a fixed number of years even after a patient asks for deletion. The correct response is to document the retention basis, not to either delete everything or ignore the request.

Most data maps stop at the electronic medical record. That misses where the actual compliance risk lives: registration kiosks, insurance verification, pharmacy dispensing, home-care and telemedicine add-ons, and the cloud vendors quietly sitting behind all of it.

• Trace data through appointment booking, registration, and identity verification
• Include clinical and diagnostic systems — EMR, lab information systems, radiology PACS
• Cover billing, insurance, and TPA (third-party administrator) data exchanges
• Extend the map to pharmacy, telemedicine, and home-care service providers
• List every cloud vendor and support tool that touches patient data, even briefly

For each system, record the purpose of processing, the system owner, who else receives the data, retention rules, and the trigger that should delete or archive it. New tools should not go live until they are added to this map — shadow SaaS is where most hospital data leaks originate.

Evidence to keep: a live data map, linked to a processing register, updated whenever a new vendor or system is introduced.

The single-signature admission form — one consent line covering treatment, insurance sharing, research use, and marketing communication — does not meet the DPDP Act's standard. Sections 5 and 6, along with Rule 3, require consent to be free, specific, informed, unconditional, and unambiguous, and notice must be able to stand on its own outside a bundled form.

• Build separate consent captures for treatment, insurance sharing, research participation, and promotional communication
• Store the notice version, purpose tag, timestamp, and channel for every consent event
• Make each notice independently understandable — a patient should know what they're agreeing to without reading the whole form
• Give every notice a visible, equally easy withdrawal path

This is the single highest-leverage fix on this list. A hospital that separates these four purposes today avoids the much harder retrofit of untangling one blanket consent record after the fact.

A patient withdraws consent for promotional messages. The intake system updates. But the CRM keeps sending appointment-reminder SMS with promotional content baked in, the call centre still has the patient on a follow-up list, and an outsourced marketing vendor never received the instruction at all.

Sections 6(4) and 6(5) require withdrawal to be as easy as giving consent, and require the hospital and its processors to stop the related processing within a reasonable time, unless another lawful basis applies.

Evidence to keep: proof of who sent the stop instruction, which systems acknowledged it, and where data legitimately persisted because of a retention law — not because no one followed up.

Section 7 lets hospitals process personal data without consent to protect life or health during a medical emergency, or during a public health event such as an outbreak. This is a narrow, specific exception — not a general label that can be stretched to cover discharge-data marketing or unrelated research recruitment.

• Create a dedicated emergency-access pathway with a reason code, a time limit, and mandatory after-the-fact review
• Log every emergency access with patient ID, staff member, record accessed, and stated rationale
• Route any non-emergency secondary use — marketing, unrelated research, data sales to partners — through the normal consent process, with its own legal basis

Auditors and the Data Protection Board will look specifically for hospitals that used the emergency exception as a blanket justification. Time-boxing and after-the-fact review is what separates a legitimate emergency-access log from a workaround.

Section 8(5) and Rules 6–7 require reasonable security safeguards: access management and logging, backups, processor contracts with incident and deletion clauses, and breach notification — to patients without delay, and to the Data Protection Board with full details within 72 hours.

• Named user accounts with role-based access — no shared logins on shared terminals
• Fast de-provisioning when staff leave or contracts end
• Access logs that tie a specific user, patient record, and action together
• Tested backup restoration for critical clinical data, not just a scheduled backup job
• Processor contracts that explicitly assign incident response and data-deletion duties

These are statutory maximums, not automatic per-incident fines — but they signal how seriously the Act treats a hospital's security baseline. A 72-hour breach clock is unforgiving if the access logs needed to scope the breach don't already exist.

Access requests, correction requests, and erasure requests arrive through reception, email, and patient portals — often into three disconnected inboxes with no shared tracking. Sections 11–14 and Rule 14 require a clear, unified mechanism for patients to submit and track these requests.

Section 9(1) and Rule 10 add a specific obligation for children's data: verifiable parental or guardian consent before processing, with a record linking the child, the parent or guardian, and the verification evidence used.

• Centralise every request — access, correction, erasure, grievance — into one queue with identity verification built in
• Route work to the right team regardless of which channel the request came through
• Document exceptions explicitly — active medical-record retention duties, ongoing disputes — with DPO or legal sign-off
• For paediatric records, store the parent/guardian verification artefact alongside the child's record, not in a separate system

A privacy policy cannot prove that a system actually behaved as written. Every control on this list needs to produce an artefact that someone outside the compliance team could inspect and verify — a log, a timestamp, a signed acknowledgement.

If a control can't produce evidence in that table, it isn't a control yet — it's a policy statement waiting to fail its first audit.

DataDefend is built for exactly the gap this guide describes — the distance between a written policy and evidence a hospital can produce on request. It doesn't replace clinical judgment or legal decisions on retention; it makes the operational side provable.

• Unified Consent Manager: captures purpose-specific consent across reception, apps, and teleconsultation, and pushes withdrawal instructions to every connected system with acknowledgement tracking
• Automated DSAR Management: single intake queue for access, correction, and erasure requests, with identity verification and SLA tracking built in
• Vendor Risk Management: keeps the processor register and data-sharing agreements tied directly to the systems in your data map
• Data Discovery & Mapping: traces patient data across EMR, billing, CRM, and cloud systems automatically instead of relying on a static spreadsheet
• Audit & Reporting: generates the evidence artefacts — logs, timestamps, acknowledgements — that a Data Protection Board inquiry or internal audit would ask for

What it can't do: make clinical emergency determinations or legal retention calls. Those stay with your DPO and legal team — DataDefend's job is to make sure the operational trail behind those decisions is complete and auditable.

Don't start by rewriting the privacy policy. Pick one outpatient journey — registration through billing — and trace that patient's phone number, diagnosis, and lab report through every system it touches. Then test one withdrawal request end-to-end. If it stalls anywhere past the consent screen, that's the workflow to fix first.

The hospitals that will be ready when enforcement begins in 2027 are the ones treating DPDPA as an operational build now, not a document to finalise later.

DataDefend offers a free account with 3,000 consent collections per month, no credit card required — the fastest way to see what a fully traceable patient consent flow looks like before you commit to a platform.