Skip to content
MedOrbit
Book a demo

Compliance

The DPDP Act 2023 for hospitals: what your software has to do

MedOrbit team · Updated 30 July 2026 · 5 min read

Under the Digital Personal Data Protection Act 2023 your hospital is a Data Fiduciary: you decide why patient data is processed, so the duties land on you rather than on your software vendor. What the software has to do is make those duties routine — record consent as an artifact, answer a data-principal request without an email thread, and produce an audit trail when something goes wrong. This guide covers the duties, the workflows they imply, and the eight questions that tell you whether an HMS can carry them.

What does the DPDP Act change for a hospital?

It changes the default. Patient data is no longer something you hold because you collected it — you hold it for a stated purpose, on a lawful ground such as consent, for as long as that purpose lasts. Consent, retention and erasure stop being policy documents and become features.

Hospitals feel this in three places: registration, where notice and consent are given; sharing, where a record leaves the building; and closure, where data should stop being kept. If your system cannot show what was agreed and when, all three become manual reconstruction.

Is our hospital a Data Fiduciary?

If your hospital decides the purpose and means of processing patient data, yes — you are the Data Fiduciary and the patient is the Data Principal. Your HMS vendor and cloud provider are normally Data Processors acting on your instructions, so the contract with them matters as much as the product.

That split has a hard edge: a vendor cannot absorb your obligation to give notice, act on a rights request or notify a breach. It can only make them fast. Read every compliance page, including our own, as a claim about tooling.

What does a real consent artifact look like?

A consent artifact is a record, not a checkbox: who agreed, to what purpose, on what date, through which channel, and what happened when they withdrew. If you cannot reproduce all five two years later, you have a signature rather than consent.

  • Purpose, in language the patient read — not a link to a policy page.
  • A timestamp, a channel and an identity for whoever gave it.
  • Scope: which categories of data, and which recipients.
  • Withdrawal, carrying the same weight as the grant.
  • An append-only trail, so an auditor sees the sequence, not only today's state.

Verifiable parental consent for a child's data is its own case, and the one hospitals most often get wrong. Paediatrics, immunization and maternity records involve a data principal who cannot consent for themselves, so the guardian relationship must be held as data, not assumed at the desk.

How do we answer a data-principal request?

Treat it as a ticket with a clock, never as an email. A patient can ask what you hold, ask you to correct it, ask you to erase it, and raise a grievance if you do not respond — so the answer needs a queue, an owner and a deadline.

The awkward part is scope. Patient data is not one table: it is registration, consults, prescriptions, results, imaging, bills, claims, call recordings and message logs. Access means all of it. Erasure means deciding what other law obliges you to retain, and a defensible answer names that exception rather than ignoring the request.

What do we do in the first hour after a breach?

Contain, record, notify. The Act requires a Data Fiduciary to inform the Data Protection Board and the affected Data Principals of a personal data breach, so the first hour is about knowing what was touched — a logging question answered long before the incident.

This is where per-user access logs earn their cost. If all you know is that a role could have seen a record, your notice is a guess. If you know which user opened which chart at which minute, the notice is narrow and survivable — the argument for the security architecture behind it.

None of this is legal advice. The statute dates from 2023 and its rules and timelines have been phased in since, so read the current position with your own counsel, not a vendor's summary — the ministry publishes the source material at meity.gov.in.

What should we ask an HMS vendor?

Eight questions cover the ground, and each one has an answer that is either a demo or an excuse. Ask for the demo.

  • Show me one patient's consent record, including a withdrawal.
  • Where does an access request start, and who owns it?
  • What does erasure delete, and what is retained under other law?
  • Can we see per-user access logs for one patient's chart?
  • Which sub-processors touch our data, and in which country?
  • How is data at rest encrypted, and who holds the keys?
  • What is your breach-notification commitment to us, in hours?
  • How is a guardian relationship recorded for a child's data?

Two of those — sub-processors and residency — decide whether you can answer a due-diligence question with a region name instead of a promise. MedOrbit runs in AWS ap-south-1 (Mumbai), with the consent ledger and access-request tooling in the platform.

Questions people ask about this

Does the DPDP Act apply to a small clinic?

The Act governs digital personal data processed in India, with no floor based on facility size. A solo clinic storing patient phone numbers is processing personal data.

Can we keep clinical records after a patient asks for erasure?

Erasure has to be reconciled with retention you owe under other law. Name the obligation you rely on, erase what falls outside it, and record the decision.

Is a consent form at the front desk enough?

Only if it becomes a record you can reproduce — purpose, date, channel, scope, withdrawal. A signed page in a drawer cannot answer a request two years later.

If you want to see a consent ledger, an access-request queue and per-user access logs in one system, book a 30-minute demo and bring your compliance lead to it.