A single patient episode generates consent records across hospital, diagnostic lab, insurance TPA, and specialist — none linked, none auditable together. Under DPDPA, every party in this chain is independently accountable.
The 4-party consent chain in one patient episode
Follow a single patient through a routine cardiac workup in a Tier 1 Indian city and count the consent events:
- Hospital registration — paper form, filed in admin
- Diagnostic lab (SRL, Metropolis, or Dr. Lal Pathlabs) — separate collection consent
- Insurance TPA — data access during pre-authorisation
- Cardiologist's EMR system — referral and report sharing
Four organisations. Four separate data flows. One original consent — collected at hospital registration — which none of the downstream entities can retrieve.
Who is the Data Fiduciary in this chain
Under DPDPA, every entity that independently determines the purpose and means of processing is a Data Fiduciary. The hospital is a Data Fiduciary. The diagnostic lab is a Data Fiduciary for its own processing. The TPA is a Data Fiduciary for insurance data processing. Each is separately accountable — and each must be able to demonstrate valid consent for their specific processing purpose. The hospital's registration form does not cover the lab's obligations.
Purpose-specific consent at the lab level
Did the patient explicitly consent to their biological sample and associated demographic data being processed by the specific diagnostic chain? Or did they only consent to "hospital services"? Under DPDPA, "hospital services" is not a purpose-specific consent that covers third-party lab processing — and the Data Protection Board will ask the lab, not the hospital, to produce its consent record.
TPA data access — which consent covers it
When the insurance TPA accessed the diagnostic report for pre-authorisation, under which consent event does that access fall? "The patient filed a claim" is not a DPDPA-valid consent basis for PHI access. The TPA must be able to show a purpose-tagged, timestamped consent record that specifically covers insurance pre-authorisation data access — or the access is a violation.
Cross-entity withdrawal propagation gap
If the patient withdraws consent from the hospital, does that withdrawal reach the diagnostic lab, the TPA, and the specialist's EMR system? In almost every Indian healthcare chain today, it does not. Withdrawal lives in the originating system and propagates nowhere. Under DPDPA, incomplete propagation is the Data Fiduciary's violation — not the patient's problem.
How Consentica solves the multi-entity chain
Consentica by OpenBlockAI provides a multi-entity consent architecture for healthcare chains: QR-based consent at hospital registration that is purpose-tagged for each downstream entity, a shared consent record that each party can retrieve and audit independently, withdrawal signals that propagate across the integrated chain, and an audit trail that each Data Fiduciary can present separately for their own regulatory examination.
The diagnostic lab that cannot produce a consent record for a patient's data will not be shielded by pointing to the hospital. Under DPDPA, each Data Fiduciary answers independently.