-
The CDSCO has released a guidance document on regulation of medical device software devices.
-
Introduces detailed requirements for regulation of medical device software, AI-enabled software, quality management systems, technical documentation and post-market surveillance.
I. INTRODUCTION
On July 21, 2026, the Central Drugs Standard Control Organisation (“CDSCO”), Medical Devices Division, issued a circular releasing the final Guidance Document on Medical Device Software under the Medical Devices Rules, 2017 (“Guidance”), bearing Doc No. CDSCO/MD/GD/MDSW/01/2026.1 It follows the draft guidance issued by the CDSCO on medical device software. All State and Union Territory Licensing Authorities and stakeholders have been advised to refer to the Guidance while submitting applications for regulatory approvals under the Medical Devices Rules, 2017 (“MDR”).
The Guidance addresses the regulatory framework, classification principles, safety and performance requirements, documentation expectations, quality management considerations and post-market obligations for medical device software (“MDSW”). We have analysed the key provisions of the Guidance and their impact on the industry below.
II. SCOPE AND APPLICABILITY
The Guidance applies to software products which attract the definition of a “medical device” under MDR, including In vitro diagnostic (“IVD”) medical devices.
MDSW refers to software that is intended for a medical purpose. It includes software that, alone or in combination, performs one or more medical purposes without being part of a hardware medical device, described as standalone medical device software, and software that is a part of the medical device hardware or that drives or influences the use of that device.
In this context, “medical purpose’ is defined under the Guidance to include diagnosis, prevention, monitoring, treatment or alleviation of any disease or disorder; diagnosis, monitoring, treatment, alleviation of or assistance for any injury or disability; investigation, replacement, modification or support of the anatomy or of a physiological process; supporting or sustaining life; disinfection of medical devices; and control of conception. The guidance also extends it to mitigation, prediction and alleviation of any disease or pathological condition or state of humans or animals.
The guidance further sheds light on software products that are regulated as MDSW and software products which fall outside the ambit of regulation under the MDR. Software products regulated under the MDR include software intended for a medical purpose in humans or animals, whether embedded in or used to drive or influence medical device hardware or operating as standalone software. It also includes software interfaced with other medical devices or general-purpose software, mobile applications, cloud or network-based software, AI or machine learning-based software, and commercial off-the-shelf software, where such software meets the definition of a medical device.
Software products falling outside the scope of the MDR include software intended solely for general wellness, fitness, education or training without a medical purpose. It also includes software limited to data transfer, storage, archival, formatting, communication or similar functions. The exclusion also covers certain hospital and clinical information systems, general-purpose communication systems, laboratory information systems, where their functions do not independently serve a medical purpose.
The exclusion is function-specific rather than product-specific. Where software products carry additional functions permitting use for a medical purpose, such as image analysis as an aid in diagnosis, quantification of physiological parameters for clinical decision-making or real-time patient monitoring, it is likely to be treated as a medical device.
In the draft guidance issued by the CDSCO on medical device software previously, medical device software was classified either as “Software as a Medical Device” and “Software in a Medical Device”. However, the final Guidance does not adopt this terminology to suggest a wide ambit of MDSW.
The Guidance adopts a broader, function-based approach in determinisation of whether a software product will be regulated as a medical device and reduces uncertainty around the regulatory status of digital health products, including AI-enabled software.
III. ARTIFICIAL INTELLIGENCE IN MEDICAL DEVICE SOFTWARE
The Guidance expressly recognizes AI and machine learning based software MDSW, where it has a medical purpose and sets out specific considerations for AI-enabled MDSW across its lifecycle. Applicants are expected to provide information on the methodology underlying the software, including whether it uses rule-based systems, AI or ML, neural networks, or fixed or adaptive algorithms, as well as the degree of autonomy of the software.
The Guidance also identifies AI-specific risks such as bias, lack of explainability, model drift, poor generalisability and hallucination, and contemplates the use of an Algorithm Change Protocol depending on the nature and risks of the product. Further, manufacturers are expected to provide information regarding the composition and source of datasets used for training, validation and testing, and demonstrate appropriate assessment of the model.
The Guidance places particular emphasis on ensuring that AI-enabled MDSW performs appropriately across populations, healthcare settings and operational environments relevant to its intended use. Where models have been trained or validated outside India, manufacturers may be required to justify their applicability to Indian clinical settings and supplement foreign performance evidence with validation in representative Indian populations. These considerations extend beyond the pre-market stage, with AI-enabled MDSW expected to be continuously monitored post-market for changes in performance and AI-specific risks, including bias, model drift and hallucination.
By prescribing AI-specific documentation, validation and lifecycle monitoring requirements, the Guidance aligns regulatory expectations with the unique risks posed by AI based MDSW, and signals increased regulatory scrutiny of such medical devices.
IV. INTENDED USE AND RISK-BASED CLASSIFICATION
A. Intended use statement
The intended use statement is pivotal in regulation and risk classification of medical devices, including MDSW. It must clearly define the specific medical purpose of the MDSW, for instance whether it is decision support software, whether it drives a device, or whether it provides a definitive diagnosis or treatment recommendation.
The parameters to be considered by applicants while drafting the intended use as provided in the Guidance are the medical purpose, the intended disease or condition and whether it is critical, the intended patient population, the intended users, the intended use environment, contraindications, the device software function, and the software platform. The Guidance also recognizes that not every parameter applies to every MDSW product, and information such as contraindications may sit outside the intended use statement.
B. Risk-based classification
Under the MDR, all medical devices including MDSW are classified using the parameters provided in the First Schedule of the MDR basis the intended use of that medical device.
The classes are structured as follows:
Software intended to drive or influence the use of hardware is classified in the same risk class as that hardware. For standalone MDSW, the Guidance offers the following matrix, which reads the significance of the information provided for healthcare decision-making against the state of the healthcare situation i.e. critical,2 serious3 or non-serious4.
By prescribing detailed parameters for intended use statements and introducing a structured framework for classifying standalone MDSW, the Guidance reduces ambiguity in risk classification and assists manufacturers in identifying the applicable licensing and compliance requirements.
V. QUALITY MANAGEMENT SYSTEM AND OTHER APPLICABLE STANDARDS
The Guidance provides that the manufacturer of MDSW must establish a quality management system (“QMS”) in respect of the organisational structure and the entire software lifecycle, covering design, development, product planning, configuration, deployment and maintenance as prescribed under the MDR. This ensures that MDSW is developed consistently, risks are controlled, changes are traceable, validation is documented, defects are managed, and cybersecurity is maintained.
The Guidance provides specific compliance requirements such as submission of an undertaking or notarised QMS certificate issued by the National Regulatory Authority or competent authority for domestic and overseas manufacturers, respectively. The Guidance also prescribes substantive expectations for MDSW in compliance with the QMS requirements such as documented and controlled QMS appropriate to the risk class of the MDSW, mechanisms for continuous performance assurance, compliance with applicable cybersecurity standards, etc.
The Guidance states that MDSW must conform to standards laid down by the Bureau of Indian Standards (“BIS”) or as notified by the Ministry of Health and Family Welfare failing which, to compliance with ISO or IEC standards or any other pharmacopoeial standard must be undertaken. The Guidance also specifically highlights the regulatory quality requirements for digital health ecosystem such as interoperability, consent-based data governance, secure information exchange, privacy and confidentiality, and digital traceability and accountability. This provides greater certainty on the regulatory expectations for obtaining and maintaining licences for MDSW in India.
VI. DOCUMENTATION AND POST-MARKETING REQUIREMENTS
The Guidance prescribes comprehensive documentation requirements for MDSW manufacturers throughout the product lifecycle. Under this, applicants are expected to maintain technical documentation demonstrating the software's intended use, architecture, design, risk management, verification and validation, cybersecurity controls, clinical evaluation (where applicable), and software lifecycle processes. For AI-enabled MDSW, additional documentation relating to algorithm design, training and validation datasets, performance across relevant populations, bias assessment, explainability and algorithm change protocols is also expected. The documentation should be sufficiently detailed to demonstrate the safety, performance and regulatory compliance of the software.
The Guidance also emphasises that regulatory obligations continue after market entry and requires manufacturers to implement appropriate post-market surveillance mechanisms. Manufacturers are expected to monitor the performance of MDSW throughout its lifecycle, identify and address software defects, cybersecurity vulnerabilities and safety issues, and maintain appropriate records of software updates and corrective actions.
These requirements ensure that manufacturers continually monitor software performance, investigate adverse events, and disclose any vulnerabilities that could affect patient safety or data integrity.
VII. CONCLUSION
The Guidance reflects the CDSCO's intent to strengthen oversight of software-based medical technologies while supporting innovation through greater regulatory clarity. As digital health solutions, particularly AI-enabled software, continue to evolve, manufacturers will need to adopt a lifecycle approach to compliance encompassing product design, validation, quality management, cybersecurity and post-market surveillance. Early alignment with the Guidance will be critical to facilitating regulatory approvals and ensuring continued compliance under the MDR for the medical devices industry.
Shlok Siddhant, Naveli Sharma, Tanya Kukade and Dr. Milind Antani
You can direct your queries or comments to the authors.
1Circular F. No. MED-16028/2/2025-eoffice dated July 21, 2026 and Guidance Document on Medical Device Software, Doc No. CDSCO/MD/GD/MDSW/01/2026.
2Critical situations are those where accurate or timely action is vital to avoid death, long-term disability or serious deterioration of health, or to mitigate impact on public health.
3Serious situations are those where accuracy is vital to avoid unnecessary interventions or long-term irreversible consequences.
4Non-serious situations are those involving slow, predictable progression manageable with minor, largely non-invasive interventions.