Healthcare technology law in India — where clinical risk, data privacy, and software regulation all apply at once.

Likely yes, if it independently performs a medical function such as analysing medical images or supporting a diagnosis. Under CDSCO's Software as a Medical Device framework, standalone software of this kind is classified into four risk-based classes, A through D, based on its intended use and clinical impact. Classification is determined by what the software is validated to do, not by its underlying technical architecture — an AI tool and a simpler rules-based tool performing the same clinical function can fall into the same class.

Not universally, but it is increasingly mandatory for providers connected to government schemes such as AB-PMJAY empanelled hospitals, and strongly encouraged across the sector more broadly. With several hundred million ABHA health IDs already issued, ABDM integration is becoming a practical expectation for interoperability even where it is not yet a strict legal requirement for a given platform type.

The DPDP Act does not currently create a separate statutory category with heightened obligations purely for health data in the way GDPR treats special category data, but health data's sensitivity in practice drives stricter consent, security, and breach-notification expectations from both the Data Protection Board and sector-specific frameworks like the ABDM Health Data Management Policy, which independently mandates security and privacy by design for participants in the ABDM ecosystem.

Only if you process data for US-based patients, US covered entities, or US business associates as part of your operations. Indian healthtech companies serving purely domestic patients are governed by the DPDP Act and sector rules, not HIPAA — but any company with a US-facing product line, US clinical partners, or US data processing agreements should assess HIPAA exposure separately rather than assuming DPDP compliance covers it.

It can trigger a genuine reclassification event. Even minor changes to labelling, promotional materials, or instructions for use can move a product from a lower to a higher risk class if the new language suggests diagnostic or life-supporting functionality — meaning marketing copy, app store descriptions, and onboarding flows all carry real regulatory weight and should be reviewed alongside the underlying software, not treated as a separate workstream.

A product classification review to establish SaMD status and likely risk class, a regulatory map across CDSCO, NMC, ABDM, and DPDP, and documentation support for whichever filings and consent architecture your specific product requires — with cyber risk assessment built into the same engagement rather than run as a separate, uncoordinated exercise.