-
The Central Drugs Standard Control Organization has released the draft guidance on for regulating software-based medical devices.
-
The draft aligns India’s approach with international standards and seeks to address regulatory ambiguity surrounding AI-driven, digital, and cloud/network-based software.
I. Introduction
In India, medical devices are regulated under the Medical Device Rules, 2017 (“MDR”) which includes software-based medical devices within its ambit. However, the MDR does not provide specific guidance on regulation of such devices such as for classification, licensing, validation, or post-market oversight. As a result, manufacturers and regulators have faced uncertainty regarding the licensing of standalone digital health applications and lack of formal provisions for AI/ML validation or cybersecurity management. Moreover, there have been no defined mechanisms to track or evaluate software updates and algorithmic modifications after product deployment, leaving gaps in ongoing safety assurance.
To address these long-standing issues, the Central Drugs Standard Control Organization (“CDSCO”) under the Ministry of Health and Family Welfare, issued the Draft Guidance on Medical Device Software (“Draft Guidance”) on October 21, 2025.1 The draft seeks to bring structure and predictability to the regulation of software-based medical devices by formally distinguishing between Software in a Medical Device (“SiMD”) and Software as a Medical Device (“SaMD”) and establishing a risk-based classification and licensing framework.
The Draft Guidance represents India’s first dedicated effort to align its medical software regulation with international best practices and lays the foundation for a transparent, technology-responsive framework that balances patient safety, innovation, and regulatory accountability.
We have analysed some of the key provisions of the Draft Guidance below.
II. Key Provisions of the Draft Guidance
A. Classification and Scope
The Draft Guidance is intended to provide much needed clarity on the regulation of Medical Device Software (“MDS”) (inclusive term used for referring to SiMDs and SaMDs under the Draft Guidance) including In vitro diagnostic MDS. The Draft Guidance applies only to software products which attract the definition of a “Medical Device” under the MDR. It classifies MDS into two categories:
-
SiMD - Software that is considered as a part of the medical device hardware and it does not have or perform a medical purpose on their own. For example, embedded software that controls or drives an insulin pump. Examples of SiMD would be an embedded software that controls or drives an insulin pump to deliver a calculated dose of insulin or the embedded software/firmware in a cardiac pacemaker is regulated as a component of that pacemaker, because it is supplied as part of the device and is necessary for the device to function.
-
SaMD – Refers to standalone software which can be used either alone or in combination with a hardware medical device to perform its intended use. For example, software intended for image analysis of body fluid preparations, or AI/ML-based tool intended for screening. Examples of SaMD are a software intended for image analysis of body fluid preparations or digital slides to perform cell count or a software intended to provide information that may suggest or exclude medical conditions by analyzing X-ray images or ECGs.
In addition to this, the Draft Guidance explicitly includes cloud and network-based medical device software which does not drive or influence the use of another hardware medical device shall be considered as SaMD, if it meets the requirements for a ‘medical device’.2
It provides the key elements that should be considered while framing the ‘intended use’ statement for the MDS by the manufacturer, which includes the following:
-
Medical Purpose;
-
Intended Disease or Condition;
-
Intended Patient Populations;
-
Intended Users;
-
Intended Use Environment;
-
Contra-Indications;
-
Medical device software function, etc.
The Draft Guidance clarifies that only software performing a medical purpose, such as diagnosis, prevention, monitoring, prediction, or treatment of disease or physiological conditions, will fall within the ambit of MDR. By contrast, administrative, operational, or communication tools such as, hospital information systems, billing software, or telecommunication platforms used solely for data transmission or scheduling are proposed to be excluded from regulation under the MDR. This distinction is critical because it establishes the boundaries of regulatory applicability and ensures that compliance obligations are focused on software that directly impacts patient care or clinical decision-making.
B. Risk-Based Regulation
The Draft Guidance adopts the four-tier risk classification system as prescribed under the MDR, which categorizes all medical devices, including software, based on the intended use of the device and the potential risk posed to patient health and safety. The classes are structured as follows:
Classification of SiMD and SaMDs
The Draft Guidance states that for MDS, the classification is based on the intended use of the device following the risk-based classification followed under the First Schedule to the MDR. As per this, SiMDs
falls automatically in the same risk class as its hardware medical device as the SiMD only drives or influences the use of a hardware device.
Additionally, specific guidance is given for the classification of SaMD wherein the risk classification is determined while considering factors such as the significance of information provided by the software for decision making in treatment of diagnosis, deciding on clinical management for patient, etc. in the state of healthcare situation in which the SaMD is intended to be implemented such as critical/serios/non-serious situation. etc.
This framework mirrors the risk categorization model of the International Medical Device Regulators Forum and the European Union Medical Device Regulation, both of which emphasize that regulatory scrutiny should be proportionate to the software’s clinical significance. This not only strengthens patient safety but also improves regulatory efficiency, making the Indian framework more predictable and globally harmonized.
C. Quality and Standards
The Draft Guidance mandates that all MDS are required to conform to the standards laid down by the Bureau of Indian Standards (“BIS”) or other standards as may be notified by the MoHFW such as the International Organisation for Standardisation (ISO) or the International Electro Technical Commission (IEC), or by any other pharmacopeial standards.
The manufacturers of MDS are required to implement Quality Management System (“QMS”) governing all stages of the software’s lifecycle — from design and development to validation, release, maintenance, and post-market surveillance.
Local Indian manufacturers are required to keep records demonstrating compliance with QMS and submit an undertaking stating compliance with the requirements of QMS following the Fifth Schedule of the MDR. This must be done as part of their application for grant of manufacturing licenses. Similarly, for import purposes, the overseas manufacturer is required to ensure that its manufacturing facility complies with the QMS requirements and submits a notarized copy of QMS certificate issued by its competent authority along with their application for grant of import license.
The Draft Guidance provides clarity on the mandatory implementation of QMS, outlining the responsibilities of the manufacturers and importers for compliance with regulatory requirements. By providing explicit direction on the application of QMS, it promotes consistency, transparency, and accountability in software-based medical devices.
D. Licensing Pathway
The Draft Guidance aligns the licensing requirements for medical device software with the existing framework under the MDR, while adapting it to the unique nature of software-based medical devices. Similar to non-software medical devices, the licensing process for software will depend on its risk classification. Under MDR, low-risk devices (Class A and B) fall within the jurisdiction of the State Licensing Authority, while higher-risk devices (Class C and D) are regulated by the Central Licensing Authority. Applicants are required to obtain a manufacturing license or an import license, depending on the nature and source of the product.
It also provides detailed guidance on nature of data submissions and documents required for various licenses along with providing document checklists for such forms and licenses. The applications for test licenses for the MDS are to be submitted online via the National Single Window System (NSWS), whereas applications for manufacturing and import licenses are processed through the CDSCO’s Medical Device Online Portal. This dual-portal structure introduces digital efficiency and traceability into the licensing process, though its effectiveness will depend on seamless integration between the two systems.
E. Documentation and Post-Marketing Requirements
The Draft Guidance places strong emphasis on documentation and post-marketing requirements for medical devices as prescribed under MDR. Applicants are required to maintain detailed records of post marketing surveillance to ensure traceability, accountability, and consistent performance of the software.
A key feature of the Draft Guidance is the introduction of an Algorithm Change Protocol (“Protocol”) for MDS. The Protocol requires manufacturers to specify how algorithmic updates or retraining will be managed, validated, and reported to regulators.
In addition to pre-market documentation, the Draft Guidance prescribes robust post-market obligations, including submission of Periodic Safety Update Reports, implementation of post-market surveillance mechanisms, and cybersecurity incident reporting. These requirements ensure that manufacturers continually monitor software performance, investigate adverse events, and disclose any vulnerabilities that could affect patient safety or data integrity.
III. Conclusion
The Draft Guidance is a pivotal step in building India’s digital health regulatory ecosystem. It offers long-overdue clarity, global harmonization, and stronger patient protection while supporting innovation in AI and medical software development.
The effectiveness of the Draft Guidance will ultimately depend on how it is implemented and interpreted in practice. The introduction of new documentation, validation, and post-market obligations may create practical compliance challenges, particularly for smaller manufacturers and start-ups developing low-risk (Class A and B) software. A calibrated and proportionate approach—where regulatory requirements correspond to the risk profile of the software and are supported by clear procedural guidance—will be essential to ensure that the framework enhances accountability without stifling innovation. Equally important will be the need for uniform interpretation and consistent enforcement by both State and Central authorities to prevent regulatory fragmentation once the framework takes effect.
For effective implementation, CDSCO should clarify enforceability, allow transition time, and issue targeted guidance for adaptive AI tools and emerging digital technologies. The Draft Guidance ensures that India’s regulatory ecosystem keeps pace with the rapid evolution of medical technology and represents a balanced approach in promoting innovation, regulatory ease and prioritizing patient interest.
Authors
Naveli Sharma, Shlok Siddhant, Tanya Kukade and Dr. Milind Antani
You can direct your queries or comments to the relevant member.
1Accessible at: https://cdsco.gov.in/opencms/opencms/system/modules/CDSCO.WEB/elements/download_file_division.jsp?num_id=MTM1MjM=
2Accessible at: https://cdsco.gov.in/opencms/opencms/system/modules/CDSCO.WEB/elements/download_file_division.jsp?num_id=NTU0OA==