Kōami
Back to Resources
Data Security7 min read

The DPDP Act Reaches the Hospital Floor

K

Kōami

Editorial team

Share this article
The DPDP Act Reaches the Hospital Floor — Data Security | Kōami

The registration counter asks for a phone number, an address and, quite often, an Aadhaar number. The number goes into the system, and from there into the SMS gateway that sends appointment reminders, into the spreadsheet the marketing team uses for health-camp follow-ups, into the WhatsApp group where the ward coordinates discharges, and into a backup on a drive in the IT room. Nobody decided this. It accreted, one reasonable step at a time, over a decade.

India's Digital Personal Data Protection Act, 2023 turns that accretion into a question a hospital has to answer: on what basis do you hold this, and who told the patient?

What changes, in plain terms

The Act is short by the standards of privacy law, and its core is a small number of ideas.

  • A hospital that decides why and how personal data is processed is a data fiduciary. The patient is a data principal.
  • Processing generally requires consent, and the consent has to be preceded by a clear notice in plain language saying what data, for what purpose.
  • Purpose limitation. Data collected for one purpose is not automatically available for another. The phone number given for appointment reminders is not, by default, a marketing list.
  • Data minimisation. Collect what the purpose needs, not what the form has always asked for.
  • Patient rights: to access, to correct, to erasure, and to nominate someone to exercise those rights on their behalf.
  • Breach notification, to the regulator and to affected individuals.
  • Processors, meaning the vendors who handle data on the hospital's behalf, are bound by contract, and the obligation does not transfer away from the hospital.
  • Penalties are significant enough that this is a board-level matter rather than an IT one.

Exact timelines, thresholds and the finer points of the Rules move, and you should work from the current notified text and qualified advice rather than a summary. What is not going to change is the shape: a hospital must know what it holds, why, and be able to act on a patient's request about it.

The inventory nobody has

The first exercise is unglamorous and always revealing: write down every place patient data sits. Not the systems on the architecture diagram — every place.

  • The HIS or HMS database, and its backups, and where those backups physically are.
  • The PACS archive, which is larger than everything else combined and often has the loosest access control.
  • The lab analyser interface, which frequently keeps its own local copy.
  • Spreadsheets on individual machines: camp registrations, corporate check-up lists, TPA follow-ups, the pending-discharge tracker.
  • The SMS and WhatsApp gateways, which are third parties holding a patient's name, number and often their appointment details.
  • Scanned consent forms and discharge summaries on a shared drive.
  • CCTV, biometric attendance, and the visitor register at the gate.
  • Whatever the analytics or marketing agency was given for the last campaign.

Every hospital that does this exercise finds at least two copies it had forgotten and one vendor relationship with no contract governing data. Those are the findings. The exercise is worth doing purely for them.

Consent notices, and the trap of consenting to everything

The instinct is to add a paragraph to the registration form covering every conceivable use, and have everyone sign it. This is the approach the law is specifically designed to defeat, and it fails at the point that matters, which is when a patient objects and the hospital has to show that the consent was informed and specific.

The workable version separates the purposes.

Care delivery is the core purpose, and the notice for it can be short and clear. Statutory and regulatory reporting is a separate basis and should be described as such rather than bundled into consent. Insurance and TPA processing involves disclosure to third parties and needs to say so. Appointment reminders and clinical follow-up are operational. Marketing, health camps, newsletters and feedback surveys are a genuinely separate purpose, and the patient should be able to decline them without declining treatment.

That last point is the one that changes behaviour inside a hospital. Once marketing consent is separate and recorded, the marketing list stops being "everyone who ever registered" and becomes a subset. This is inconvenient and it is the entire point.

If declining a purpose would stop the patient receiving care, it is not a consent. It is a condition of entry, and it will not stand.

Access control is where policy becomes real

A privacy policy has no effect on who can actually open a record. That is decided by role configuration, and in most hospitals the roles have drifted a long way from the org chart.

The pattern is familiar. A single Doctor role that can see every patient in the hospital, because it was easier to configure. Front-office staff with access to clinical notes they have no use for. Shared logins at the counter during busy hours. Vendor support accounts, created for a go-live two years ago, still active and still privileged. Ex-employees whose accounts were never disabled because offboarding runs through HR and never reaches the HIS.

Least privilege is the principle, and the practical version is narrower than most hospitals implement: access follows the care relationship, so a clinician sees the patients they are treating; sensitive categories such as psychiatry, HIV status and fertility records sit in their own compartments with explicit grants; every access to a record is logged with enough detail to answer who looked and when; and break-glass access exists for emergencies, is generously granted, and is reviewed afterwards without exception.

The audit log deserves particular attention, because it is what converts a policy into something provable. A log that records only writes cannot answer the most common privacy complaint, which is that somebody read a record they had no business reading.

Rights requests need an owner and a route

A patient writes in asking what data the hospital holds about them, or asks for a correction, or asks for erasure. The Act gives them that right and expects a response.

Most hospitals have no route for this at all. The letter arrives at the front desk, is passed to medical records, then to IT, and stalls because nobody can assemble the answer across nine systems and a shared drive.

Deciding this in advance is inexpensive. Name the person who owns rights requests. Define the intake channel and publish it. Write down which systems have to be queried, which is precisely the inventory from earlier. Agree what erasure means in a clinical context, where retention obligations for medical records constrain what can actually be deleted, and be able to explain that constraint to the patient rather than simply refusing.

Breaches, and the twenty-four hours that matter

Breach handling is where preparation shows most starkly, because it happens under time pressure and in public.

Have a definition of what constitutes a reportable breach and who decides. Have the contact points ready, both regulatory and internal. Know in advance what your logs can actually tell you about scope, because the first question is always how many records, and a hospital that cannot answer it will guess badly. Rehearse it once. A tabletop exercise on a Thursday afternoon costs three hours and finds most of the gaps.

Note that CERT-In's incident reporting directions already impose their own tight timelines for cyber incidents, separately from the DPDP obligations. Hospitals need one process that satisfies both, not two competing ones discovered mid-incident.

A first ninety days that is actually achievable

  • Build the data inventory, including spreadsheets and messaging apps. Nothing else works without it.
  • Separate the consent purposes on the registration form, especially marketing.
  • Review roles in the HIS and PACS, and disable dormant and vendor accounts.
  • Confirm that read access is logged, not just writes.
  • Get data processing terms in writing with the SMS gateway, the cloud provider, the billing vendor and the analytics agency.
  • Name the person who owns rights requests, and publish the route.
  • Run one breach tabletop.

None of this is exotic. It is mostly hygiene that a hospital would want in place regardless. What the Act adds is a deadline and a consequence — and, usefully, a reason for the conversation about that spreadsheet on the marketing laptop to finally happen.

Found this useful? Pass it on to someone on your team.

Share this article