On this page · 11 sections
- Two regulators, one data flow
- How CDSCO classifies clinical AI software
- The Algorithm Change Protocol: governing a model that learns
- DPDP duties for health data
- The ABDM layer your architecture should speak
- The data-architecture playbook
- The wider governance map
- Common architecture mistakes
- FAQ
- How eCorpIT can help
- References
Summary. Deploying clinical AI in India now means answering to two regulators at once. CDSCO regulates the model as a medical device, and on 21 October 2025 it issued draft guidance on Medical Device Software that puts AI diagnostic and decision-support tools in the higher risk classes, C and D. The DPDP Rules, 2025, notified on 14 November 2025, govern the patient data, with the core obligations effective 13 May 2027 and breach penalties reaching ₹250 crore. Underneath both sits the Ayushman Bharat Digital Mission, which had created 84.79 crore ABHA health IDs and linked 82.69 crore health records by January 2026 on a FHIR-based, consent-driven exchange. For a hospital CTO or health-tech founder, the data architecture is where these three forces meet. Get the consent flow, de-identification, residency and audit trail right and you can ship; get them wrong and you fail an audit or trigger a penalty. This playbook maps the rules to a concrete architecture.
Clinical AI in India is past the pilot stage. AI is screening for tuberculosis, cancer and eye disease, and telemedicine platforms like eSanjeevani run at national scale. What changed in late 2025 is that the regulatory scaffolding caught up. The question is no longer whether you can build a diagnostic model; it is whether your data architecture can satisfy CDSCO, the DPDP regime and the ABDM ecosystem at the same time.
Two regulators, one data flow
The single most useful mental model is to separate the model from the data. CDSCO cares about the software as a device: is it safe, validated and properly classified. DPDP cares about the personal data the software touches: was there consent, is the purpose limited, is it retained only as long as allowed. They are different gates, and your architecture has to pass both.
| Dimension | CDSCO (the device) | DPDP (the data) |
|---|---|---|
| Governs | The AI software as a medical device | Personal and health data processed |
| Instrument | Medical Device Rules 2017, MDSW draft guidance | DPDP Act 2023, DPDP Rules 2025 |
| Key trigger | Diagnostic or decision-support purpose | Any processing of personal data |
| Core duty | Risk classification, validation, change control | Consent, purpose limitation, breach notice |
| Deadline | MDSW guidance finalising from the Oct 2025 draft | Core obligations from 13 May 2027 |
Abhishek Singh, additional secretary at MeitY and chief executive of the IndiaAI Mission, framed how the data law binds clinical AI: the DPDP Act applies to AI models by requiring no sharing of personal health data without consent, no processing beyond the purpose it was given for, and no retention beyond the approved duration. That is the data half of the contract. CDSCO governs the other half.
How CDSCO classifies clinical AI software
CDSCO regulates Software as a Medical Device under the Medical Device Rules, 2017. SaMD is standalone software with a medical purpose, which covers AI radiology, computer-aided detection and clinical decision-support apps. Classification is risk-based and turns on two questions: how significant is the information the software provides, and how serious is the healthcare situation it addresses.
| Class | Risk | Typical clinical AI example | Licensing authority |
|---|---|---|---|
| A | Low | Wellness or administrative support tools | State Licensing Authority |
| B | Low-moderate | Triage support in non-serious settings | State Licensing Authority |
| C | Moderate-high | Decision support in serious conditions | CDSCO (central) |
| D | High | Diagnosis or treatment guidance in critical care | CDSCO (central) |
Per analysis of the rules, AI and machine-learning diagnostic or decision-support tools usually land in Class C or D, which means central CDSCO licensing and the most stringent validation. The practical lesson is to classify early, because a Class C or D pathway shapes your evidence generation, your documentation and your timeline from the first sprint.
The Algorithm Change Protocol: governing a model that learns
The hardest problem with clinical AI is that the model changes. A device approved on Monday is a different device after retraining on Friday. CDSCO's October 2025 draft guidance addresses this with an Algorithm Change Protocol: manufacturers must specify in advance how updates and retraining will be managed, document model retraining and update triggers, and track performance drift over time. This lets you iterate without re-licensing from scratch, but only if the change-control plan is defined up front.
Industry pushed for proportionality. Nasscom recommended that CDSCO distinguish significant clinical modifications from routine, low-risk updates, recognise a "line-extension" category for approved software, and exempt minor changes such as bug fixes, cybersecurity patches and interface refinements from formal reporting. It also asked for IMDRF-aligned classification and documentation that is practical and proportionate to risk. For your architecture, the takeaway is to build model versioning, drift monitoring and an auditable change log as first-class components, not afterthoughts.
DPDP duties for health data
Health data is among the most sensitive categories under DPDP, and the DPDP Rules, 2025 set the obligations a clinical AI system must meet: collect data only with clear, itemised consent; process it only for the stated purpose; retain it only as long as needed; and notify the Data Protection Board and patients of a breach. The penalty for failing to take reasonable security safeguards that leads to a breach reaches ₹250 crore under the Act's schedule. Where the patient is a child under 18, verifiable parental consent applies, and large processors designated as Significant Data Fiduciaries owe an annual data-protection impact assessment and independent audit. The same consent and purpose-limitation engine we describe for India's DPDP consent manager framework applies directly to hospital and health-tech data flows.
The ABDM layer your architecture should speak
You are not building on a blank slate. The Ayushman Bharat Digital Mission, launched on 27 September 2021, is India's national digital-health infrastructure, and integrating with it is increasingly the path of least resistance for interoperable records and consent.
| ABDM building block | What it is | Architecture role |
|---|---|---|
| ABHA | Ayushman Bharat Health Account, a unique health ID | Patient identity reconciliation |
| Healthcare Professionals Registry | Verified clinician directory | Clinician identity and access |
| Health Facility Registry | Registry of health facilities | Facility identity and trust |
| Unified Health Interface | Booking and consent layer | Consent capture and discovery |
| Health information exchange | Open-source HIE using FHIR | Standards-based record exchange |
The mission's Health Data Management Policy sets a guiding principle of "Security & Privacy by Design" and a consent-based model in which data moves only after the patient agrees. Before integrating, applications are validated in an ABDM sandbox and pass security audits such as the Web Application Security Audit. Building to FHIR and the ABDM consent model from the start saves a painful retrofit later, and aligns your system with the framework that holds 82.69 crore linked health records.
The data-architecture playbook
Here is how the rules translate into concrete architecture decisions for a clinical AI system.
| Layer | Requirement | How to implement |
|---|---|---|
| Identity | Reconcile patients across visits | Map to ABHA; avoid ad hoc patient keys |
| Consent | Capture and propagate consent | Itemised, purpose-tagged consent that travels with the record |
| De-identification | Strip PHI before model use | Automated de-identification; separate identified and de-identified stores |
| Residency | Keep data where the law expects | India-region storage; document data flows |
| Audit | Prove what touched the data | Immutable logs of access, processing and model version |
| Model governance | Control a model that learns | Versioning, drift monitoring, Algorithm Change Protocol log |
Two architectural choices do most of the work. First, separate the identity plane from the data plane, so models train and infer on de-identified data while consent and identity are reconciled elsewhere through ABHA. Automated de-identification matters because manually stripping protected health information from records is slow and error-prone, and India is building anonymised national health datasets precisely so models can train without raw identifiers. Second, treat consent as a structured artefact that travels with the data and can be withdrawn, mirroring the privacy-first patterns in our privacy-first AI architecture work and the lessons in clinical AI deployment under CDSCO and DPDP.
Privacy-preserving training is the third pillar. Federated learning lets multiple hospitals improve a shared model without moving raw records off-site, which fits both DPDP minimisation and the residency expectations of Indian health data. It is not a silver bullet, but it changes the default from "centralise everything" to "move the model, not the data."
The wider governance map
CDSCO and DPDP are the two hard gates, but they sit inside a broader framework that a complete architecture should map to. The Ministry of Health and Family Welfare has noted that the DPDP Act, the National Health Authority's Health Data Management Policy and the ICMR's Ethical Guidelines for AI in Biomedical Research and Healthcare collectively define consent, purpose limitation, data access and accountability across healthcare actors. The ICMR guidelines set out ten patient-centric ethical principles, among them autonomy, data privacy, accountability and liability, risk minimisation and safety, and non-discrimination and fairness, with the autonomy principle stressing patient consent and clear disclosure of risks.
India is also building tooling and initiatives around this stack. The newer SAHI and BODH initiatives target safe and validated AI use in healthcare, and on 2 April 2026 IndiaAI and CDSCO launched a Health Innovation Acceleration Hackathon whose brief centres on a reliable data-anonymisation tool, a signal that de-identification is treated as core infrastructure, not an afterthought. For an architecture team, the message is that consent, de-identification and accountability are required by several frameworks at once, so building them well satisfies many obligations with one design rather than several bolt-ons.
Common architecture mistakes
The failures repeat. Teams classify the device too late and discover mid-build that a Class C pathway demands evidence they never collected. They bolt consent on as a checkbox instead of a structured, withdrawable artefact, so they cannot honour a withdrawal request. They train on identified data because de-identification was deferred, creating a breach surface that DPDP penalises. And they treat the model as static, with no versioning or drift monitoring, so the Algorithm Change Protocol becomes impossible to satisfy. Each mistake is an architecture decision made too late. The fix is to treat classification, consent, de-identification and model governance as foundations, addressed in the same sprint as the model itself, a theme we expand in healthcare AI deployment mistakes in Indian hospitals.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation with senior-led engineering teams that build compliant clinical AI systems for hospitals and health-tech firms in India. We classify your software against CDSCO risk classes, design DPDP-aligned consent and de-identification flows, integrate with ABDM and FHIR, and stand up the model-versioning and audit infrastructure the Algorithm Change Protocol expects. Founded in 2021 and assessed at CMMI Level 5, we design applications aligned with CDSCO and DPDP requirements rather than retrofitting them. To scope a clinical AI data architecture, contact our team.
References
_Last updated: 26 June 2026._
