A founder building a clinical AI product in India in 2026 receives, on a regular basis, a question from hospital procurement teams that did not exist five years ago: “How are you handling DPDP compliance — and where do you stand on DISHA?” The expected answer is no longer “we encrypt data at rest” or “we are HIPAA-aligned.” Both of those are now table stakes, and neither addresses the actual Indian regulatory landscape.

The truth is that healthcare AI in India is governed by an evolving combination of frameworks, of which the DPDP Act is the operational regulation and DISHA is the proposed sector-specific overlay. They are not interchangeable. They overlap on some questions and diverge on others. Founders, hospital IT leaders, and clinicians who confuse them produce procurement documents that are either over-engineered or, more often, miss the questions that matter.

This article is a practical side-by-side breakdown of DISHA and DPDP as they apply to healthcare AI builders in 2026, with concrete guidance on what to implement now and what to monitor as both frameworks evolve.

Side-by-side comparison of DISHA and DPDP Act for healthcare AI: scope (sector-specific vs general), consent model, data subject rights, cross-border data flow, breach notification, penalties, and enforcement authority.
DISHA and DPDP compared on the dimensions that matter most to healthcare AI builders

What Each Framework Actually Is

The two are not parallel laws of the same kind. Their nature is different and that shapes how to think about compliance.

The Digital Personal Data Protection Act (DPDP) is the cross-sector data protection law passed in 2023 and progressively coming into operational force. It applies to all processing of personal data of Indian data principals, including health data. It is the law currently in effect and the regulation under which healthcare AI builders operate today. Implementation rules and the formal Data Protection Board have been progressively rolling out, with substantive operational compliance expected in 2025–2026.

The Digital Information Security in Healthcare Act (DISHA) is a proposed sector-specific health data law that has been under discussion in various forms since 2017. It has not yet been enacted. The current expectation in 2026 is that DISHA — or its successor — will eventually formalise the healthcare-specific layer that DPDP does not address explicitly. Until enacted, DISHA’s specific provisions are not binding, but the direction of travel they signal is informative for builders planning multi-year deployments.

The implication: in 2026, DPDP compliance is operational and required. DISHA is anticipatory — useful for understanding where regulation is heading, not yet a procurement gate.

DPDP: What Healthcare AI Builders Must Do Now

DPDP applies to any processing of personal data, which includes health data, and which includes data routed through AI tools. Six operational requirements matter most for healthcare AI builders:

Lawful basis for processing. Most healthcare data processing happens under the “consent” basis, with limited exceptions for legitimate uses. Consent must be specific, informed, and revocable. Generic “patient agrees to data use” clauses no longer meet the bar.

Notice and consent design. When patient data flows from a hospital to an AI tool, the patient must be informed and consent must be obtained in a manner consistent with DPDP requirements — purposes specific, language accessible, mechanism to withdraw clearly available.

Data minimisation. Process only what is needed for the specified purpose. AI vendors who default to “give us everything you have” face structural compliance problems. The shift is toward minimal-data architectures where the AI tool processes the smallest viable data set.

Data subject rights. Patients have the right to access, correction, erasure, and grievance redress regarding their data. AI vendors must build mechanisms — directly or through hospital partners — to honour these rights. Erasure, in particular, can be operationally complex if the data has been used in model training.

Cross-border data transfers. DPDP introduces controls on where data can be transferred. Cloud-hosted AI tools with foreign data residency face additional compliance questions. Many Indian-deployed AI tools are moving to in-country data hosting partly for this reason.

Breach notification. Personal data breaches must be reported to the Data Protection Board and affected individuals within prescribed timeframes. AI tools that process clinical data must have incident response procedures that meet these requirements.

Penalties. DPDP penalties scale by severity and can reach significant amounts — up to ₹250 crore for serious breaches. Healthcare data, given its sensitivity, sits in the high-penalty tier.

What DISHA Would Add (If Enacted in Its Discussed Form)

DISHA, in the forms discussed publicly over the past several years, would layer healthcare-specific provisions on top of general data protection. Key additions that founders should anticipate:

Healthcare-specific definitions of sensitive data. DISHA’s discussed framing treats health data as a specially protected category with stricter consent and processing requirements than general personal data.

Sectoral consent architecture. Specific consent mechanisms for healthcare contexts, potentially integrated with the ABDM consent layer for digitally-routed clinical data.

Healthcare-specific data subject rights. Stronger rights over health records, including portability between providers, structured access for research uses, and specific provisions for minor and incapacitated patients.

Healthcare-specific accountability. Designated data protection officers for healthcare providers and data processors above certain thresholds.

Healthcare-specific breach severity. Stricter notification timelines and penalty tiers for breaches involving health data.

Builders should not over-engineer for DISHA in its proposed form — the final version, if enacted, will differ. But architectural decisions made now (cloud architecture, consent mechanism design, data residency choices) should anticipate sectoral-overlay regulation rather than only general data protection.

The ABDM Connection

ABDM is not a data protection law, but it shapes how DPDP and any future DISHA apply in practice. ABDM provides the consent management infrastructure (the HIE-CM), the identity layer (ABHA), and the data exchange protocols that increasingly route healthcare data flows in India. Healthcare AI tools that integrate with ABDM inherit a substantial portion of consent and data handling compliance through the ABDM framework itself.

For builders, this creates a practical strategic question: build ABDM integration early, accepting the integration effort but inheriting compliance scaffolding, or build outside ABDM, retaining flexibility but assuming the full consent and data handling burden directly.

The 2026 answer for most clinical AI builders is to plan ABDM integration as a forward-looking architectural choice even if not required today. As DPDP enforcement matures and DISHA-style sectoral regulation arrives, ABDM-integrated tools will face fewer compliance retrofits than tools that built consent and data handling ad hoc.

Compliance checklist for healthcare AI builders covering DPDP-required elements (lawful basis, notice and consent, data minimisation, subject rights, cross-border controls, breach notification) and DISHA-anticipated overlays (sectoral consent, healthcare data subject rights, ABDM integration, accountability roles).
What healthcare AI builders need to implement now (DPDP) and what to architect for (DISHA-anticipated overlays)

A Practical Compliance Roadmap for 2026

For a healthcare AI builder approaching DPDP and DISHA seriously, the operational priorities for 2026 are clear:

Immediate (next 90 days):

  • Audit current data handling against DPDP requirements: lawful basis, notice and consent design, data subject rights mechanisms, breach notification procedures
  • Document data flows end-to-end: what data enters the system, where it is processed, who has access, where it is stored, how long it is retained
  • Update standard vendor contracts with hospital partners to cover DPDP-specific provisions, including data processing roles and breach notification obligations

Short-term (next 6 months):

  • Establish in-country data residency for production processing where not already in place
  • Build patient-facing mechanisms for access, correction, and erasure requests — directly or through clear coordination with hospital partners
  • Designate accountability roles: data protection officer or equivalent

Medium-term (next 12–18 months):

  • Plan ABDM integration as a forward-looking compliance and commercial choice
  • Architect for sectoral overlay regulation: data minimisation, granular consent, healthcare-specific data handling
  • Monitor DISHA development and DPDP implementation rules — both are evolving

The builders who treat DPDP as a compliance checkbox produce one kind of architecture. The builders who treat it as the foundational layer of a multi-year sectoral regulatory environment produce a different and more durable one. The second approach costs more in 2026 and saves substantially over the next five years.

Further Reading

Authoritative references

Related perspectives from MedAI Collective

If your team is preparing a DPDP compliance roadmap or anticipating DISHA-style sectoral regulation in your healthcare AI architecture, MedAI Collective Consulting works with healthtech founders and hospital teams on compliance strategy and ABDM integration planning.