Indian diagnostic centres now operate under two overlapping frameworks. The Ayushman Bharat Digital Mission governs how health records are shared and linked, through ABHA identifiers and a consent-based architecture. The Digital Personal Data Protection Act governs the personal data itself, treating healthcare providers as data fiduciaries with explicit consent obligations. ABDM shapes how you share reports. DPDP shapes what you must be able to prove about that sharing.
Most centres encounter these separately, usually through a software vendor mentioning one or the other. Read together they point in a consistent direction: patient reports are moving to digital, consented, patient-controlled delivery, and the operational burden of that shift falls on the centre producing the report.
What ABDM asks of a diagnostic centre
Under ABDM, the ABHA number is a unique digital health identifier that lets an individual build and control a longitudinal health record across providers. Facilities register through the Health Facility Registry, and labs participating through ABDM-enabled systems can offer ABHA-based registration and issue ABHA-linked reports. The architecture is consent-based: the patient authorises access rather than the provider deciding what to release.
For a diagnostic centre the practical consequences are modest but real. Reports become linkable records rather than one-off PDFs. Patients accumulate history across providers, which means your report will be read alongside others, sometimes years later, by people with no context for your house conventions. And the delivery relationship shifts further towards the patient and away from the referring clinician.
What the DPDP Act changes
The Digital Personal Data Protection Act, 2023 is India's first comprehensive statute on digital personal data. The Digital Personal Data Protection Rules were notified on 13 November 2025, operationalising it. Two points matter most for diagnostic centres.
First, healthcare providers are data fiduciaries and must process digital personal data accordingly. Notably, the Act does not create a separate category for health data, so patient reports sit under the general framework rather than a bespoke health regime. Second, the framework is built on notice and consent. Consent must be specific and revocable, generic or blanket consent is not sufficient, and the notice given must present a fair account of what is being processed.
| Obligation | What it means for a diagnostic centre |
|---|---|
| You are a data fiduciary | Accountability for patient data sits with you, including for what your vendors do with it |
| Specific, revocable consent | A single consent at registration covering everything is not sufficient. Purpose must be identifiable and withdrawal must be possible |
| Clear notice | Patients must receive an understandable account of what is processed and why, not dense legal text |
| Significant data fiduciary duties | Larger organisations may need a data protection officer, continuous auditing and reporting |
| Phased rollout | Obligations arrive in stages, with full compliance expected by 13 May 2027 |
Where the two frameworks meet: report delivery
Most Indian centres already deliver reports by WhatsApp, email or an app, often within hours. That practice predates both frameworks and is not made unlawful by either, but it does now sit inside a consent and accountability regime that expects you to know what you sent, to whom, on what basis, and to be able to stop on request. It also intersects with the wider communication gap: faster, more direct, more consented delivery still leaves the patient holding a document written for a clinician.
Compliance and comprehension are separate problems, and solving the first does not touch the second. A perfectly consented, ABHA-linked, auditable report is still unreadable to most of the people receiving it.
Consent frameworks decide whether a patient is allowed to see their report. They say nothing about whether the patient can understand it.
What to ask any vendor handling report data
- Where is the data stored and processed, and for how long is it retained?
- Who are your sub-processors, and can you list them? As data fiduciary, their handling is still your accountability.
- What happens on withdrawal of consent, technically and within what timeframe?
- Is patient data used to train models, and can that be contractually excluded?
- Can you produce an audit trail of what was generated and delivered for a given patient?
A practical starting point
Three steps that are useful regardless of how the detail settles. Map what patient data you currently hold, where it goes, and which vendors touch it, since most centres have never written this down. Review your consent language against the specific-and-revocable standard rather than assuming a registration form covers it. And name an accountable person now, because every subsequent decision needs an owner.
