DPDP for Healthcare: A Practical Guide to Patient Data, Consent and Breach Readiness

Updated 3 October 2026.

A patient's information can pass through several teams during a single hospital visit.

Reception collects their contact details. A doctor adds consultation notes. A laboratory returns test results. Billing sends documents to an insurer. A software provider stores some of that information, and an administrator may download a copy to resolve a query.

Each handoff raises a practical question. Why does this person need the information? What can they do with it? Who is responsible when something goes wrong?

That is where DPDP preparation becomes useful.

I have reviewed dozens of privacy policies from Indian hospital chains, diagnostic labs, and HealthTech platforms over the past year. The pattern is remarkably consistent: a privacy notice copied from a US-based SaaS template, referencing "HIPAA" or "GDPR" in the opening paragraph, with no mention of the Digital Personal Data Protection Act, 2023. Some of these organisations process the medical records of millions of patients across hundreds of facilities.

A better policy helps, but it needs to describe what the organisation actually does. If the notice promises that patients can withdraw marketing consent, someone must know how to stop the messages. If a vendor holds patient records, the hospital needs to understand who can access them.

This guide works through those decisions for hospitals, diagnostic labs and HealthTech teams.

First, understand what is coming into force

As of October 2026, the DPDP framework is being introduced in stages. Most of the substantive duties discussed here, including the core processing obligations and corresponding operational rules, are scheduled to commence in May 2027 under the notified eighteen-month timetable. Existing obligations, including applicable CERT-In reporting requirements, continue in the meantime. DPDP commencement notification.

Use this period to test your processes with the people who will run them. A registration team, an IT administrator and a medical records officer will each find gaps that a policy review alone can miss.

Start with one patient journey

Choose an ordinary visit and trace the information from appointment booking through treatment, billing and follow-up.

Include the places people can overlook: emailed reports, downloaded spreadsheets, messaging accounts, scanned forms and vendor support systems. Ask staff to show you what happens when the usual process fails. Where does a report go when the portal is unavailable? How does someone correct the wrong phone number?

A working record can be simple:

For each activity, record an owner. "The hospital" is too broad when a patient is waiting for an answer.

If you need a starting structure, our data audit guide explains how to build an inventory of processing activities.

Work out who makes the decisions

Under DPDP, a Data Fiduciary decides why and how personal data is processed. A Data Processor handles it on the fiduciary's behalf.

A hospital will generally make those decisions for its patient services. A software vendor storing records under the hospital's instructions may act as a processor. Another healthcare provider receiving a referral may make its own decisions about treatment and recordkeeping.

Those differences affect the arrangements you need.

Section 8(2) requires a valid contract when a Data Fiduciary engages a processor for the activities covered by that provision. Calling every recipient a "vendor" does not establish that they are all processors. DPDP Act, Sections 2 and 8.

For each outside organisation, establish what it receives, what instructions it follows and whether it uses the information for purposes of its own.

Then ask the operational questions. Who reports an incident? Who responds to a correction request? What happens to the records when the relationship ends?

Make registration understandable for the patient

A patient arriving for a consultation may be in pain, anxious or helping a family member. Give them information they can use in that moment.

Explain what you collect, why you need it and how they can contact you about their data. Where you rely on consent, the notice and consent process need to meet the Act's requirements. Rule 3 provides further detail on the notice, including clear descriptions of the data and purposes. DPDP Rules 2025, Rule 3.

Consent is not the only possible basis. Section 7 also permits specified legitimate uses, including certain uses of information voluntarily provided for a specified purpose. Its conditions matter. A phone number supplied for one purpose should not be treated as unrestricted permission for every later use. DPDP Act, Sections 6 and 7.

A useful exercise is to ask your registration team to retrieve the notice shown to a patient who visited last Tuesday.

Can they find the version the patient saw? Can they show the choices recorded? If the patient changes a preference, which systems receive that update?

This exercise will tell you more about your readiness than the number of pages in your privacy policy.

Look closely at referrals, insurance claims and recordings

These three situations deserve their own review because information moves beyond the original interaction.

Patient referrals. Before sending records to another provider, establish what that provider needs and how the information will be transferred. Check the recipient, the patient-facing explanation and the basis for sharing. Avoid making the whole patient file the default attachment.

Insurance claims. Give billing teams a clear process for identifying the documents needed for a claim. Keep a record of what was sent and to whom. The team should also know what to do when an insurer requests additional information.

Consultation recordings. Decide why you need a recording before enabling the feature. Treatment notes, quality reviews, staff training and product development are different activities. Review the basis for each intended use, the explanation given to the patient, access permissions and retention.

For a HealthTech platform, this review should include the tools connected to the consultation service. Check whether a transcription provider retains audio, whether support staff can replay it and whether another service receives it for model training.

Those are configuration and contract questions as much as writing questions.

Keep the emergency route clear

The Act expressly recognises processing needed to respond to a medical emergency involving a threat to life or an immediate threat to health. It also provides for treatment and health services during epidemics, outbreaks and other public-health threats. DPDP Act, Sections 7(f) and 7(g).

Your process should make that route clear to the staff who need it.

Document how emergency access is authorised and reviewed. Make sure the team can distinguish urgent use of information from later activities such as a promotional campaign or unrelated analysis.

A practical review would also ask what happens after the emergency: which temporary access permissions remain open, where information was shared and whether those records are captured.

Check the boundaries of the children's healthcare exemption

Rule 12 and the Fourth Schedule provide conditional exemptions from Sections 9(1) and 9(3) for specified healthcare organisations and professionals. The conditions focus on necessary health services and, for allied healthcare professionals, support for the relevant treatment and referral plan. Section 9(2), concerning processing likely to harm a child's well-being, still applies. DPDP Rules, Rule 12 and Fourth Schedule.

Check both the organisation and the activity.

A service describing itself as "HealthTech" should not assume that every feature qualifies. Maintaining a child's treatment record, running an advertising campaign and developing a commercial profile need separate consideration.

For each activity relying on the exemption, keep a short explanation of the qualifying category and the conditions you have checked. Staff should be able to understand that explanation without reconstructing the legal analysis themselves.

Give research its own assessment

A hospital may use records to study outcomes, improve services or support a clinical trial. The word "research" alone does not settle the data-protection position.

Section 17(2)(b) sets conditions for the research, archiving and statistical exemption, including that the personal data must not be used to make decisions specific to an individual. The prescribed standards have already been published through Rule 16 and the Second Schedule. DPDP Act, Section 17, DPDP Rules, Rule 16.

Review each project's purpose, dataset, access arrangements and intended outputs. Studying a pattern across a population raises different questions from using the analysis to decide what treatment a named patient receives.

Be precise about anonymisation too. Removing names may leave other information that identifies a person. Ask what someone could work out from the remaining fields and any additional information available to them.

Keep the DPDP assessment alongside the project's ethics and clinical-research documentation. The team should be able to see which requirements have been considered and who approved the approach.

Prepare for patient requests across systems

A patient may ask about the processing of their information, request a correction or seek erasure. Under Sections 11 to 14, the Act provides rights covering access to information, correction and erasure, grievance redressal and nomination, subject to the applicable provisions. DPDP Act, Sections 11 to 14.

The difficult part for a hospital is finding the relevant systems and getting a coordinated response.

A corrected phone number may need to reach the appointment platform, patient portal and billing system. A request sent to the wrong department should still reach the person responsible for handling it.

Assign one team to coordinate requests, with named contacts in the departments and vendors it depends on. Record what was requested, how identity was checked, what action was taken and what was communicated to the patient.

Set retention rules that people can explain

Avoid one blanket retention period for everything.

A consultation record, an insurance document, a marketing list and a support recording may have different purposes and different legal requirements. Section 8(7) recognises retention necessary for compliance with law when setting out the erasure obligation. DPDP Act, Section 8(7).

Build a schedule by record category. Identify the purpose, the applicable retention requirement, the point from which time is counted and the person responsible for disposal.

Include copies outside the main patient system. Ask how deletion reaches exports and vendor systems, and how backups are handled. When a record must be retained, the team should be able to explain the reason and restrict its use appropriately.

Test security where staff actually work

Section 8(5) contains the reasonable-security-safeguards obligation. Rule 6 sets out further requirements. DPDP Act, Section 8(5), DPDP Rules, Rule 6.

Turn the security review into practical checks:

• Can a staff member see records unrelated to their work?
• Are accounts removed promptly when someone leaves?
• Can a vendor access live patient data without approval?
• Can you identify who downloaded or changed a record?
• Have you tested restoring the systems needed for patient care?
• Do staff have a secure way to share reports that is convenient enough to use?

Ask people to demonstrate the answers. A setting marked "enabled" is less useful than evidence that the control works in the situation you care about.

Prepare for a breach before anyone needs to find the reporting template

A breach response needs named decision-makers, working contact details and a way to act outside office hours.

The upcoming DPDP reporting process is often shortened to "72 hours". That misses the first step. Rule 7 requires notification to affected individuals and an initial notification to the Board without delay. The detailed Board update follows within 72 hours of awareness, unless the Board allows more time on a written request. DPDP Rules, Rule 7.

CERT-In's existing directions have a separate six-hour deadline for the specified categories of cyber incidents, measured from noticing the incident or being informed of it. CERT-In Directions, 28 April 2022.

Build both assessments into the response plan. Give someone responsibility for recording when the organisation became aware, preserving evidence, coordinating the technical investigation and preparing communications.

Then run a tabletop exercise. Use a scenario such as a compromised laboratory account or an exposed report download. Check whether the team can establish what happened, who may be affected and who has authority to send the required notifications.

An exercise also reveals ordinary problems: an outdated phone number, an approval that depends on one person, or a vendor contract that says very little about incident cooperation.

Keep existing healthcare obligations in view

DPDP preparation needs to fit alongside the requirements already relevant to your organisation.

For example, participants in ABDM should review the applicable health-data exchange and consent arrangements under its Health Data Management Policy. ABDM Health Data Management Policy.

Your organisation may also need to account for professional confidentiality, clinical-record requirements, insurance arrangements and research governance. Identify the applicable requirements for each activity and bring the relevant owners into the review.

This is particularly useful where two teams have made different assumptions about the same records. Billing may expect to retain a document for one reason while the patient-services team has promised something else.

Frequently asked questions

The main DPDP business duties discussed below are scheduled to commence in May 2027 under the government's commencement notification. Existing sectoral and cybersecurity requirements operate on their own timelines.

Is consent to medical treatment the same as consent to process patient data?

Consent to a medical procedure and the legal basis for processing personal data are separate assessments. A hospital needs to identify why it collects, uses and shares each category of patient information. DPDP provides for consent and the certain legitimate uses in Section 7. Signing a treatment form should not be treated as blanket permission for unrelated promotions, consultation recordings or model training.

Sources: DPDP Act, Sections 4, 6 and 7.

Can a hospital process patient data during an emergency without first obtaining consent?

Section 7(f) provides a legitimate-use route for processing needed to respond to a medical emergency involving a threat to life or an immediate threat to health. Section 7(g) separately addresses treatment and health services during epidemics, outbreaks and other public-health threats. Document the relevant circumstances and protect the information. An emergency justification does not automatically extend to later advertising or unrelated analysis.

Sources: DPDP Act, Sections 7(f) and 7(g).

Can a patient require a hospital to delete all their medical records?

A patient's erasure request does not automatically require deletion of records that must be retained under applicable law. The hospital should assess the record category, purpose and retention requirement under Sections 8(7) and 12, alongside relevant healthcare obligations. Explain what can be erased and what remains for a stated reason. Keeping a clinical record does not, by itself, justify continued promotional use of the patient's contact details.

Sources: DPDP Act, Sections 8(7) and 12.

Does the children's healthcare exemption cover every HealthTech product?

The children's healthcare exemption does not cover every product described as HealthTech. Rule 12 and the Fourth Schedule identify qualifying establishments and professionals, with conditions tied to necessary health services or support for the relevant treatment and referral plan. Check the provider and the specific activity. The exemption concerns Sections 9(1) and 9(3); the separate restriction on harm to a child's well-being remains.

Sources: DPDP Rules, Rule 12 and Fourth Schedule; DPDP Act, Section 9.

Does calling a project research exempt it from DPDP?

Calling a project research does not establish the exemption. Section 17(2)(b) requires the processing to be necessary for research, archiving or statistical purposes, excludes use to make decisions specific to an individual, and requires compliance with the prescribed standards. Rule 16 and the Second Schedule supply those standards. Assess the project's dataset, outputs and intended uses; a population study and a named patient's treatment decision raise different questions.

Sources: DPDP Act, Section 17(2)(b); DPDP Rules, Rule 16 and Second Schedule.

Are all hospital software vendors Data Processors?

A hospital software vendor is a Data Processor when it processes personal data on the hospital's behalf. If it independently determines a purpose and means for another use, that activity needs a separate Data Fiduciary assessment. Check the service terms and actual data flows, including support access, analytics and model training. A processor label in the contract does not settle uses the vendor makes independently.

Sources: DPDP Act, Sections 2(i), 2(k) and 8.

What to do first

Start with a manageable piece of work that produces something the team can use.

Choose one patient journey. Map the systems, departments and outside organisations involved. Review the notices and choices at each step. Test one correction or erasure request. Walk through an incident with the people who would actually respond.

Keep a short record of the gaps, the owner of each change and the evidence needed to show it has been completed.

For a wider view of the work, use our DPDP compliance checklist.

ComplyZero helps Indian businesses organise DPDP readiness, consent records, privacy work and supporting evidence. If your healthcare team needs help turning its findings into a practical implementation plan, talk to ComplyZero.

This article provides general information. The requirements applicable to a particular healthcare organisation depend on its activities, legal status and other obligations.