CDSCO’s New Software as a Medical Device (SaMD) Rules: What AI Tool Developers and Hospitals Must Know

Until October 2025, a hospital procuring an AI-powered imaging tool, a diagnostic mobile app, or a cloud-based clinical decision support platform in India was navigating genuine regulatory ambiguity — the Medical Devices Rules, 2017, existed, but offered little specific direction on how software, as distinct from physical hardware, should be classified and licensed. The Central Drugs Standard Control Organization’s Draft Guidance on Medical Device Software, released on October 21, 2025, is the first serious attempt to close that gap. This article explains what it actually covers and what it means practically for clinics and hospitals evaluating software-based medical tools.

Why This Guidance Was Needed

The existing Medical Devices Rules, 2017, framework lacked detailed direction on software-specific aspects — risk classification tailored to software’s unique characteristics, licensing pathways, validation expectations, cybersecurity, and how to handle post-deployment updates (a particular challenge for AI/ML tools that continue to learn and change after initial approval). This regulatory gap had made it genuinely difficult to evaluate the growing range of digital health solutions entering the Indian market, from AI-driven diagnostic decision support to standalone mobile health applications.

The Core Distinction: SiMD vs. SaMD

The guidance formally distinguishes between two categories that had previously been treated with less clarity:

• Software in a Medical Device (SiMD): software embedded in, and inseparable from, a physical medical device — firmware in a pacemaker, or the operating software built into an IVD analyser. This software does not perform a medical purpose independently and does not require separate classification; it simply inherits the risk classification of the parent hardware device.
• Software as a Medical Device (SaMD): standalone software that performs a medical purpose — diagnosis, monitoring, prevention, or treatment support — on its own or alongside general-purpose hardware, without being embedded in a dedicated physical medical device. This includes AI-powered radiology and imaging analysis tools, computer-aided detection software, standalone clinical decision support platforms, and mobile applications intended to monitor or analyse a medical condition. SaMD must be classified independently.

The Risk-Based Classification System (Class A to D)

SaMD classification follows a risk-based framework aligned with the First Schedule to the Medical Device Rules and with international IMDRF standards, driven by two considerations: the significance of the information the software provides for a healthcare decision, and the seriousness of the healthcare situation it addresses.

Class	Risk Level & Licensing Authority
Class A	Minimal risk of injury; online registration with CDSCO; licensed by State Licensing Authority
Class B	Low-to-moderate risk; licensed by State Licensing Authority
Class C	Higher risk, plays a more direct role in diagnosing or guiding treatment in serious clinical scenarios; licensed by CDSCO’s Central Licensing Authority
Class D	Highest risk, direct role in critical clinical decisions; licensed by CDSCO’s Central Licensing Authority

As a practical rule of thumb: software supporting clinical management in non-serious situations tends to fall into the lower classes (A or B), while software that plays a direct diagnostic or treatment-guiding role in critical clinical scenarios is likely to attract the higher classifications (C or D), bringing it under CDSCO’s more stringent central review.

A Specific, Important Feature for AI/ML Tools: The Algorithm Change Protocol

This is arguably the guidance’s most consequential innovation for AI developers specifically. Traditional medical device regulation assumes a product’s design is fixed at approval; AI/ML-based tools, by contrast, are often designed to continue learning and updating after deployment. The guidance introduces an Algorithm Change Protocol (ACP), which allows developers to pre-specify and document how an AI model may be updated over time — without requiring a fresh licensing review for every incremental algorithm change, provided the change stays within the pre-approved protocol’s bounds. This is a meaningful, practical accommodation for how modern AI tools actually work, and developers should treat a well-documented ACP as central to their regulatory strategy, not an afterthought.

What the Guidance Does NOT Do

It’s important to be precise here: the Draft Guidance clarifies how the existing Medical Devices Rules, 2017, apply to software across its lifecycle — it does not create entirely new statutory requirements from scratch. Its significance lies in providing structure, predictability, and lifecycle-oriented clarity to an area that was previously ambiguous, not in imposing a wholly new regulatory regime. As of this writing, it remains in draft form — the public consultation period has closed, and the final version may incorporate changes based on industry feedback, so developers and hospitals should monitor the CDSCO website for the official final release.

What This Means for Hospitals and Clinics Buying Software (Not Just Building It)

While much of the guidance is written with software developers and manufacturers in mind, hospitals and clinics procuring AI diagnostic tools, clinical decision support platforms, or health monitoring apps should treat this classification framework as a practical due-diligence checklist:

1. Ask any vendor what SaMD class their product is classified under (or expects to be classified under once the guidance is finalised), and request supporting documentation rather than accepting a verbal assurance.
2. For higher-risk (Class C or D) tools — those playing a direct role in diagnosis or treatment guidance for serious conditions — confirm the vendor holds, or is pursuing, Central Licensing Authority approval rather than only state-level registration.
3. For AI/ML tools specifically, ask whether the vendor has an Algorithm Change Protocol in place, and how model updates are validated and communicated to the hospital before deployment.
4. Build vendor SaMD classification and licensing status into procurement contracts and renewal reviews, since this is a genuinely new due-diligence dimension that didn’t previously have this level of regulatory structure to reference.

How This Connects to the National CDSS Rollout

The timing here is notable: this SaMD guidance arrived just months before the national rollout of the AIIMS-built Clinical Decision Support System across roughly 70,000 hospitals, covered in a companion article. A government-deployed tool of that scale operating without a clear classification and governance framework would have been a significant regulatory gap — the SaMD guidance provides at least the beginnings of the structure needed to evaluate and govern exactly this kind of large-scale clinical AI deployment going forward.

Frequently Asked Questions

Is the CDSCO SaMD guidance final, binding law as of now?

No, as of this writing it remains in draft form following the close of its public consultation period; hospitals and developers should watch for the final, notified version, which may differ from the draft in some respects.

Does every hospital software system now need CDSCO classification?

Only software that performs a medical purpose — diagnosis, monitoring, prevention, or treatment — falls within scope; general hospital administrative or billing software without a medical purpose is not classified as a medical device under this framework.

What’s the practical difference between Class A/B and Class C/D for a hospital buyer?

Class A and B software is licensed at the state level and generally carries lower risk; Class C and D software requires Central Licensing Authority approval and is used in higher-stakes diagnostic or treatment-guiding roles — hospitals should apply more rigorous vendor due diligence for the latter category.

Why does the Algorithm Change Protocol matter specifically for AI tools?

It allows an AI/ML tool’s model to be updated over time within pre-approved, documented boundaries, without requiring a completely fresh regulatory review for every change — reflecting how AI systems actually evolve after deployment, unlike traditional fixed-design medical devices.

Where can hospitals and developers submit feedback or track the guidance’s finalisation?

Through CDSCO’s official channels, including the National Single Window System and the CDSCO Medical Device Online Portal, and by monitoring the CDSCO website (cdsco.gov.in) directly for the official final release announcement.

Researched Sources

1. Lexology (via India Corporate Law/Cyril Amarchand Mangaldas) — The Next Frontier in MedTech Regulation: Dissecting CDSCO’s Draft Guidance on Medical Device Software
2. India Briefing — Navigating India’s Medical Device Software Framework: A Guide
3. Freyr Solutions — SaMD Regulation in India: CDSCO Classification (Class A-D), Registration Requirements & Emerging Market Strategy
4. Gadgeon — CDSCO Medical Device Software: Regulatory Pathways and Classification

Disclaimer

This article is for general informational and educational purposes and reflects CDSCO’s draft guidance as understood at the time of writing; it remains in draft form and may change upon final notification. It is not regulatory or legal advice; hospitals and developers should consult CDSCO’s official guidance and a qualified regulatory affairs professional before making procurement or product-development decisions.