Digital Trust · DPDP for HealthTech

DPDP for healthtech: every record is sensitive, every partner is a processor.

For founders, CTOs, CISOs and compliance leads at telemedicine, e-pharmacy, diagnostics, wellness and health-records platforms. You sit between patients, doctors, labs, pharmacies, insurers and the national health data ecosystem — and DPDP makes you accountable for what each of them does with the data you route.

Health records consentABDM interoperabilityDoctors & labs as processorsMinors & dependantsPrivacy by design
Where this starts

What healthtech teams usually discover in week one.

The privacy policy exists. The gaps are operational: what was collected under which consent, who it went to, and whether anyone can prove it. If three or more of these apply, a scoped gap assessment is the right first step.

Regulators & rule-sets in play
National health data ecosystem (ABDM)Clinical establishment rules (state)Drugs & pharmacy rules (for e-pharmacy)CERT-InData Protection Board

Sound familiar?

  • Patients accept one consent at sign-up that covers consultations, lab sharing, pharmacy fulfilment, insurer claims and wellness marketing.
  • Doctors on the platform keep patient details on personal devices and messaging apps.
  • Family profiles let one user add dependants — including minors — with no separate consent path.
  • Lab and pharmacy partners receive orders with full patient identity where a token would do.
  • Health data is used to train recommendation or triage models with no notice about that purpose.
  • You expose records to insurers or employers for claims or wellness programmes on request, without a documented basis.
Personal data in scope

The data a HealthTech organisation actually holds.

A DPDP programme starts with an honest inventory. These are the categories we typically find across healthtech systems — each needs a purpose, a basis, an owner and a retention period.

  • Consultation notes and prescriptions
  • Lab results and imaging
  • Medication and order history
  • Wearable and lifestyle data
  • Family and dependant profiles
  • Insurance and payment details
Hospital reception corridor representing digital health platforms that connect patients, doctors and labs
How the Act applies

DPDP obligations, translated for HealthTech.

The Act is sector-neutral. Its impact is not. These are the obligations that carry the most weight for your workflows.

01

Purpose-specific consent for each health flow

Consultation, diagnostics, pharmacy, insurance sharing, research and marketing are distinct purposes. Bundling them defeats the “specific and informed” standard.

02

Role clarity: fiduciary or processor

A doctor treating a patient is usually a fiduciary; a lab processing your order may be a processor. Your platform is often both. Contracts and notices must reflect the actual role.

03

Verifiable parental consent for minors

Dependant profiles for children require verifiable consent of a parent or guardian, and no tracking or targeted advertising directed at children.

04

Security proportionate to sensitivity

Health data requires encryption, tokenised sharing where possible, access logging and rapid revocation for doctors and partners who leave the platform.

05

Interoperability with consent

Sharing through national health data rails or with other providers must be driven by the patient’s consent and recorded as such.

We keep legal specifics general on this page. Section-level analysis, penalty exposure and interpretation are worked through with your counsel during the engagement.

The hard part

Clinical record-keeping versus erasure — and the role question underneath it.

Clinicians and establishments are required to maintain medical records for defined periods. A patient’s erasure request under DPDP therefore lands differently depending on who holds which record and in what role. Resolving it means mapping roles first, then retention.

How we resolve it

  • A role map for every data flow: platform, doctor, lab, pharmacy, insurer — fiduciary or processor, and under which contract.
  • Clinical records held under a record-keeping duty tagged as statutory retention with the applicable rule recorded.
  • Platform-side derivatives — recommendations, wellness profiles, marketing segments — erased on withdrawal.
  • Erasure responses that explain what the treating clinician retains and what the platform has deleted.
In your workflows

Where consent, notice and rights actually show up.

Sign-up & dependants

Layered notice; per-purpose consents; verifiable parental consent path for minors; consent versioning.

Consultation & prescription

Doctor onboarding with role and device terms; access scoped to active cases; records shared by consent event.

Labs, pharmacy & insurers

Tokenised orders where identity is not needed; processor contracts with deletion terms; per-partner data register.

Models & analytics

Training and analytics uses declared in notice; de-identification standards; AI systems registered with governance status.

Want to know which of these is your biggest gap? The free assessment takes about ten minutes and scores seven compliance areas.

Run the Gap Assessment
Typical starting points

Three ways HealthTech clients begin.

Scoped, time-boxed and designed to produce evidence early — so the board and the regulator see progress inside the first month.

First engagements

  • Role-and-flow mapping for the patient journey (platform, doctors, labs, pharmacy, insurers) in two weeks
  • Consent redesign with per-purpose toggles and a verifiable parental-consent path
  • Processor-contract remediation for labs, pharmacies and clinicians with a register in Avisha Trust
How the programme runs

From gap assessment to continuous readiness.

1

Week 1–2 · Gap assessment

Data inventory, consent and notice review, vendor and rights-process review, breach readiness. Prioritised findings.

2

Week 3–6 · Remediation sprint

Notice and consent redesign, retention-vs-erasure matrix, vendor contract terms, breach playbook — highest-risk gaps first.

3

Week 7–12 · Operations

Rights-request workflow, consent logging and evidence store live in Avisha Trust; teams trained; first evidence pack produced.

4

Ongoing · Monitoring

Quarterly reviews, vendor re-assessment, AI-usage tracking and readiness reporting to the board.

Built for the Indian regulatory stack

We reconcile DPDP with the sector rules that already bind you, instead of importing a foreign template.

Security and compliance from one team

“Reasonable security safeguards” are tested by the people who run VAPT and incident response, not only described in policy.

Evidence, continuously

Avisha Trust captures consent, rights requests and attestations so the answer to “show me” is an export, not a project.

FAQ

DPDP for HealthTech: questions we hear most

DPDP does not define special categories the way GDPR does, but security safeguards must be reasonable for the sensitivity of the data, and health data is about as sensitive as personal data gets. Regulators and the Board will judge encryption, access control and minimisation accordingly.
Only where the purpose was notified and, if consent-based, consented to — and with de-identification wherever the model does not need identity. We register each model in an AI inventory with its data lineage, which also feeds your AI governance obligations.
Treat dependant profiles for minors as a separate flow with verifiable parental consent, no behavioural tracking and no targeted advertising. We design the account model so this is enforced by the system rather than by policy.
Often yes, because they act as fiduciaries for their patients. Your platform’s terms, onboarding and tooling should make it easy for them to comply — scoped access, no local copies, clear retention — because their failures become your reputational and contractual problem.
Related sectors

DPDP looks different next door.

Start with your sector’s pressure point.

Request a scoped HealthTech DPDP assessment, or run the free gap assessment first.