Consent management
Compliance, Privacy & Ethicsarticle · 8 मिनट · अपडेट 17 जुल॰ 2026

Consent management

लेखक Rajendra Sharma, RN, CPC, CPBसमीक्षक Rajendra Sharma, RN, CPC, CPB · 17 जुल॰ 2026

Consent is not a signature you collect once. It is a scoped, revocable, time-bound object the system must enforce — and most health systems treat it as a form, which is why it fails.

FHIRDPDPGDPR

In one line

Real consent management means the system cannot do the thing you didn't agree to. If consent is a signature in a filing cabinet and the database will happily serve the data anyway, you have consent theatre — a record of permission, not a mechanism.

The distinction that decides everything

There are two ways to build consent, and they look identical on a compliance checklist:

Consent as a record. You collected a form. It's stored. Somewhere. Access control is separate, and enforcement depends on everyone behaving correctly and remembering the form exists. This is what most health systems have.

Consent as a control. The permission is an object the data flow depends on. No valid consent, no data — not "against policy", but technically impossible. This is what ABDM's HIE-CM built, and it's the reason the Indian architecture is genuinely interesting rather than merely large.

The gap between them is the gap between a promise and a guarantee.

A meaningful consent is not "yes". It answers five questions:

  • Who may see it — this hospital, this insurer, this app.
  • What — prescriptions but not the psychiatric notes; the 2019 admission, not a lifetime.
  • Why — the purpose. Care is not research. Research is not marketing.
  • How long — an expiry, so permission dies without anyone remembering to kill it.
  • Can it be withdrawn — and does withdrawal actually stop the flow?

Compare that with the consent form most patients sign, which in substance says: "yes, forever, to everything, for any purpose, and good luck retrieving it." That document is legally tidy and ethically hollow.

Withdrawal is the honest test

Anyone can build "collect a yes". The test of a consent system is what happens on no.

  • Does revocation stop future access? (Usually yes — this part is easy.)
  • What about the copy already exported to the analytics warehouse? To the vendor's environment? In last night's backup?
  • What about a model already trained on it? You cannot un-train a model. This is a genuinely unsolved problem and the industry mostly avoids saying so.

The uncomfortable rule: the further data travels, the less real your withdrawal is. Which means the strongest consent control isn't the revoke button — it's minimising what you copied in the first place.

Purpose limitation, and where it breaks

The most common violation in health data is not a hacker. It is purpose creep: data collected for care, quietly reused for a quality dashboard, then a research project, then a product feature, then training an algorithm. Each step is individually defensible. Nobody ever decided to do the last thing.

Guard rail: a consent granted for care does not authorise analytics or model training. If you want that, ask for that — separately, specifically. And log against the artefact, so any access can name the permission that allowed it. Under DPDP or GDPR that log is your defence.

Where the models differ

  • GDPR — consent is one of six lawful bases, and often not the best one. Healthcare frequently relies on other bases, because "freely given" is questionable when the alternative is not being treated. Health data is special category, so processing is prohibited by default and permitted only under specific conditions.
  • DPDP (India) — consent-centric, with a statutory Consent Manager as a registered intermediary. And critically: no special category for health data. The extra care must come from your design and sectoral rules, not the Act.
  • HIPAA — largely permits treatment, payment and operations without additional consent, and regulates disclosure instead. A very different shape.

Building it

  • FHIR Consent exists and models scope, purpose and provision. It's a data structure, not an enforcement engine — you still have to make something honour it.
  • Consent must be checked at access time, not cached. A revocation you learn about tomorrow is a breach today.
  • Make refusal usable. If declining is buried, confusing, or degrades care, the consent wasn't freely given — regardless of what the form says.

The sentence to carry: if your system can technically do what the consent forbids, then what you have is a policy, not a control.

संदर्भ

  1. HL7 FHIR R4 — Consent
  2. MeitY — Digital Personal Data Protection Act, 2023
  3. EU — GDPR Article 7: Conditions for consent

संबंधित entries