The Consent Manager Milestone Lands Inside Your Group Mediclaim Data Chain

A group mediclaim programme looks like an insurance contract and behaves like a data pipeline. The employer builds the member file from its HR master: employee code, name, date of birth, gender, grade, location, and for each dependant a name, a date of birth and a relationship. That file goes to the broker, who cleans it and loads it for placement. The insurer receives it for rating and policy issuance. The TPA receives it to build the e-card and adjudication database. The hospital receives a subset at the cashless desk. Diagnosis codes, discharge summaries, investigation reports and bills then travel back up the same chain to settle the claim.

Five parties, two directions, and health data at almost every hop. Most Indian corporate programmes have never documented that flow as a data-processing arrangement. The employer treats the transfer as an incident of employment. The broker treats it as servicing. The insurer treats it as underwriting. The TPA treats it as its mandate. None of that is a consent record, and none of it survives contact with the Digital Personal Data Protection framework as written.

The reason this now needs attention is calendar, not theory. India's DPDP framework commences in three phases: 13 November 2025, 13 November 2026 and 13 May 2027. The middle date is the one that touches consent architecture directly, and it is close enough that design decisions taken this renewal season will still be in force when it passes.

The Consent Manager framework under Rule 4 becomes operational on 13 November 2026. A consent manager is a registered, accountable entity through which a data principal gives, reviews, manages and withdraws consent across the fiduciaries that hold their data, from a single interface rather than from a dozen separate ones.

What this does not mean is that every group mediclaim consent must run through a consent manager from that date. What it means is that the mechanism exists, is registrable, and becomes part of the ecosystem an insurance data chain has to be able to interoperate with. The obligation that follows is architectural: if a data principal chooses to manage consent through a registered consent manager, the fiduciaries holding their data need to be able to receive, honour and act on that record, including a withdrawal.

Full substantive compliance covering notice, consent, security safeguards, breach reporting and data-principal rights is due by 13 May 2027. So the November 2026 date is the point at which consent stops being an abstraction with an eighteen-month horizon and starts being an interface with a live counterparty on the other side of it.

The sequencing matters more than the individual dates. Consent architecture designed only against the May 2027 deadline tends to be built as an internal control. Consent architecture designed against November 2026 has to be built as something an external registered entity can talk to, which is a materially different specification, and retrofitting the second onto the first is the expensive path.

Ask a corporate HR team today on what basis it shares an employee's date of birth and dependant details with a broker and an insurer, and the answer is usually some version of "it is part of the benefit, the employee joined the scheme". That reasoning has commercial sense behind it. The employee is enrolled in a benefit they receive, and the data transfer is what makes the benefit function.

The difficulty is that the reasoning was never written down as a lawful basis, never presented to the employee as a notice, and never separated by purpose. A single act of joining is being asked to carry underwriting, claims adjudication, wellness vendor onboarding, analytics on utilisation, and often a broker's own benchmarking database. Those are distinct purposes with distinct parties, and consent that is specific and informed does not stretch across all of them by implication.

The places this shows up most sharply in group health:

• Wellness and screening vendors. Health-risk assessments, annual master health check-ups and biometric screening usually sit with a separate vendor engaged by the employer, receiving identified health data on a flow that the mediclaim consent, if any, never described.
• Utilisation analytics. Claims data returned to the employer for renewal negotiation is frequently shared at a level of granularity that is not genuinely anonymised, particularly in a scheme of a few hundred lives where a single high-value claim identifies itself.
• Broker benchmarking. Aggregated client claims data used to build market benchmarks is a purpose of the broker's own, not the employer's, which makes the broker a fiduciary for it rather than a processor.
• Continuation and portability. Data retained after an employee exits, so a retiral or portability offer can be made, is a fresh purpose that the original enrolment did not cover.

A large share of the lives on a typical Indian corporate mediclaim policy are not employees at all. They are spouses, children and, on schemes that still cover them, parents and parents-in-law. Every structural assumption that makes the employee flow defensible fails for them.

A dependant has no employment relationship with the employer. They did not join the scheme, sign an offer letter or accept a benefits handbook. Their data reaches the employer through the employee, who supplied it. Their health data reaches the TPA and the hospital in exactly the same way an employee's does, and it is the same category of sensitive data. Parents in the older age bands typically generate the highest claim frequency and the most detailed medical records on the scheme.

Children add a further layer, because the framework treats a child's data as requiring verifiable parental consent rather than ordinary consent, and a paediatric admission produces a full clinical record moving through the chain.

The operational implication is that enrolment cannot stay a single-actor event. The employee entering dependant details into the HR portal is, in framework terms, one person supplying another person's health-relevant data to a chain of fiduciaries. Fixing this properly means the enrolment journey has to capture something from or on behalf of the dependant, and has to carry a notice that reaches them. The workable pattern is a recorded declaration by the employee for adult dependants and a verifiable parental route for children, and very few corporate enrolment journeys are built that way today.

The framework allocates obligations to whoever determines the purpose and means of processing. That entity is the Data Fiduciary and carries the notice, consent, security, breach and rights obligations. An entity processing on a fiduciary's instructions is a Data Processor. Group mediclaim gets this wrong more often than any other line, because everyone in the chain assumes someone else is the accountable party.

1. The employer is a Data Fiduciary for the HR master and for its decision to enrol members, define eligibility and share the file. It cannot delegate this by pointing at the insurer.
2. The broker is a Data Fiduciary for its own purposes: advice, placement, servicing records, and any benchmarking or analytics it runs on client data. It may simultaneously act as a processor for the employer on file handling. The dual role is normal and has to be written down. The DPDP Act 2023 obligations that apply to insurance brokers set out where that line falls.
3. The insurer is a Data Fiduciary for underwriting, rating, policy issuance and claims decisions on the data it receives.
4. The TPA is the ambiguous one. It processes on the insurer's mandate for adjudication, which reads as processor, but it also determines means for its own network management, provider empanelment, fraud screening and retained claims history, which reads as fiduciary. Most TPA relationships in the market have no document that resolves this.
5. The hospital is a Data Fiduciary in its own right for the clinical record it creates, and a recipient of member data for eligibility verification at the cashless desk.

The practical consequence is that a group mediclaim policy needs a data-processing schedule between employer and broker, between broker and insurer where the broker handles data on either party's behalf, and between insurer and TPA. A TPA selection exercise that scores turnaround time and network size without scoring the data-protection posture is now scoring the wrong things.

The consent manager framework exists to make consent manageable, and the part that matters most operationally is the part that gets least attention: withdrawal has to be as easy as giving consent, and it has to propagate.

Consider what happens when a covered spouse withdraws consent for their health data to be processed by a wellness vendor engaged by their partner's employer. The vendor has to stop. The employer has to stop supplying. If the withdrawal is delivered through a registered consent manager rather than through a form on the employer's intranet, the employer, the broker and the vendor each need a way to receive it. None of that is exotic, but none of it is built in a typical corporate benefits stack today.

The harder version is a withdrawal that touches the insurance contract itself. A member who withdraws consent for claims adjudication cannot be adjudicated, which in practice means they cannot claim. This is why purpose separation is not administrative tidiness. If enrolment, adjudication, wellness and analytics are captured as one undifferentiated block, a withdrawal aimed at wellness reads as a withdrawal from everything, and the scheme administrator has no defensible way to keep the claim path open while shutting the analytics path.

The full obligation set is due by 13 May 2027, and the consent interface has to be workable from 13 November 2026. Working backwards from those two dates gives a sequence rather than a scramble.

1. Map the flow first. Write down every hop in the chain, the fields that move at each hop, the purpose, and the receiving party. Most employers discover two or three flows they had forgotten, usually a wellness vendor and an EAP provider.
2. Assign roles. Decide, in writing and with the counterparty, who is fiduciary and who is processor at each hop. Where a TPA or broker sits in both roles, split the description by activity.
3. Rebuild enrolment. Purpose-separated notice, severable consent, a dependant path that reaches adult dependants and a verifiable parental route for children. This is the longest item and the one that needs to be live for the November renewal cycle rather than the May deadline.
4. Fix the contracts. Data-processing schedules with instructions, security obligations, breach-notification flow-down, retention limits and deletion on exit, in the employer-broker, insurer-TPA and employer-vendor agreements.
5. Set retention. Group health data has legitimate long-tail retention through claims run-off and regulatory record-keeping. A defensible schedule maps each category to its basis and triggers deletion when none remains.
6. Wire withdrawal and rights. A workflow that can find one member's data across HR, broker, insurer, TPA and vendor systems, and act on it inside a defined turnaround.

On the insurance side, the read-through is to cyber and professional indemnity. An employer holding the health data of several thousand lives is a data-rich target whose exposure is not limited to its own systems, and a broker or TPA that mishandles a group health file faces a professional-indemnity allegation from the client alongside any regulatory consequence. Both belong in the same review as the compliance work, because the phased DPDP compliance timeline changes the risk profile the policy wording is being asked to respond to.

Doing that well means reading what each cyber and professional-indemnity wording actually grants against where the group health data chain puts the real exposure, which is wording work rather than premium comparison. Sarvada gives commercial insurance brokers and corporate risk teams structured, searchable access to insurer policy wordings, so cover can be matched to a data-protection profile that the DPDP phases are reshaping. Request Access to bring that precision to your group health conversations.