A DPDP Act Readiness Checklist for Hospitals

Consent under the Act is expected to be free, informed, specific, and unambiguous, given for a stated purpose and capable of being withdrawn. A single signature on an admission form covering every conceivable future use of a patient's data does not meet that description. Purposes must be separated so a patient can agree to one and refuse another.

The notice accompanying a request has to be understandable, which in an Indian hospital means available in the languages patients actually speak. A notice written for a legal audience and handed over at an admission desk is a compliance artefact rather than a communication. Test comprehension with real patients before adopting the wording.

Distinguish clearly between processing needed to deliver care and processing that is genuinely optional, such as marketing contact or research participation. Bundling the optional with the essential is the most common defect we find. Care must never be made conditional on agreeing to an optional purpose.

Purpose limitation means data collected for one reason is not quietly repurposed for another. In a hospital the common breach is undramatic: a marketing team pulls a list from the clinical system, an administrator uses billing records to find prospects for a health package, a department shares a patient list with an external partner. None of these feels like a violation to the person doing it, which is why the control has to be technical as well as instructional.

Retention needs a schedule reconciling clinical need, statutory obligation, accreditation expectation, and the principle of not keeping data longer than its purpose requires. These pull in different directions, and the resolution belongs to the hospital and its own legal advisers rather than to a software default. Write it down, date it, and give it an owner.

Deletion must be real and must reach backups, archives, exports, and downstream copies. A record removed from the primary database while surviving in three reporting extracts has not been deleted in any meaningful sense. Document what was disposed of, when, and under whose authority.

The Act requires reasonable security safeguards, and in a hospital the most consequential of these is that staff reach only the records their role requires. Broad access granted for convenience is the default state in many hospitals, particularly where a system was configured quickly and permissions were never revisited. Every account holding more access than its role needs is an unnecessary exposure.

Review role definitions against the current organisation chart, remove access on the day someone changes role or leaves, and eliminate shared logins entirely because they destroy attribution. Break-glass access for emergencies should exist but should be exceptional, logged, and reviewed afterwards. HealUDoc supports role and branch-scoped access with an audit trail, though whether the roles themselves are correct remains a hospital decision.

Logging is what turns a control into evidence. Being able to show who opened a record, when, and from where is what lets a hospital answer a complaint or investigate an incident credibly. Logs nobody ever reviews provide considerably less assurance than they appear to.

Patients hold rights over their data, including access to information about processing, correction of inaccurate data, erasure in defined circumstances, grievance redress, and nomination of someone to act on their behalf. Each right needs an operational route: a place requests arrive, a person who owns them, a way to verify who is asking, and a defined turnaround. Without that, a right exists on paper and fails in practice.

Correction is the one hospitals find hardest, because a clinical record cannot simply be overwritten. The workable approach is an amendment preserving the original entry, recording who requested and who approved the change, and propagating the correction to places the data was already sent. HealUDoc's audit trail retains the original entry alongside the amendment for this reason.

A patient portal (/patient-portal) reduces the volume of routine access requests by letting patients see their own records directly, but it does not replace a formal request channel. Publish the channel, staff it, and log every request with its outcome and timing. Independent legal advice should confirm how each right applies to your hospital's circumstances.

The Act contemplates notification of personal data breaches, and the quality of a hospital's response is largely determined before anything happens. What matters on the day is whether you can establish what was accessed, whose data was involved, and over what period, which depends entirely on logging configured months earlier. A hospital unable to scope an incident cannot report it accurately.

Write and rehearse the plan: who is notified internally, who decides, who communicates with affected individuals and authorities, and what is recorded throughout. Include incidents that are not cyberattacks, such as a misdirected discharge summary, a lost device, a misused shared login, or a vendor's error. These are far more frequent than intrusions and are usually handled worse.

Run a tabletop exercise at least annually and after any material change to systems or suppliers. Contracts with vendors and processors should state their notification obligations to you and their duty to cooperate during an investigation. None of this makes a hospital compliant on its own, and no software product can; compliance is the sum of governance, contracts, configuration, and behaviour.