DPDP alignment
India Digital Health · ABDMarticle · 8 मिनट · अपडेट 17 जुल॰ 2026

DPDP alignment

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

How ABDM's consent architecture lines up with India's Digital Personal Data Protection Act — where they reinforce each other, and the one gap health builders must not assume away.

ABDMDPDP

In one line

India's Digital Personal Data Protection Act (DPDP), 2023 and ABDM were designed in the same intellectual climate and fit together unusually well — but they are not the same instrument, and the difference is where teams get into trouble.

The vocabulary, mapped

DPDP's terms and ABDM's roles line up cleanly enough to be worth memorising together:

DPDP conceptWhat it meansWho that is in ABDM
Data PrincipalThe person the data is aboutThe patient, holding an ABHA
Data FiduciaryDecides why and how data is processedThe hospital / HIP, the HIU
Data ProcessorProcesses on a fiduciary's behalfYour cloud vendor, your HMIS provider
Consent ManagerRegistered intermediary through which consent is given, managed and withdrawnThe HIE-CM

That last row is the striking one. DPDP contains a statutory concept of a consent manager — an accountable intermediary a person uses to grant and withdraw permission. ABDM had already built one for health. The law and the architecture were converging on the same idea.

Where they genuinely reinforce each other

  • Consent must be free, specific, informed and unambiguous under DPDP, for a stated purpose. ABDM's consent artefact is already purpose-bound, time-bound and typed — the technical object is shaped like the legal requirement.
  • Withdrawal must be as easy as granting. ABDM makes revocation a first-class operation that actually stops the flow, rather than a request you email someone.
  • Purpose limitation. The artefact names the purpose; using data beyond it isn't merely non-compliant, it's outside what was technically authorised.

This is a rare and genuinely good situation: the compliant path is the architecturally natural one. Most privacy law fights the systems it governs. Here, doing the ABDM thing properly gets you a long way toward doing the DPDP thing properly.

The gap you must not assume away

Now the part that matters most, and that catches people who learned privacy from GDPR.

DPDP does not create a special category for health data.

Under the EU's GDPR, health data is "special category" — processing is prohibited by default and permitted only under specific conditions, with heightened obligations. Many practitioners carry that assumption into Indian work and expect the law to supply extra protection automatically, simply because the data is clinical.

DPDP's structure is different: it is a general personal data law. Your psychiatric history and your food-delivery address are, in the Act's architecture, personal data of the same class.

Two consequences to internalise:

  1. Do not rely on the statute to notice that health data is sensitive. The heightened care your patients deserve has to come from your design decisions, your sectoral obligations, and ABDM's own rules — not from an assumption that the law has already imposed it.
  2. Sectoral rules do real work here. ABDM's policies, professional obligations and contractual terms carry weight that, in a GDPR jurisdiction, the statute itself would carry.

This is not a claim that Indian patients are unprotected. It is a claim that the source of the protection is different, and that engineers who assume GDPR's shape will misjudge where their obligations actually come from.

Practical guidance for builders

  • Consent artefact ≠ blanket licence. A grant for care does not authorise analytics or model training. If you want that, ask for that.
  • Log against the artefact. For any access, you should be able to name the consent that permitted it and the purpose claimed. That's your audit story, and you'll want it before someone asks.
  • Minimise on the way in. The safest record is the one you didn't collect. DPDP's purpose limitation and ABDM's scoping both push the same way.
  • De-identify for secondary use. Research and product analytics should work from de-identified data as a matter of course — and note that de-identification is a discipline with known failure modes, not a checkbox.
  • Read the rules, not the summaries. Implementation detail under DPDP has continued to evolve since the Act passed in 2023. This entry is orientation, not legal advice; where the answer decides real patient exposure, get counsel who has read the current rules.

The bigger picture

For the enormous body of Indian professionals working on US healthcare data under HIPAA, DPDP is the moment the discipline comes home. The habits — minimum necessary, purpose limitation, audit trails, treating a record as someone's life rather than a row — transfer directly. What changes is the legal frame around them, and the fact that the patient is now your neighbour.

संदर्भ

  1. MeitY — Digital Personal Data Protection Act, 2023
  2. National Health Authority — ABDM
  3. ABDM Sandbox v3 — Developer Documentation

संबंधित entries