DPDP for the Operations head in Healthcare

Snooping on VIP, celebrity, colleague or neighbour records is a common problem. Give access by role, mark sensitive records, ask for a reason before opening them, allow break-glass access in emergencies, and review those logs every week.

Rule 6 requires access control and monitoring. Section 8(5) · Rule 6 · Section 8(6) · Rule 7

1. Flag VIP, staff and sensitive records.
2. Ask for a reason to open them.
3. Allow break-glass with review.
4. Review logs weekly.
5. Act on misuse consistently.

• Flag settings
• Review records
• Action records

• Everyone can see everything
• Break-glass never reviewed
• No action on misuse

• Who should be able to see personal data in our systems?
• Which logs must we keep, for how long, and where?
• Which records need extra protection under other health laws?

ABDM uses a consent manager and consent artefacts to share health records between providers. That consent covers ABDM sharing. You still need your own DPDP notice for what you collect, and your own safeguards, retention and grievance process. The two should use the same plain language so patients are not confused.

Section 5 and 6 for your own notice and consent; ABDM's policy for ABDM sharing. Section 5 · Rule 3 · Section 6 · Section 8(5) · Rule 6

1. Map what goes through ABDM and what does not.
2. Align notices with ABDM screens.
3. Log ABDM consent requests.
4. Keep safeguards on the gateway.
5. Train front desk on ABHA linking.

• Flow map
• Aligned notices
• Gateway logs

• Assuming ABDM consent covers everything
• ABHA linking without explanation
• Gateway with weak access

• What should our privacy notice say, and where must people see it?
• When do we need consent, and when can we rely on a legitimate use?
• Where does personal data live in our organisation?

A notice must tell people, in plain words, what data you collect, why, how they can withdraw consent, how they can use their rights and how they can complain to the Data Protection Board. It has to stand on its own, separate from long terms and conditions, and be shown at the point where data is collected.

Registration desks, appointment apps, lab forms and health-camp sign-ups need short notices in the languages patients speak.

Section 5 and Rule 3 ask for a notice that can be understood on its own, with an itemised list of the data and the purpose for each item. Data you already hold from before the Act also needs a notice, as soon as reasonably practicable. Section 5 · Rule 3 · Section 6 · Sections 11–14 · Rule 14

1. List every point where personal data comes in: forms, apps, counters, calls, emails, partner feeds.
2. Write one short notice per collection point, with the data items and purpose side by side.
3. Add how to withdraw consent, how to make a request and the DPO or contact person's details.
4. Offer the notice in English and in the languages your patients actually use.
5. Keep each version with the date it went live.

• Screenshots or copies of the notice at each collection point, with dates
• Notice version history
• Translations, where used

• Hiding the notice inside terms and conditions
• One notice for everything, with no link between data items and purposes
• Forgetting old data collected before the Act

• When do we need consent, and when can we rely on a legitimate use?
• Someone withdraws consent. What has to stop, and how fast?
• Someone asks what data we hold about them. What do we send?

Send a summary of the personal data you hold about them and what you do with it, and the names of the other organisations you shared it with and what was shared. Check the person's identity first, log the request and keep a copy of your reply.

Under the 2002 regulations, patients and authorised attendants should get record copies within 72 hours of a request. The DPDP summary adds who the data was shared with.

Section 11 gives the right to a summary and the list of organisations it was shared with. Rule 14 asks you to publish how requests are made and to answer within the period you publish. Sections 11–14 · Rule 14 · Section 8(9)–(10) · Rules 9, 14

1. Log the request in one register the day it arrives.
2. Verify identity using details you already hold.
3. Search every system, including vendors' copies.
4. Write a plain summary: what data, why it is used, who received it.
5. Send it, and file the request, search notes and reply.

• Request register
• Search notes for each request
• Copy of each reply with date

• Sending raw database dumps
• Forgetting data held by vendors
• No identity check before sending

• How do we handle a privacy complaint within 90 days?
• Someone asks us to delete their data. Must we?
• Where does personal data live in our organisation?

Publish one clear way to complain, log every complaint, give it an owner and reply within the period you publish, never more than 90 days. People can go to the Data Protection Board only after using your process, so a good process keeps most matters with you.

Patient relations already handles complaints. Tag the data ones and count the days.

Section 8(10) requires a working grievance process. Rule 14(3) caps the reply time at 90 days. Section 13 says people must use your process before approaching the Board. Section 8(9)–(10) · Rules 9, 14 · Sections 11–14 · Rule 14 · Sections 18–26

1. Publish one contact for privacy complaints on your website, app and notices.
2. Log each complaint with the date, channel and a named owner.
3. Acknowledge within a few days, and set an internal target well under 90 days.
4. Find and fix the cause, not just the single case.
5. Reply in writing and close the entry with the date.

• Complaint register with dates
• Replies sent
• Monthly summary to management

• Mixing privacy complaints into general complaints with no tag
• No owner, so nobody counts the days
• Closing a complaint without fixing the cause

• Someone asks what data we hold about them. What do we send?
• Someone asks us to delete their data. Must we?
• Someone withdraws consent. What has to stop, and how fast?

Sending personal data to the wrong chat or a personal account is one of the most common breaches. Banning messaging rarely works. Give staff an approved tool that is easy to use, set simple rules, and make it safe to report a wrong send at once.

Reports and images on WhatsApp groups are the most common hospital breach.

Section 8(5) asks for reasonable safeguards. A wrong send is a breach under Section 2(u), and Section 8(6) applies. Section 8(5) · Rule 6 · Section 8(6) · Rule 7

1. Ask teams how they actually share files and photos today.
2. Provide an approved tool for that job.
3. Set three simple rules: approved tool, no personal accounts, report wrong sends.
4. Teach the rules with real examples from your own work.
5. Treat a quick report as good behaviour, not a disciplinary case.

• Approved-tool policy
• Training record
• Incident reports of wrong sends

• A ban with no alternative
• Punishing people who report
• Ignoring group chats with vendors

• Something has gone wrong. What happens in the first 72 hours?
• Who needs DPDP training, and what should it cover?
• Who should be able to see personal data in our systems?

All three are personal data. Put a clear notice where people are recorded, collect only what you need at reception, keep footage and registers for a set period, and protect biometric templates carefully. Do not keep copies of ID documents unless you must.

CCTV must not cover examination or changing areas; put notices at entrances.

Section 5 needs notice. Section 8(5) needs safeguards. Section 8(7) needs erasure after the purpose. For staff, Section 7(i) can cover security and attendance. Section 5 · Rule 3 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8 · Section 7

1. Put notices at CCTV points and reception, in the local language.
2. Ask visitors only for name, phone and whom they are meeting, unless security needs more.
3. Set a period for footage and registers, then delete.
4. Restrict who can view footage, and log viewing.
5. Check the vendor contracts for CCTV, guards and attendance systems.

• Notices in place
• Retention settings on the recorder
• Viewing log

• Photocopying visitor IDs as routine
• Footage kept until the disk fills
• Biometric systems with vendor default passwords

• Are contract and agency workers our responsibility?
• How long can we keep personal data?
• What must a vendor contract say about personal data?

Call recordings, chat transcripts and agent screens hold a lot of personal data. Tell callers that calls are recorded and why, keep recordings for a set period, limit who can listen, and mask card numbers and passwords on screen and in recordings.

Appointment and lab call centres record names and conditions.

Section 5 needs notice, Section 8(5) needs safeguards, and Section 8(7) needs erasure after the purpose. Section 5 · Rule 3 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8

1. Play a short recording notice at the start of calls.
2. Set a retention period by call type.
3. Pause recording when card or other sensitive details are given.
4. Limit replay rights to quality and complaint teams.
5. Lock agent screens and stop phones on the floor if data is sensitive.

• Recording notice script
• Retention settings
• Replay access list

• Recordings kept indefinitely
• Card numbers in recordings
• Open replay access for all supervisors

• How long can we keep personal data?
• Who should be able to see personal data in our systems?
• How do we handle a privacy complaint within 90 days?

You must erase data that you no longer need for the purpose it was collected for, unless a law requires you to keep it. Where a law does require it, keep the data, stop using it for anything else, and tell the person why it is being kept and until when.

Medical records have legal minimums; a patient's erasure request cannot cut those short.

Section 12 gives the right to correction and erasure. Section 8(7) allows retention only where a law requires it. Rule 8(3) asks every organisation to keep personal data and logs for at least one year first. Sections 11–14 · Rule 14 · Section 8(7) · Rule 8

1. Log the request and verify identity.
2. Check the retention schedule for each record type involved.
3. Delete what has no legal reason to stay, including copies with vendors and in test systems.
4. Mark what must stay, with the law and the end date.
5. Reply in plain words: what was deleted, what is kept, why and until when.

• Erasure log
• Vendor deletion confirmations
• Reply to the person

• Refusing every erasure request 'because of backups'
• Deleting records a law requires
• Not telling vendors

• How long can we keep personal data?
• Does deletion have to reach backups and test copies?
• Someone asks what data we hold about them. What do we send?