How to handle a patient data access, correction, or erasure request under DPDP

When a patient asks to see, fix, or delete the data your clinic holds on them, the work is yours to do, not your software's. The Digital Personal Data Protection Act, 2023 gives every patient (the data principal) the right to access, correct, and erase their personal data, and your clinic (the data fiduciary) has to act on each request. Here is the manual runbook.

This is a clinic process, not a button. Good software helps you find and pull the record, but a person reads the request, checks who is asking, decides what the law lets you keep, and writes back. Treat the steps below as a standing operating procedure your front desk and you can run every time.

What the patient can actually ask for

The DPDP Act, 2023 gives the patient three operational rights you will see in practice. Get the vocabulary right, because each one ends differently.

Request	What it means	What you must do
Access (Section 11)	A summary of the personal data you hold and process, plus who you shared it with	Provide the summary and the list of recipients
Correction (Section 12)	Correct, complete, or update inaccurate or incomplete data	Fix it on receipt of the request
Erasure (Section 12)	Delete their personal data	Erase it, unless you must keep it for the original purpose or under another law

Erasure is the one to read carefully. Section 12 says you "shall erase" the data "unless retention of the same is necessary for the specified purpose or for compliance with any law for the time being in force." Medical records carry their own retention rules, so a patient asking you to wipe a clinical file does not always override a record you are legally required to keep. Where it is unclear, hold the record and confirm with a professional rather than deleting in haste. We cover the keep-or-bin question in records retention and disposal.

Step 1: Publish a contact point so requests have a front door

Under Section 8 of the Act, a data fiduciary has to publish the contact details of a person who can answer a patient's questions about how their data is processed. The DPDP Rules, issued in November 2025, restate this as publishing the contact of an authorised person for queries.

In a small clinic this is one line on your privacy notice, your website, and a printed sheet at reception: a name or role, an email, and a phone number. Decide internally who owns it, usually the owner-doctor or the practice manager. If a request lands on WhatsApp or in a verbal aside at the counter, route it to that single inbox so nothing slips.

Step 2: Log the request the moment it arrives

Open a simple register, a spreadsheet or a notebook, and record every request on arrival: the date, the patient's name, what they asked for (access, correction, or erasure), and how it came in. This log is your proof that you acted, and your clock starts here.

Do not skip this even for a casual "can you delete my number." A logged request is a request you can show you handled. An unlogged one is a request you will forget on a busy morning.

Step 3: Verify who is asking before you hand anything over

This step protects the patient, not the clinic. Handing a record to the wrong person is itself a data breach. The Act also puts a duty on the patient not to impersonate someone else, but the responsibility to check sits with you.

Confirm identity the way you would for any sensitive counter request: match a government ID or the registered phone number and date of birth against the record. For a request made on behalf of a child or a dependent, check the relationship. Note in your log how you verified. If the person sending the email is not obviously the patient, ask for a second identifier before you proceed.

Step 4: Locate every copy of the record

You can only fulfil a request for data you can find. This is where structured records earn their place. In Avinya Plus, a patient's chart pulls together their demographics, allergies, medications, and a chronological timeline of visits, labs, imaging, prescriptions, and procedures in one place, and those records are exportable. That makes assembling an access summary a search, not an archaeology dig.

But map the whole picture, not just the EMR. Patient data also lives in your billing ledger (GST invoices carry name, phone, and what was done), in appointment history, and sometimes in paper files, a WhatsApp chat, or a spreadsheet a staff member kept. List every place the patient appears before you respond, so an "access" summary is complete and an "erasure" actually clears every copy you are allowed to clear.

Step 5: Fulfil the request, and keep the part you must keep

Now act, by type:

• Access: export the patient's record into a readable format and give them a summary of what you hold and who you shared it with. The exportable structure of your records is what makes this a quick task rather than a manual transcription.
• Correction: edit the field, complete the missing detail, or update the stale entry. Keep the old value visible in your trail so the change is traceable.
• Erasure: delete what you are not required to retain. Where a medical-record retention rule or another law forces you to keep a file, you keep it, and you tell the patient plainly that you are retaining it for that reason. This is exactly the line Section 12 draws.

A note on what the software does not do here. There is no auto-deletion engine that decides for you, and no consent module that runs this workflow on your behalf. The decision about what to erase versus retain is a clinical and legal judgement your clinic makes. If a vendor implies its tool decides retention automatically, ask precisely what it deletes, when, and on whose authority. More on the manual side of this in the work clinic software leaves to you.

Step 6: Record what you did, and respect the trail

Close the loop in your log: what you provided or changed, the date, and who handled it. Then write back to the patient confirming the action.

Your audit trail supports this without being the whole answer. Avinya Plus logs every create, update, delete, view, and download against a named user, so months later you can show who touched a record and when. Role-based access keeps reception on the calendar and clinical charts with doctors, which limits who could have handled the data in the first place. That evidence is useful when a patient queries what happened, but the request log and your written reply are the records that show you honoured the right.

Grievances: give patients a way to escalate

The Act also gives patients a right to grievance redressal (Section 13) and expects them to use your clinic's mechanism before approaching the Data Protection Board. So publish how a patient complains if they are unhappy with your response, and respond within the period the Rules prescribe. A clear escalation path at the clinic is both a legal expectation and the thing that keeps a complaint from becoming a Board matter.

Two more reads to round this out: a plain-language DPDP Act primer for clinics and the related patient consent under DPDP, since consent and rights requests sit side by side in the same law.

This is general guidance for running a clinic, not legal advice. The DPDP Rules are recent and parts are being rolled out in stages, so confirm your specific duties and the prescribed timelines with a qualified professional.