What the DPDP Act means for hospitals, in practical terms

Not legal advice. This is an operational summary to help you ask better questions. Obligations depend on your establishment and how you process data, and rules are still being operationalised. Take specifics to a lawyer who works on Indian data protection.

India’s Digital Personal Data Protection Act, 2023 is the first comprehensive data protection statute the country has had, and hospitals sit squarely inside its scope. Patient records are personal data, they are held digitally, and hospitals decide what happens to them, which is what makes a hospital a Data Fiduciary under the Act rather than a bystander.

Most of the coverage of the Act is written for technology companies. What follows is the part that changes how a hospital actually runs.

The vocabulary, quickly

• Data Principal, the person the data is about. Your patient.
• Data Fiduciary, whoever decides why and how the data is processed. Your hospital, for patient records.
• Data Processor, whoever processes it on the Fiduciary’s instructions. Typically your HMS vendor.

That last distinction has a consequence people miss: responsibility to the patient stays with the hospital. You cannot contract it away to a software vendor. If your vendor mishandles records, the patient’s relationship is still with you.

Notice and consent, as an operational problem

The Act requires that patients be told, in clear language, what is being collected and why, and that they be able to give and withdraw consent. Two practical implications for a hospital front desk:

• The notice has to be comprehensible, and available in a language the patient can understand. A dense English paragraph on a form that everyone signs without reading is unlikely to be the intent.
• Withdrawal has to be possible, which means somebody at your hospital needs a defined process for handling that request, and it needs to reach the systems actually holding the data.

Worth separating clearly: consent for treatment and consent for things like marketing messages are different, and bundling them is exactly the pattern the Act is aimed at. If you send appointment reminders, that is part of care. If you send promotional offers, that is not, and it needs its own basis.

Retention, and the awkward part

The Act points toward not keeping personal data longer than the purpose requires. Medical records, though, are subject to their own retention expectations under separate medical and clinical-establishment rules, which can require holding records for years.

These two pull in different directions, and the resolution is genuinely establishment-specific. The practical step is to write down, per record type, how long you keep it and on what basis, rather than defaulting to keeping everything forever because deleting feels risky. An undocumented forever-retention policy is the weakest position to be in.

Breach obligations change your incident response

The Act requires notifying the Data Protection Board and affected individuals in the event of a personal data breach. The operational consequence is that you need to be able to answer, quickly, which records were affected and whose they were.

That capability is built long before an incident. If your systems cannot tell you who accessed what and when, you will not be able to scope a breach, and an unscoped breach is one you have to disclose at maximum assumed severity.

Questions worth putting to your software vendor

1. Where is our data stored and processed, physically, and does any of it leave India?
2. Do you use sub-processors, who are they, and what do they receive? Cloud hosting and AI features are the usual answers.
3. If a patient withdraws consent, what is the mechanical process, and how long does it take?
4. Can you produce an access log showing who viewed a specific patient’s record, and over what period is that log retained?
5. On termination, how do we get our data, in what format, and what happens to your copies?
6. Is any of our data used to train models, and can we see that in writing?

That last one deserves particular attention as AI features spread through healthcare software. “We use AI” is not an answer. What leaves your systems, to whom, and whether it is retained or trained on, are three separate questions with three separate answers.

A reasonable starting sequence

1. Inventory what personal data you hold, where it lives, and who can reach it.
2. Write your retention position down, per record type, with its basis.
3. Fix your notice and consent capture at registration, in the right languages.
4. Define the consent-withdrawal and access-request process, and name an owner.
5. Confirm role-based access is real, not five people sharing one login.
6. Get sub-processor and data-location answers from every vendor, in writing.

None of this requires new software to begin. The first two steps are a document, and they are the ones that make every later conversation, with vendors, auditors, or a regulator, substantially easier.

For how we handle this on our side, including our AI sub-processor and what leaves the platform, see our privacy policy.