The Scenario
Harini is the CFO of a mid-sized private hospital group in Tamil Nadu. The group had invested significantly in a business intelligence platform, which pulled data from their hospital management system, OPD records, pharmacy transactions, and diagnostic reports. The platform generated dashboards that the management team used for operational decisions — bed utilisation, consumable planning, department profitability, and patient retention.
At the end of the financial year, the analytics vendor offered a value-added service: a patient re-engagement module that would use the same data to identify patients who had not returned for follow-up visits and send them targeted health alerts via SMS and email. The hospital management approved the feature.
What the hospital had not done was revisit the consent it had obtained from patients at registration. That consent — collected through a standard hospital intake form — covered the processing of personal data for the provision of medical care and for billing purposes. It did not cover the use of diagnostic and prescription data for automated marketing outreach.
The DPDP Act Position
This scenario involves a textbook purpose limitation failure — one that also carries significantly aggravated risk because the personal data in question is health data.
First — Processing beyond the specified purpose under Section 8(1). Section 8(1) of the DPDP Act makes the Data Fiduciary responsible for compliance with the Act in respect of processing carried out by it or by any Data Processor on its behalf. The analytics vendor, when it ran the re-engagement module, was a Data Processor acting on the hospital’s behalf. Consequently, the hospital bears liability for this processing. The specified purpose under which patient data was collected was medical care and billing. Re-engagement marketing is not a purpose covered by that consent — regardless of whether the hospital subjectively considered it beneficial to patients.
Second — Data Processor contract inadequacy under Section 8(2). Section 8(2) requires the Data Fiduciary to ensure that its Data Processor processes personal data only for the specified purpose under a valid contract. The analytics vendor’s contract, in this case, covered the provision of BI dashboards and reporting. The re-engagement module was a new capability added under an expanded commercial arrangement — but without a corresponding update to the Data Processor contract to reflect the new processing purpose, and without fresh consent from patients for that purpose.
Third — Retention and purpose drift under Rule 8. Rule 8 of the DPDP Rules, 2025 governs the time period for which personal data may be retained once its specified purpose is served. Health data collected for a specific episode of care — an OPD visit, a diagnostic test — remains subject to the purpose for which it was collected. Feeding that data into a marketing analytics module after the specified purpose has been served is a purpose drift violation, compounded by the retention obligation.
The IS Audit 3.0 Perspective
IS Audit 3.0 by ICAI identifies data privacy and confidentiality as the leading challenge for data analytics deployments, specifically calling out the risk of data being misused once it is accessible to an analytics platform. Hospital management systems are among the most data-rich environments in any organisation. However, that richness also makes them among the highest-risk environments for purpose drift — the gradual expansion of analytics use cases beyond the original data collection purpose.
Importantly, IS Audit 3.0 material by ICAI also flags the risk that insufficient evidence is retained on file about the procedures and inputs used in analytics processing. In the hospital’s case, there was no audit trail linking the re-engagement module’s data inputs to a consent record. Consequently, if the Data Protection Board of India ever investigated, the hospital would be unable to demonstrate that lawful basis existed for the marketing processing.
The Compliance Fix
Healthcare organisations — and any organisation running analytics on data collected for a primary service purpose — must:
→ Conduct a purpose mapping exercise before activating any new analytics module. Every new use case must be traced back to a consent record that explicitly covers it.
→ Review and update all Data Processor contracts each time the analytics vendor introduces a new processing module or capability. Section 8(2) compliance requires the contract to reflect the actual processing being performed.
→ Maintain consent records that are granular enough to support an audit trail. “Patient consented to data processing” is not sufficient. The consent record must specify what data was covered, for what purpose, and at what point in time.
→ Apply purpose limitation controls at the analytics platform level — configure data access so that each module can only access the data categories covered by the relevant consent record.
→ Obtain fresh, specific consent before using health data for any purpose beyond direct patient care and billing — including patient outreach, marketing, research, and quality benchmarking.
Harini’s hospital had good intentions. However, the DPDP Act governs outcomes, not intentions. Unlawful processing remains unlawful even when it is well-meaning.
The compliance deadline is 13 May 2027. Health data analytics is high-risk processing. Its governance must match that risk.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
