On this page · 15 sections
- Step 1: Decide whether your software is a medical device
- Step 2: Find your risk class and the right licence
- Step 3: Set up an Algorithm Change Protocol for your model
- Step 4: Build DPDP-grade consent and data handling
- Step 5: Integrate with ABDM and the wider governance frame
- Step 6: Run post-market surveillance and security
- Sequencing a compliant deployment
- Build a clinical evidence package
- Validation, bias, and clinical safety
- A realistic timeline and budget
- Common compliance gaps
- India market context
- FAQ
- How eCorpIT can help
- References
Summary. India is moving healthcare AI from pilots to regulated deployment. On October 21, 2025, the Central Drugs Standard Control Organisation (CDSCO) released draft guidance on Medical Device Software under the Medical Device Rules 2017, applying a risk-based classification to Software as a Medical Device, including AI radiology and diagnostic tools. Diagnostic or treatment-guiding software in critical settings lands in Class C or D, licensed centrally, with approvals that can run from 30 days at the lowest risk to 240 days at the highest. At the same time, the Digital Personal Data Protection Act 2023 governs patient data with penalties up to ₹250 crore, and the Ayushman Bharat Digital Mission is building a national health-records exchange that an AIIMS-developed clinical decision system will run across hospitals nationwide. Here are six steps to stay CDSCO and DPDP compliant.
The window matters. For two years the question in Indian health AI was whether the models worked; in 2026 it is whether you can deploy them safely inside a real regulatory frame. Two regulators now shape every product: CDSCO for the software as a medical device, and the DPDP authority for the patient data it touches. Treating either as an afterthought is how a working model fails to reach a clinic. The six steps below are the path from a model to a compliant, deployed product. For the privacy-architecture foundation, see our guide to generative AI enterprise strategy.
Step 1: Decide whether your software is a medical device
The first step is classification, because it decides everything after it. Under the CDSCO draft guidance, Software as a Medical Device is standalone software that performs a medical purpose without being embedded in hardware, and it explicitly includes AI-powered radiology tools, computer-aided detection, and apps that monitor or analyse medical conditions, as the CDSCO draft guidance and analyses by Cyril Amarchand Mangaldas set out. If your software informs a clinical decision, assume it is in scope until you can show otherwise.
A wellness app that gives general tips is usually out of scope; a tool that flags a suspected tumour on a scan is firmly in. The honest test is whether a clinician would act on your software's output. If yes, you are building a regulated medical device, and the rest of these steps apply.
Step 2: Find your risk class and the right licence
CDSCO uses a risk-based classification driven by the significance of the information the software provides and the seriousness of the clinical situation it addresses, per Freyr's classification guide. Software that diagnoses or guides treatment in critical scenarios is likely Class C or D. Class A and B are licensed by state authorities, while Class C and D fall under CDSCO's Central Licensing Authority, and approval timelines under the Medical Device Rules range from about 30 to 60 days for Class A up to 120 to 240 days for Class C, with AI and machine-learning products advised to plan for the upper end.
| Class | Risk and clinical role | Licensing and indicative timeline |
|---|---|---|
| Class A | Low risk, informational | State authority, ~30 to 60 days |
| Class B | Low to moderate risk | State authority, ~60 to 120 days |
| Class C | Moderate to high, guides care | CDSCO central, ~120 to 240 days |
| Class D | High risk, critical decisions | CDSCO central, upper-end timelines |
| AI/ML SaMD | Often Class C or D | Plan for the upper end, plus a change protocol |
The planning lesson is to classify early and budget the timeline into your launch, because a Class C AI tool can take the better part of a year to clear. Building the product without knowing its class is how teams discover, late, that they needed central approval and a clinical evidence package they did not prepare.
Step 3: Set up an Algorithm Change Protocol for your model
AI models change, and a regulator that required a fresh licence for every retrain would make iteration impossible. The CDSCO draft addresses this with an Algorithm Change Protocol (ACP) for AI and machine-learning tools, which lets you make defined, pre-specified updates without constant re-licensing, as Mavenrs' analysis explains. The catch is that the protocol must be specified up front: what kinds of change are allowed, within what bounds, and how you validate them.
The step is to write your ACP before you launch, not after your first model update. Define the performance envelope your model must stay within, the data and tests you will use to validate a change, and the records you will keep. Done well, the ACP is what lets a healthcare AI product improve safely inside the regulation rather than freezing at version one.
Step 4: Build DPDP-grade consent and data handling
Patient data is among the most sensitive categories, and the DPDP Act 2023 with its 2025 Rules sets a high bar. Hospitals and products must obtain explicit, informed consent before collecting, processing, or sharing personal data, and the Rules require consent notices to be standalone, in plain language, and specific about what data is collected, for what purpose, and how it will be used, as Ardent Privacy's healthcare analysis describes. Generic or blanket consent does not meet the standard, and failures can draw penalties up to ₹250 crore.
The design step is to make consent granular and auditable, to minimise the data your model actually needs, and to prefer privacy-preserving techniques such as federated learning where you can train without centralising raw patient records. A healthcare AI product that collects everything by default is both poor engineering and a compliance risk; one that collects the minimum, with clear consent, is easier to deploy and to defend.
Step 5: Integrate with ABDM and the wider governance frame
Indian healthcare AI does not run in isolation; it plugs into national digital health infrastructure. The Ayushman Bharat Digital Mission assigns every citizen a digital health ID and builds a national health-records exchange, which is the structured, longitudinal data substrate that clinical models need, and the government is deploying an AIIMS-developed AI clinical decision support system across hospitals nationwide under ABDM, per Digital Health News. Around this sit ethics and validation expectations from bodies such as ICMR.
The step is to design for interoperability and governance from the start: support ABDM standards so your product can exchange records cleanly, and align with ICMR's ethical guidance for AI in health research and care. A product that ignores the national frame may work in a single hospital but cannot scale into the system the country is actually building.
Step 6: Run post-market surveillance and security
Approval is not the finish line. A major focus of the CDSCO draft is post-market surveillance of software devices: manufacturers must maintain performance records, conduct ongoing safety evaluations, submit periodic safety update reports, and report cybersecurity vulnerabilities, as india-briefing's guide notes. For an AI product, this means monitoring real-world performance for drift, because a model that was accurate at approval can degrade as clinical data shifts.
The step is to build the monitoring in: track live performance against the envelope you defined in your ACP, watch for degradation, keep the records the regulator expects, and treat a security vulnerability as a reportable event. Post-market surveillance is where many software teams underinvest, and it is exactly where a healthcare AI product earns or loses its licence to keep operating.
| Step | What to do | Governing frame |
|---|---|---|
| 1. Classify | Decide if your software is a medical device | CDSCO draft guidance |
| 2. Licence | Find your risk class, file with the right authority | MDR 2017, CDSCO |
| 3. Change control | Write an Algorithm Change Protocol | CDSCO ACP for AI/ML |
| 4. Consent and data | Granular consent, data minimisation | DPDP Act 2023 and Rules 2025 |
| 5. Interoperate | Support health-records exchange and ethics | ABDM, ICMR |
| 6. Surveil | Monitor performance, report security | CDSCO post-market surveillance |
Sequencing a compliant deployment
Run these in order, because each depends on the one before. Classification sets your licensing path; the licence sets your evidence and timeline; the change protocol protects your ability to iterate; consent and data handling decide whether you can use the data at all; ABDM integration decides whether you can scale; and surveillance keeps you operating. Teams that try to do these in parallel, or skip to deployment, usually discover a missing approval or an inadequate consent flow at the worst time, after the product is built.
The encouraging part is that the frame is now defined enough to plan against. Two years ago, the rules for AI medical software in India were unclear; the October 2025 CDSCO draft, the DPDP Rules, and ABDM together give a builder a path, even if it is a demanding one.
Build a clinical evidence package
A Class C or D AI tool is not approved on its code; it is approved on evidence that it is safe and effective for its intended use. That means defining the intended use precisely, the patient population, the clinical setting, and the decision the software supports, then showing performance data that backs the claim. For an AI diagnostic, that includes how the model performs against a reference standard, on data that represents the population it will serve, with the failure modes documented honestly. The lifecycle framing means the regulator wants not just a snapshot of accuracy but a plan to keep it safe over time.
The practical step is to assemble this package as you build, not after. Specify the intended use early, because it determines your risk class and your evidence bar, and collect validation data that matches the real clinical setting rather than a clean research set. A model that scores well on a curated dataset but was never tested on the messy data of an actual hospital is exactly what the evidence requirement exists to catch.
Validation, bias, and clinical safety
Clinical AI carries a risk ordinary software does not: it can be confidently wrong in ways that harm a patient, and it can be wrong unevenly across groups. India's population is diverse, and a model trained on data from one region or demographic can underperform on another, which is both a safety problem and an ethics one under guidance from bodies such as ICMR. Validation therefore has to test performance across the groups the tool will serve, not only in aggregate, and the evidence package should report it that way.
The step is to treat bias and subgroup performance as part of safety, not a separate exercise. Test across age, sex, region, and any clinically relevant subgroup, document where performance varies, and constrain the intended use to where the evidence supports it. A tool that is honest about where it works is safer and more credible to a regulator than one that claims uniform performance it cannot show.
A realistic timeline and budget
Put the pieces together and a Class C AI deployment is a programme, not a sprint. Classification and intended-use definition come first, then the clinical evidence and validation work, then the central CDSCO submission with an approval window that can reach 120 to 240 days, alongside building DPDP-grade consent and ABDM interoperability in parallel. A realistic plan assumes most of a year from a finished model to a deployed, licensed product, and resources the regulatory and clinical work as seriously as the engineering.
The budget lesson is that compliance is a line item, not an afterthought. Clinical validation, regulatory filing, consent infrastructure, and post-market monitoring all cost real time and money, and skipping them does not save either; it moves the cost to a failed deployment. Teams that plan the regulatory path from the start reach the clinic; teams that treat it as paperwork at the end stall before they get there.
Common compliance gaps
A few gaps recur in Indian health-AI projects. The first is misclassifying a diagnostic tool as a wellness app to avoid CDSCO, which collapses the moment a clinician relies on its output. The second is consent that is generic rather than specific, which the DPDP Rules reject in favour of the standalone, plain-language notice they require. The third is a model with no change protocol, so the first retrain triggers a re-licensing problem nobody planned for. The fourth is no post-market monitoring, so model drift goes unnoticed until performance has quietly degraded in real use.
Each gap is cheaper to close at design time than after a submission or a deployment fails. The pattern across all of them is the same: the regulation expects a lifecycle plan, from intended use through change control to surveillance, and a product that has one moves through approval and into clinics far faster than one that does not.
India market context
The opportunity is large and specifically Indian. ABDM's national health-records exchange creates a substrate of Indian clinical data that global models were never trained on, which is exactly where a locally built, locally compliant product has an edge. The AIIMS clinical decision system rolling out across hospitals signals government intent to deploy AI in care at scale, which pulls demand toward products that fit the CDSCO and ABDM frame rather than against it.
The risk is regulatory, not technical. A model that performs well but cannot show its class, its consent basis, or its post-market plan will not deploy, and the DPDP penalty for mishandling health data reaches ₹250 crore. The teams that win treat CDSCO classification, DPDP consent, and ABDM interoperability as first-class design inputs, not paperwork bolted on at the end.
FAQ
How eCorpIT can help
eCorpIT (eCorp Information Technologies Private Limited) is a Gurugram-based, CMMI Level 5 technology organisation whose senior engineering teams build healthcare and AI software. We help health-tech teams classify SaMD, prepare CDSCO licensing and an Algorithm Change Protocol, build DPDP-grade consent and data-minimisation flows, integrate with ABDM, and stand up post-market monitoring. Read more about us, or contact our team to plan a compliant healthcare-AI deployment.
References
- CDSCO, Draft guidance document on Medical Device Software, October 21, 2025.
- Cyril Amarchand Mangaldas, Medical Device As Software: Has CDSCO Guidance Changed The Rules?, January 2026.
- Mavenrs, India Medical Device Software Regulation 2026, 2026.
- Asia Actual, India Releases Draft Guidance on Medical Device Software, 2025.
- Digital Health News, Govt to deploy AI-powered Clinical Decision Support System across hospitals, 2026.
- Ardent Privacy, DPDPA for Healthcare: India's Health Data Protection Laws, 2026.
- ARC Advisory Group, AI in Healthcare in India, 2026.
- India Briefing, Navigating India's Medical Device Software Framework, 2026.
- DPDPA.com, DPDPA Penalties Explained: Rs 50 Crore to Rs 250 Crore Fines, 2026.
_Last updated: June 22, 2026._
