Summary: The CDSCO’s Draft Guidance on Medical Device Software only clarifies how the existing Medical Devices Rules apply to software across its lifecycle, but does not create any new regulatory requirements. Its significance lies in signalling a more structured, risk-based and lifecycle-oriented approach to regulating software-driven healthcare products in India.

Medical device software has historically held an ambiguous status within India’s medical device regulatory framework. Although software now plays a significant role in clinical decision-making through AI-assisted diagnostics, disease monitoring applications, and clinical decision-support tools, the Medical Devices Rules, 2017 (“MD Rules”), were conceived primarily with hardware-based medical devices in mind. Consequently, for several years now, manufacturers and developers of medical software have been left navigating a legally applicable but operationally unclear regulatory regime.

This gap became pronounced after medical devices, including software, were expressly brought within the definition of “drug” under the Drugs and Cosmetics Act, 1940, in February 2020[1]. Although the statutory basis for regulating medical devices (including software) was settled, following the judicial scrutiny by the Delhi High Court[2] and the Supreme Court[3], questions persisted around how the MD Rules should be applied to standalone software and products where software performs a medical function independent of any specific hardware device.

It is in this context that the Draft Guidance Document on Medical Device Software (“Draft Guidance”), issued by the Central Drugs Standard Control Organisation (“CDSCO”) on October 21, 2025[4], assumes significance. While the Draft Guidance does not introduce new regulatory requirements, it seeks to explain how existing provisions of the MD Rules apply in such cases, and to address the uncertainty at the intersection of healthcare regulation and digital innovation. With the stakeholder consultation process having run its course, the Draft Guidance warrants closer examination, not as a new regulatory intervention, but as an articulation of regulatory intent.

Regulatory uncertainty before the Draft Guidance

Before the issuance of the Draft Guidance, regulatory ambiguity manifested across the lifecycle of software, potentially qualifying as a medical device. In particular, the following concerns repeatedly arose:

• Threshold uncertainty: Developers often struggled to determine whether a software product qualified as a “medical device”. While fitness and wellness applications were clearly excluded, the point at which monitoring, analytics, or decision-support functionality crossed into medical purpose was often unclear.
• Classification challenges: The MD Rules classify medical devices into Classes A, B, C, and D, based on risk. However, there was limited guidance on how this framework should apply to standalone software, particularly software that influences diagnosis or treatment without any physical interface with the patient.
• Software update pathways (including AI and ML): Unlike conventional medical devices, software evolves continuously. Diagnostic and AI-driven tools are routinely updated to improve performance or accuracy, raising questions around whether each update requires prior regulatory approval, particularly where updates may affect clinical performance or risk classification.
• Licensing and manufacturing concepts: The application of concepts such as “manufacture”, “import”, and “place of manufacture” to cloud-based software, developed by geographically distributed teams, remained unsettled, particularly where software is delivered electronically across borders.

Nature and Scope of the Draft Guidance

Against this backdrop, the Draft Guidance serves as a clarificatory instrument for medical device as a software under the MD Rules. At the outset, the Guidance states that it reflects existing regulatory practices under the MD Rules and should not be construed as creating new legal obligations. Within this limited but important scope, the Draft Guidance provides clarity across three interlinked aspects of regulation.

Software categorisation under the Draft Guidance

The Draft Guidance draws a functional distinction between embedded and standalone medical software once it qualifies as a medical device.

• Software in a Medical Device (“SiMD”) refers to software integrated within a hardware medical device that enables or controls its functioning. This includes embedded firmware in pacemakers, software driving insulin pumps, or operating systems integral to diagnostic analysers. This software does not independently perform a medical purpose and assumes the risk classification of the parent hardware device. Separate classification is, therefore, not required.
• Software as a Medical Device (“SaMD”) is a standalone software that independently performs a medical purpose without being embedded in a hardware medical device. This includes AI-powered radiology tools, computer-aided detection software, and mobile applications intended to monitor or analyse medical conditions. SaMD must be classified independently, based on its intended use and clinical impact, in accordance with the MD Rules.

Risk-based classification framework

For SaMD, the Draft Guidance adopts a risk-based classification framework, aligned with the First Schedule to the MD Rules. Classification is driven by two key considerations: significance of the information provided by the software and the seriousness of the healthcare situation it addresses. Software that plays a direct role in diagnosing or guiding treatment decisions in critical clinical scenarios is likely to attract higher risk classifications (Class C or D). By contrast, software that supports clinical management in non-serious situations may fall within lower risk categories (Class A or B).

Importantly, the Draft Guidance does not create a separate classification regime for software. Instead, it explains how existing classification principles under the MD Rules should be applied in a software-driven context.

Algorithm Change Protocol for AI and ML-based software

Recognising the evolving nature of AI and machine learning-based software, the Draft Guidance introduces the concept of an Algorithm Change Protocol (“ACP”), intended to address the reality that such software is updated over time, often to improve performance or accuracy. Manufacturers are therefore expected to define, in advance, how algorithmic changes will be managed across the product lifecycle.

Once an ACP is approved by the relevant licensing authority, predefined updates may proceed without the need for separate regulatory approvals for each change. Importantly, ACP approval does not, by itself, constitute regulatory approval of the software, nor does it dilute ongoing obligations relating to safety, quality, or post-market surveillance.

Continuing Compliance and Regulatory Implications

The Draft Guidance reiterates that medical device software is subject to the same quality management, safety, and post-market surveillance requirements applicable to other medical devices under the MD Rules. Manufacturers are required to maintain appropriate documentation relating to software design and architecture, risk management, clinical evaluation, and verification and validation activities. The Guidance further clarifies that existing licensing and jurisdictional principles under the MD Rules continue to apply, with the Central Licensing Authority regulating imports of all classes of medical devices and the manufacturing of Class C and D devices, and State Licensing Authorities regulating the manufacturing of Class A and B devices.

At the same time, while the Draft Guidance brings clarity to several aspects of medical device software regulation, certain practical issues remain unresolved. These include how cloud-based development and deployment models are regulated, the criteria for determining which software updates require regulatory approval versus those permissible under an approved Algorithm Change Protocol, and questions around manufacturer attribution when software is developed, hosted, and marketed by different entities.

Looking Ahead

Viewed holistically, the Draft Guidance does not amend the legal framework or expand the scope of regulation for software medical devices. Instead, it brings coherence to the application of existing rules in a rapidly evolving digital health environment. However, its practical impact will depend on consistent and proportionate implementation by licensing authorities, as well as on how flexibly lifecycle concepts, such as risk-based classification and controlled software updates are applied in practice. It remains to be seen how the Draft Guidance ultimately takes shape in its final form, and how the clarifications emerging from the consultative process are reflected in the final regulatory position. If implemented carefully, the Draft Guidance has the potential to reduce regulatory uncertainty for developers and manufacturers while reinforcing patient safety, without constraining innovation through rigid or overly formalistic compliance expectations.

---

[1] Vide Notification S.O. 648(E) dated February 11, 2020 issued by the Ministry of Health and Family Welfare, accessible at https://cdsco.gov.in/opencms/resources/UploadCDSCOWeb/2018/UploadGazette_NotificationsFiles/S.o6478eMedical%20Device%20Definition.pdf

[2] Surgical Manufacturers and Traders Association v. Union of India, W.P.(C) 10514/2019 and W.P.(C) 10478/2020, Judgment dated September 1, 2023

[3]Surgical Manufacturers and Traders Association v. Union of India, S.L.P. (Civil) Diary No. 53762/2023, Order dated January 25, 2024

[4]https://cdsco.gov.in/opencms/resources/UploadCDSCOWeb/2018/UploadPublic_NoticesFiles/Draft%20guidance%20document%20on%20Medical%20Device%20Software%2021%2010%202025.pdf