Table of contents
India's Digital Personal Data Protection (DPDP) Act treats health information as personal data requiring meaningful consent and careful handling, and it applies to any software processing patient data for an Indian provider — a hospital's own systems, a clinic's practice-management software, or a third-party health-tech platform. Unlike sector-specific health data laws in some other jurisdictions, the DPDP Act is India's general data protection framework, which means healthcare providers need to interpret its general requirements for their specific, sensitive context rather than following a health-specific checklist that doesn't fully exist yet.
This guide covers what the DPDP Act practically requires for healthcare software — consent, data handling, breach notification and vendor due diligence — written for providers and platforms evaluating or building software that touches patient data, not as a substitute for qualified legal review of your specific situation.
- Applies to
- Any software processing patient personal data for an Indian provider
- Core requirement
- Clear, specific, informed consent — not a buried checkbox
- On a breach
- Notification obligations apply — plan for this before it happens
- Vendor risk
- You remain accountable even when a vendor processes the data
What the DPDP Act requires, in practice
The DPDP Act's core mechanism is consent: a healthcare provider or platform processing a patient's personal data needs clear, specific, informed consent for that processing, presented in a way the patient can actually understand — not a long, generic terms-of-service checkbox that technically mentions data use somewhere in paragraph twelve. For healthcare specifically, this matters more than in most other sectors, because the data involved (diagnoses, treatment history, prescriptions) is inherently sensitive and its misuse carries real consequences for the patient beyond the usual privacy concerns.
Beyond consent, the Act's general obligations apply squarely to healthcare data handling: purpose limitation (using patient data only for the purpose it was collected for, not repurposing it silently for something else), data minimization (collecting only what's actually needed for the stated purpose), reasonable security safeguards proportionate to the sensitivity of the data, and defined data retention — not keeping patient data indefinitely once the purpose it was collected for no longer applies.
Consent in a clinical workflow
Getting consent right in a healthcare setting has a real practical tension: the consent needs to be genuinely informed and specific, but a clinical workflow can't reasonably ask a patient to review a lengthy legal document during every interaction. The patterns that work in practice: a clear, plain-language consent capture at the start of a care relationship (not buried in intake paperwork), specific enough to cover the actual categories of processing involved (storage, sharing with specific categories of parties, any AI-assisted processing), and a straightforward way for the patient to understand and, where the Act provides for it, withdraw consent later.
| Obligation | What it means in practice | Common failure mode |
|---|---|---|
| Informed consent | Clear, specific consent for how patient data will be processed | A generic, unread terms-of-service checkbox treated as sufficient |
| Purpose limitation | Using data only for the purpose it was collected for | Reusing clinical data for unrelated purposes (e.g. marketing) without fresh consent |
| Data minimization | Collecting only what's needed for the stated purpose | Capturing broad data "in case it's useful later" |
| Security safeguards | Reasonable, proportionate technical and organizational protection | Treating security as an IT afterthought rather than a designed-in requirement |
| Breach notification | Notifying the Data Protection Board and affected individuals as required | No incident response plan in place before a breach happens |
| Vendor accountability | The provider remains responsible even when a vendor processes the data on its behalf | Assuming a vendor's own compliance claim is sufficient without verification |
A vendor's compliance claim doesn't transfer your accountability
When a third-party platform, AI tool or cloud provider processes patient data on your behalf, you as the healthcare provider remain accountable for that data under the DPDP Act — a vendor's marketing claim of being "DPDP compliant" is a starting point for due diligence, not a substitute for it. Get specifics in writing: what data they process, where it's stored, who has access, whether it's used to train any model, and what happens to it if the relationship ends.
Vendor due diligence for healthcare software
Most healthcare providers today rely on multiple third-party systems — practice management software, an AI clinical documentation tool, a cloud hosting provider, a billing platform — each of which is a point where patient data leaves the provider's direct control. Before adopting any of them, the practical due diligence questions are concrete: exactly what patient data does the vendor access or store, is any of it used to train AI models beyond serving your account, what security certifications or audits back their claims (rather than marketing language alone), what's their data breach notification process and timeline, and what happens to your data if you stop using the vendor.
This diligence should scale with sensitivity and scope — a vendor handling full clinical records deserves considerably more scrutiny than one handling only appointment scheduling metadata. Document these answers in writing as part of vendor selection, not as an afterthought once a contract is already signed.
Breach response: plan before, not during
The DPDP Act creates breach notification obligations, and the worst time to figure out your notification process is during an actual incident. A basic incident response plan — who's notified internally, how you assess what data was affected, the notification timeline and process for both the regulator and affected patients, and a communication plan for patients — should exist before it's needed. This is a standard practice recommendation regardless of the specific regulatory regime, but the stakes are higher with health data given both the sensitivity of the information and the trust relationship at stake with patients.
If you're evaluating or building an AI-assisted clinical tool specifically, see our AI medical scribe buyer's guide for the data-privacy evaluation questions specific to that category, and our broader healthcare AI use-case guide for where AI genuinely helps in healthcare operations versus where it shouldn't be trusted unsupervised.
- Consent capture is clear, specific and in plain language — not a buried generic checkbox
- Patient data use is limited to the purpose it was actually collected for
- Only data genuinely needed for the stated purpose is being collected
- Every third-party vendor handling patient data has been through documented due diligence
- Security safeguards are proportionate to the sensitivity of the data handled
- A breach response plan exists and has been reviewed, not assumed
- Data retention periods are defined, not indefinite by default
- Qualified legal counsel has reviewed your specific processing activities
Building or evaluating healthcare software?
Talk to our team about data privacy considerations for your specific healthcare software project — or explore Znapie Doctor's Assistant.
Frequently asked questions
Does the DPDP Act apply to all healthcare software in India?+
It applies to any processing of personal data by an Indian provider or a platform processing data for one — which covers hospital systems, clinic practice-management software, and third-party health-tech platforms handling patient data.
What kind of consent does the DPDP Act require for patient data?+
Clear, specific and informed consent — presented in a way the patient can genuinely understand, not a generic, unread terms-of-service checkbox that technically mentions data use.
Is a healthcare provider still responsible for patient data handled by a vendor?+
Yes — using a third-party vendor to process patient data doesn't transfer accountability under the DPDP Act. The provider needs to conduct real due diligence on any vendor handling patient data, not rely on the vendor's compliance claims alone.
What should a healthcare provider do to prepare for a potential data breach?+
Have an incident response plan in place before any breach occurs — who's notified internally, how affected data is assessed, the notification timeline for regulators and patients, and a patient communication plan. This should not be figured out for the first time during an actual incident.
What questions should I ask an AI or software vendor handling patient data?+
What data they access or store, whether it's used to train AI models beyond your account, what security certifications back their claims, their breach notification process, and what happens to your data if you stop using the vendor — get all of this in writing.
Is this guide a substitute for legal advice on DPDP compliance?+
No — this is a practical overview to inform your evaluation. Specific obligations depend on your exact data processing activities and should be confirmed with qualified legal counsel for your situation.
Written by
CodeSurge AI Engineering Team
The CodeSurge AI team designs and builds AI systems, SaaS products and enterprise integrations for clients in India, the UAE and beyond — this section shares the architecture patterns, cost drivers and implementation tradeoffs we work through on real projects.