Guide
DPDP Act for hospitals
There is a great deal written about what the Digital Personal Data Protection Act 2023 requires, almost all of it by lawyers and almost none of it about software. This is the other half: what a hospital's system actually has to be able to do, written by people who built a consent ledger and an audit log rather than by people advising on the Act. It is not legal advice, and it does not substitute for it.
Draft — pending expert review
This page was prepared from the official sources listed below but has not yet been reviewed by a qualified professional. It is general information, not legal or medical advice.
A hospital is the Data Fiduciary — accountable for the patient data it holds. Its software is one of the tools it uses to meet that accountability, and no software makes anyone compliant on its own.
- The hospital is
- The Data Fiduciary — accountable
- Software provides
- Consent records, audit, access control
- Software cannot provide
- Policy, a grievance officer, training
- The usual mistake
- Buying a product and calling it done
The framing
Who is accountable, and for what
Under the Act the hospital is the Data Fiduciary: it decides why and how patient data is processed, and it carries the obligations. A software vendor hosting that data acts as a processor on the hospital's instructions. That distinction matters commercially, because it is the hospital — not the vendor — that answers to a patient or a regulator.
What follows from it is the test worth applying to any system you are shown: not “is this product DPDP compliant”, which is close to meaningless, but “can this product produce the evidence I will be asked for” — what was consented to, by whom, against which version of which notice, who looked at the record, and what changed.
The checklist
What a hospital system has to be able to do
Eight capabilities, with an honest statement of where Trisvio stands on each. Three of them we have not built, and saying so is more useful than a compliance badge:
| Capability | In Trisvio | Detail |
|---|---|---|
| Record consent by purpose, against a versioned notice | Built | An append-only ledger of grant, refuse and withdraw events per purpose, tied to the version of the notice in force when it was given. One signature covering everything cannot show what was actually agreed to. |
| Capture a guardian for a child | Built | Treatment-data consent for a patient under 18 requires a guardian's name and relationship before it can be saved. |
| Never let a consent gap block care | Built, deliberately | A missing consent surfaces as a prompt on the patient record and on the consent screen. It never stops clinical work — a system that withholds treatment over a form is worse than the problem it solves. |
| Show who accessed a record, not only who changed it | Built | The audit log records changes, with before and after values on money-path changes, and the opening of key records such as the patient profile, a visit or a report. |
| Encrypt sensitive identifiers | Partly | Identifiers and second-factor secrets are AES-256-GCM encrypted with per-tenant keys. Names, phones, notes, diagnoses and bills are NOT field-encrypted — that is a real limit, not a detail. |
| Answer a data-subject request | Not built | There is no workflow for access, correction or erasure requests. A hospital receiving one today assembles the answer by hand. |
| Apply a retention schedule | Not built | Nothing expires, ages out or is automatically erased. Retention is a policy the hospital keeps outside the software. |
| Detect and report a breach | Not built | No breach-detection tooling and no notification workflow. The audit log is evidence for an investigation, not an alarm. |
Design
Three decisions worth arguing about
Consent by purpose, not one signature. Treatment, billing, communication and research are different purposes with different answers. A single consent covering all of them cannot demonstrate what a patient actually agreed to, and it is precisely what a withdrawal request will test.
A version on the notice. When the wording changes, consent given against the old wording is not consent to the new. Without a version recorded alongside each event, nobody can later say which notice a patient saw — and the ledger becomes an assertion rather than evidence.
Append-only, always. A consent record that can be edited is worth very little, because the thing being proved is what was true at a moment in the past. A withdrawal is a new event, not an amendment of the grant.
Honesty
Where software stops
The uncomfortable part of this topic for a software vendor is that most of what the Act asks for is not software at all. A hospital still needs a retention policy, a named grievance officer, a breach-response plan, contracts with its processors, and staff who have been trained on what they may and may not look at.
None of that comes in a product, and a vendor implying otherwise is selling you a false sense of completion. What a system can genuinely do is make the evidence available and make the careless mistakes harder — recording consent as it is taken, logging who read what, and limiting access by role so that seeing a record is a permission rather than an assumption.
Treat any “DPDP compliant” badge as a claim to examine rather than a reassurance. Ask instead what the system records, what it can produce on request, and what it explicitly does not do.
Official references
- The Digital Personal Data Protection Act, 2023 and the data-protection framework ↗Ministry of Electronics and Information Technology, Government of India
The Act's rules are being operationalised in phases and obligations continue to be clarified. Take legal advice on your own position rather than relying on any summary, including this one.
Next
Related
Consent and audit as records, not assurances