Software is now used for functions that were once limited to traditional medical devices or clinical assessment by a professional. It can analyse treatment parameters, monitor chronic conditions, support diagnosis, guide clinical decisions and control connected medical devices. Artificial intelligence (AI) and machine learning have further expanded these functions by enabling software to identify patterns, predict outcomes and adapt through data.
However, these developments raise important regulatory questions about when software becomes a medical device, how its risk should be classified, what technical and clinical evidence is required for approval, and how cybersecurity risks, software updates and algorithmic drift should be managed after deployment.
The Central Drugs Standard Control Organization (CDSCO) has addressed these issues in its Guidance Document on Medical Device Software, Doc. No. CDSCO/MD/GD/MDSW/01/2026 (Guidance). The document explains how Medical Device Software (MDSW), including in vitro diagnostic medical device software, is regulated under the Drugs and Cosmetics Act, 1940 and the Medical Devices Rules, 2017 (MDR, 2017). It is intended to guide manufacturers, importers, innovators, researchers and other stakeholders while preparing applications for regulatory approvals.
The Guidance does not introduce a separate regulatory framework for software. It reflects the regulatory practices followed under the MDR, 2017, while the provisions of the Drugs and Cosmetics Act, 1940, the MDR, 2017 and subsequent CDSCO guidelines and clarifications continue to govern regulatory compliance.
Scope of the Guidance
The Guidance applies to software that falls within the definition of a medical device under the MDR, 2017 and is intended for a medical purpose. These purposes include diagnosis, prevention, monitoring, treatment or alleviation of disease or disorder; assistance in relation to injury or disability; investigation, replacement, modification or support of anatomy or physiological processes; sustaining life; disinfection of medical devices; and control of conception. Mitigation or prediction of a disease or pathological condition may also amount to a medical purpose.
MDSW may operate independently or form part of a hardware medical device. Standalone MDSW performs a medical purpose without necessarily being part of a physical device, while software that operates, controls or changes the state of a hardware device, or provides output relating to its functioning, may also be regulated.
The platform on which the software operates is not determinative. Mobile applications, AI or ML-based products, cloud or network-based software, Software-as-a-Service (SaaS) products and commercial off-the-shelf (COTS) software may qualify as MDSW where their intended use is medical. The same applies to software that controls or adjusts a medical device through a physical or wireless connection.
Software intended for a medical purpose in animals is also covered. Embedded software or firmware required for a hardware medical device to perform its intended function may be licensed with the parent device. However, a separate manufacturing or import licence is required where such software is sold separately.
Examples given in the Guidance include software controlling an insulin pump, applications connected to blood-pressure cuffs, computer-aided detection software analysing X-rays or ECGs, AI systems used for cancer screening or triage, digital therapeutics intended to mitigate chronic disease and veterinary diagnostic software.
Not every software product used in a hospital, laboratory or healthcare setting is MDSW. Software used only for administrative, operational or information-management purposes generally remains outside the MDR, 2017. This includes enterprise resource planning software used in medical-device manufacturing or quality systems, software used only for transferring, storing, formatting, compressing, encrypting or archiving information, servicing and maintenance software, software that merely changes the presentation of data, and software intended solely for teaching or training.
Hospital Information Systems, Clinical Information Systems, Laboratory Information Systems and Image Management Systems are also generally excluded where their functions are limited to scheduling, billing, storage, validation, communication or management of patient information. However, they may fall within the MDR, 2017 where they perform medical functions such as diagnostic-image analysis, quantification of physiological parameters, clinical decision support, disease screening, treatment recommendation or real-time patient monitoring.
General-wellness software is outside the scope of the Guidance where it only promotes a healthy lifestyle or measures parameters for general health, fitness or routine tracking. However, software intended to screen, diagnose, alert, monitor or manage a disease or medical condition does not fall within this exclusion.
Where software contains both medical-device and non-device functions, the regulated functions should be clearly identified. Similarly, where COTS software forms part of a larger MDSW system, the applicant should explain its role and effect on the safety and efficacy of the medical-device function.
Key Definitions under the Guidance
Medical Device Software: Medical Device Software is software intended for a medical purpose, either independently or as part of, or in connection with, a hardware medical device. Unless otherwise specified, the term also includes IVD medical device software.
Intended Use: Intended use means the use for which the device is intended according to the manufacturer’s labelling, instructions for use, electronic instructions or promotional material, in accordance with the approval granted by the Central Licensing Authority. Intended use determines whether the software is regulated, its risk classification, the evidence required for approval and the scope of permitted claims.
Clinical Evidence: Clinical evidence means the information that supports the scientific validity and performance of the device for its intended use. For non-IVD devices, this includes clinical data and a clinical evaluation report. For IVD software, it includes information derived from human specimens that supports scientific validity and performance.
Investigational Medical Device: An investigational medical device is a device that does not have a predicate device, or an already licensed device proposed for a new intended use, patient population, material or major design change and is undergoing assessment for safety, performance or effectiveness.
Predicate Device: A predicate device is the first approved device of its kind in India that has a similar intended use, material of construction and design characteristics.
Cybersecurity: Cybersecurity refers to the protection of information and systems against unauthorised access, use, disclosure, disruption, modification or destruction throughout the product lifecycle.
Software Bill of Materials: A Software Bill of Materials (SBOM) is a record of the software components used in the product, their relationships and related information. It identifies third-party, open-source and commercial components and supports vulnerability tracking.
Real-World Data and Real-World Evidence: Real-world data (RWD) is information routinely collected about patient health or healthcare delivery, including electronic health records, claims, registries and information generated through digital-health technologies. Data from controlled clinical investigations is not ordinarily treated as RWD. Real-world evidence (RWE) is evidence about the use, safety, effectiveness or performance of a device derived from analysing RWD.
Algorithm Change Protocol: An Algorithm Change Protocol (ACP) is a documented plan for managing anticipated algorithmic changes without compromising the safety, performance or intended use of the software.
Intended-Use Statement
The intended-use statement should explain the medical purpose of the software and its role in the clinical process. It should identify the disease or condition, patient population, intended users, use environment, contraindications, inputs, outputs and operating platform.
The manufacturer should explain whether the software only provides information, supports or drives a clinical decision, assists or provides a diagnosis, recommends treatment, performs triage, replaces a clinician-performed action or directly controls a medical device. The source and format of the inputs, nature and recipient of the outputs, and any interfaces with other devices or systems should also be described. Where relevant, the limitations of the software output and the extent to which clinical responsibility remains with a healthcare professional should be stated.
The application should also identify whether the software is autonomous, works under user supervision or is intended only as an aid, and whether it uses rule-based, fixed, adaptive, AI, ML or neural-network methods. For IVD software, the intended-use statement should additionally identify the analyte or parameter, specimen type, diagnostic function, nature of the result, limitations and whether the product is intended for self-testing or near-patient testing.
Risk-Based Classification
MDSW is classified under the four risk classes prescribed by the MDR, 2017. Class A covers low-risk devices, Class B covers low-moderate-risk devices, Class C covers moderate-high-risk devices and Class D covers high-risk devices.
Software that drives or influences a hardware medical device generally falls in the same risk class as the hardware device. For standalone MDSW, classification is based mainly on the significance of the information supplied by the software and the seriousness of the healthcare situation or condition.
The Guidance distinguishes between software used for treatment or diagnosis, software that drives clinical management and software that informs clinical management. Software used for treatment or diagnosis provides information that may lead to immediate or near-term action. Software that drives clinical management may guide treatment, diagnosis, triage or the next clinical step, while software that informs clinical management provides information without ordinarily triggering immediate action.
Software used for treatment or diagnosis is classified as Class D for a critical condition, Class C for a serious condition and Class B for a non-serious condition. Software that drives clinical management falls in Class C, B or A depending on whether the condition is critical, serious or non-serious. Software that only informs clinical management is Class B for a critical condition and Class A for a serious or non-serious condition.
Standalone MDSW intended for use by a non-clinical user in a serious situation, without specialist support, may be treated as software used in a critical situation. Where more than one classification rule applies, the rule resulting in the higher risk class is followed.
Before filing an application, the applicant should check whether the product is already covered by a risk-classification list published by the Central Licensing Authority. Where software with the same or a similar intended use appears in the list, the corresponding classification may be followed. Where the software is not covered, the applicant may submit a classification request through the CDSCO Medical Device Online Portal.
Applicable Standards
MDSW must comply with standards prescribed by the Bureau of Indian Standards or notified by the Central Government. Where no applicable Indian standard exists, conformity may be demonstrated against recognised ISO, IEC or other international standards. Where no prescribed or recognised standard is available, validated manufacturer standards may be used.
The Guidance refers to standards covering quality management, risk management, software lifecycle processes, health-software safety, cybersecurity, usability, AI risk management, AI management systems, information security, interoperability, labelling and post-marketing surveillance. The list is illustrative, and the standards applicable to a particular product depend on its intended use and design.
Quality Management System
The manufacturer must establish a documented Quality Management System covering the organisation and the entire software lifecycle, including design, development, product planning, configuration, deployment and maintenance.
The QMS should ensure that the software is developed consistently, risks are controlled, changes remain traceable, validation is documented, defects are managed, cybersecurity is maintained and patient safety is protected.
Domestic manufacturers must establish procedures and records demonstrating compliance with the QMS requirements under the Fifth Schedule of the MDR, 2017 and submit the required undertaking with the manufacturing-licence application. An overseas manufacturer must provide the prescribed QMS certification with the import-licence application.
The documented system should cover software architecture, Software Requirements Specifications, Software Design Specifications, source-code management, version control, release management and lifecycle procedures. Manufacturers should also maintain mechanisms for monitoring performance degradation, algorithmic drift, cybersecurity vulnerabilities and unintended outcomes after deployment. The SBOM should be periodically updated, together with procedures for identifying and addressing vulnerabilities affecting relevant software components.
Where MDSW creates, processes, exchanges, analyses or displays patient-health information, the Guidance states that developers and implementers should, where applicable, align with the Ayushman Bharat Digital Mission framework. This includes standards-based interoperability, consent-based access to health records, privacy and confidentiality, secure exchange of health information and integration with relevant ABDM registries.
Regulatory Route from Development to Commercialisation
The Guidance sets out separate regulatory routes for non-IVD and IVD MDSW. Both begin with product development or a prototype and proceed through the regulatory stages applicable to the product. A test licence may be required to manufacture or import limited quantities for testing, evaluation, demonstration, training, clinical investigation or clinical performance evaluation.
For an investigational non-IVD MDSW, the applicant must obtain permission for clinical investigation and subsequently permission to manufacture or import the investigational device before seeking a commercial manufacturing or import licence. For a new IVD MDSW, the corresponding stages are permission for Clinical Performance Evaluation and permission to manufacture or import the new IVD before commercial licensing.
Mode of Submission
Applications for test licences are submitted through the National Single Window System (NSWS). Applications for commercial permissions, manufacturing licences, import licences and registration for sale or distribution are submitted through the CDSCO Online System for Medical Devices.
The relevant application must be accompanied by the prescribed fee under the Second Schedule and the legal and technical documents required under the relevant provisions and schedules of the MDR, 2017.
Test Licence
A test licence allows the manufacture or import of limited quantities of MDSW for clinical investigation, testing, evaluation, demonstration or training. It does not permit commercial sale.
For manufacture of small quantities of MDSW for these purposes, the application is made in Form MD-12 through the NSWS, and the test licence is issued in Form MD-13. For import of small quantities, the application is made in Form MD-16, and the licence is issued in Form MD-17. The prescribed documents and fee must accompany the application.
For software, the proposed quantity may be stated as the number of installations, copies or intended deployments. The applicant must justify the quantity sought for the purpose stated in the test-licence application. A test-licence application for deployment or installation at multiple sites may also be filed in parallel with an application for clinical investigation.
Clinical Investigation and Clinical Performance Evaluation
Clinical investigation of an investigational medical device and Clinical Performance Evaluation of a new IVD require prior permission from the Central Licensing Authority.
For non-IVD MDSW, the application to conduct a clinical investigation is made in Form MD-22 and permission is granted in Form MD-23. For new IVD MDSW, the application to conduct a Clinical Performance Evaluation is made in Form MD-24 and permission is granted in Form MD-25. Applications are filed through the CDSCO Medical Device Online Portal with the prescribed documents and fee.
The Guidance also refers to exemptions from clinical investigation available under Chapter VII of the MDR, 2017. Such an exemption depends on the Central Licensing Authority being satisfied with the available safety, performance and materiovigilance data and there being no evidence or theoretical possibility of a difference in the behaviour and performance of the software in the Indian population.
Permission Before Commercialisation of Investigational MDSW and New IVDs
Before a commercial manufacturing or import licence can be granted, an investigational medical device requires permission in Form MD-27 against an application in Form MD-26. For a new IVD, permission is granted in Form MD-29 against an application in Form MD-28.
The applications must include the documents prescribed in Part IV of the Fourth Schedule and the fee prescribed in the Second Schedule. Where a clinical investigation or Clinical Performance Evaluation has been conducted in India, the clinical data generated from that study must also be submitted.
Manufacturing Licences
For commercial manufacture of Class A and Class B MDSW, an application is made in Form MD-3 and the manufacturing licence is issued in Form MD-5. A loan licence is sought in Form MD-4 and issued in Form MD-6.
For Class C and Class D MDSW, an application is made in Form MD-7 and the manufacturing licence is issued in Form MD-9. A loan licence is sought in Form MD-8 and issued in Form MD-10.
Manufacturing licences for Class A and Class B devices are handled by the State Licensing Authority, while Class C and Class D manufacturing licences fall under the Central Licensing Authority.
Class A non-sterile and non-measuring medical devices are exempt from licensing. However, registration under Chapter IIIB of the MDR, 2017 is required for their commercialisation.
Import Licence
An application to import MDSW for commercial marketing is made in Form MD-14, and the licence is issued in Form MD-15. Import licences for all four risk classes are handled by the Central Licensing Authority.
The application must be filed through the CDSCO Medical Device Online Portal with the prescribed fee and supporting legal and technical documents.
Licensing Authorities
The Central Licensing Authority handles test licences, import licences, clinical investigations, Clinical Performance Evaluations, permissions relating to investigational devices and new IVDs, and requests concerning special codes, neutral codes and risk classification. Sale and distribution fall under the State Licensing Authority for all classes.
For domestically manufactured products, Market Standing Certificates and Non-Conviction Certificates are handled by the State Licensing Authority for Class A and Class B devices and by the Central Licensing Authority for Class C and Class D devices. For imported products, these matters are handled by the Central Licensing Authority. Free Sale Certificates for manufacturing are similarly handled by the State Licensing Authority for Class A and B devices and by the Central Licensing Authority for Class C and D devices.
Legal Documentation for Commercial Applications
Applications to manufacture or import MDSW for sale, distribution or marketing must be filed through the CDSCO Medical Device Online Portal with the fee prescribed under the Second Schedule and the documents required under the Fourth Schedule.
Where a field does not apply, “Not applicable” or “NA” may be stated. However, where a required document itself is not applicable, the applicant must provide a reasoned justification. The Guidance also refers applicants to the application-specific checklists in Annexure A and the Tool Tips published by CDSCO for completing the legal forms and uploading supporting documents.
The Site or Plant Master File should describe the infrastructure and working environment used for software development, production and maintenance, including relevant equipment, information and communication networks, tools and facilities. The organisation chart and qualifications of relevant personnel must also be provided.
A domestic manufacturer must furnish details of the constitution of the company or firm together with a duly notarised copy of the ownership or tenancy agreement for the establishment or site.
For an import application, the authorised agent must provide a Power of Attorney together with the undertaking prescribed under Part I of the Fourth Schedule. The Power of Attorney must be authenticated by a First-Class Magistrate in India, the Indian Embassy in the country of origin or an equivalent authority through apostille.
Device Master File and Technical Documentation
The Device Master File should describe the software, its intended use, specifications and variants, and state its name, version and version-naming system. It should also identify the functions controlled by the software, programming language and compiler versions, hardware platform, operating system, COTS components, development lifecycle, intended user, patient population and use environment.
The file should describe the analysis methodology, software inputs and outputs, data flow, interoperability, use of network or cloud storage and the degree of autonomy. It should also explain the arrangements for installation, updates, error correction and change management.
Usability validation should reflect Indian clinical workflows and operational conditions. The manufacturer should consider language and interface accessibility, differences in operator training and expertise and infrastructure constraints in healthcare facilities.
Substantial Equivalence
Where a predicate MDSW exists, the applicant must submit a structured comparison between the proposed product and the predicate.
The comparison should cover intended use, risk class, software architecture, algorithm type, operating platform, input data, output characteristics, intended users, use environment, AI or ML training methodology, datasets, applicable standards and performance measures such as sensitivity, specificity, accuracy and robustness. Safety characteristics, cybersecurity controls and other relevant technical and clinical characteristics may also be included.
Where differences exist, the applicant must provide a scientific justification showing that they do not adversely affect safety, performance or effectiveness.
Where no suitable predicate exists because of the novelty of the technology, the software may be treated as an investigational medical device or new IVD and must follow the applicable clinical investigation or Clinical Performance Evaluation route before manufacture or import for marketing.
Essential Principles of Safety and Performance
The applicant must demonstrate conformity with the Essential Principles of Safety and Performance. Software should be developed, manufactured and maintained in accordance with the state of the art, taking account of rapid development cycles, cumulative changes, risk management, information security, safe updates, verification and validation.
Software used with mobile computing platforms should also take account of platform characteristics such as screen size, contrast, connectivity and memory, as well as environmental conditions such as light and noise. The manufacturer should specify the minimum hardware, network and IT-security requirements necessary for the software to operate as intended.
Risk Management
MDSW presents risks arising from its use across different technology and hardware platforms, its connection with other systems and datasets, frequent updates and large-scale deployment. In some cases, an update made available by the manufacturer may also depend on the user for installation.
The risk-management plan and report should address injury or harm, reduction in effectiveness, cybersecurity, privacy, integrity and availability of information, user interaction and the effect of incorrect, absent or delayed information.
The Guidance also recognises indirect harm. This may arise where erroneous, delayed or misleading software information, or a reduction in device effectiveness, causes injury or health damage without a direct physical failure. Unintended bias in a software output that affects clinical decision-making may also amount to indirect harm.
The risk-management process should continue throughout the total product lifecycle, and software change management and periodic updates should form part of the risk-management documentation.
The Guidance identifies clinical, algorithmic, data-related, operational, infrastructure and environmental risks. These include incorrect diagnosis or treatment recommendations, false results, bias, model drift, poor generalisability, low-quality training data, privacy breaches, user error, interoperability failures, cloud or connectivity problems and performance differences across settings or populations.
Algorithm Change Protocol
An Algorithm Change Protocol may be prepared where appropriate to explain how anticipated changes will be managed without compromising safety or intended use. It may cover data management, risk assessment, data collection, quality assurance, performance monitoring, statistical analysis, retraining and post-marketing monitoring.
The ACP may also address version tracking, verification and validation, update triggers and procedures, communication with users and rollback arrangements. It may form part of the Risk Management File. However, changes under an ACP remain subject to the post-approval change requirements. Major changes require approval, while minor changes require notification.
Device Design and Cybersecurity
Manufacturers should apply secure-by-design principles while developing MDSW and may conduct formal threat modelling, particularly for connected, cloud-based and interoperable software.
The product should use secure default settings and should be designed to maintain safe operation during cybersecurity incidents, including loss of connectivity, denial-of-service conditions or compromise of data integrity. A security-focused architecture review should identify attack surfaces, trust boundaries, external interfaces, APIs and interoperability points. Cybersecurity controls should be verified and validated against the relevant design requirements before implementation.
For SaaS products, cloud-hosting risks may be assessed on a case-by-case basis. The applicant should provide information on whether the service is hosted on a cloud server empanelled by the Ministry of Electronics and Information Technology. Manufacturers should implement baseline security controls for hosted environments to protect the confidentiality, integrity and availability of safety-relevant data and functions.
For on-premises deployments, the manufacturer may assess risks relating to the local hosting environment, infrastructure, network security, system maintenance, access controls, backup and recovery arrangements and software updates on a case-by-case basis.
Software Requirements and Design Specifications
The Software Requirements Specifications should describe what the software is intended to do, including its functional, performance, interface and technical requirements. The Software Design Specifications should explain how those requirements are implemented.
The documentation should allow the requirements, design, risk-management file and architecture to be traced to one another.
Versioning and Traceability
The manufacturer must maintain a system for identifying and tracing deployed software versions. The Device Master File should describe the versioning and traceability system and include the history of tested versions, relevant dates and a brief description of the changes made between versions.
Verification and Validation
The Device Master File should describe the software design and development process and provide evidence that the finished software has been validated. Where the tested version differs from the version included in the finished device, the applicant should explain the differences and assess their effect on safety and effectiveness.
Verification and validation should cover the relevant hardware configurations and operating systems, interoperability with other devices or systems and applicable cybersecurity controls.
For AI-enabled MDSW, the applicant should disclose the composition of training, validation and testing datasets, including their demographic distribution, geographic origin and clinical diversity, and state whether the data is real-world or synthetic.
Where a model has been trained or validated outside India, its applicability to Indian clinical settings must be justified. The documentation should address bias, generalisability and robustness across relevant Indian sub-populations and include the system-level test protocol, expected results, pass or fail criteria and final test report.
Clinical Evidence
The manufacturer should establish the clinical association or scientific validity of the MDSW by showing that the software corresponds to the clinical situation, condition, indication or parameter stated in its intended purpose.
Evidence may come from technical standards, medical literature, professional medical-society guidelines, systematic reviews, clinical investigations, Clinical Performance Evaluations, published clinical data or secondary analysis.
Technical or analytical performance validation should demonstrate that the software can accurately, reliably and precisely generate its intended output from the relevant input. Clinical performance validation should show that the output is clinically relevant to the intended purpose.
Details and outcomes of clinical investigations or Clinical Performance Evaluations may be included in the Device Master File. Evidence generated outside India may be supplemented by validation in representative Indian populations and intended clinical environments. Real-world evidence or evidence collected through post-marketing surveillance may also form part of the clinical evidence.
Software Labelling
The Device Master File should contain the labelling information required under Chapter VI of the MDR, 2017, including the applicable label, instructions for use or user manual, product brochure and promotional material. The software should be identifiable by its version, revision level and build or release date.
Where software is supplied on physical media, the applicable packaging must carry the particulars required under Chapter VI. Where the product does not have physical packaging, the required information may be supplied electronically through the software, a web address or another suitable method. The regulatory information may also be displayed on the primary landing page or through the app-store interface.
The software label should contain the applicable identifying and regulatory information, including the MDSW name, version or build number, manufacturer details, licence or registration information, release date, intended use and instructions for use.
For downloadable software, users should be given sufficient information for installation, including the download address and installation procedure. Version-control and access-control systems should allow deployed versions to be traced. Software without a user interface should be capable of transmitting the required labelling information through an API.
Fulfilment of Licence Conditions
A licence holder must comply with the conditions of the licence or permission under the MDR, 2017. Where the Licensing Authority imposes additional conditions at the time of approval, the applicant must submit a condition-fulfilment application through the Online System for Medical Devices with supporting documents within the period specified by the Licensing Authority.
Post-Approval Changes
Changes may occur throughout the MDSW lifecycle to correct faults, improve functionality or performance, respond to changes in the operating environment or introduce security patches.
Major changes require approval from the relevant Licensing Authority. These include changes affecting design characteristics, software or system requirements, clinical claims, input-data types, intended use or indications, certain labelling particulars, manufacturing or testing processes affecting quality, and software-version changes that affect safety, effectiveness or risk controls.
Minor changes must be notified to the Licensing Authority. These include bug fixes, security patches, performance retuning within validated ranges and other changes that do not affect intended use, safety or effectiveness.
A change in the constitution of the firm is treated as a major change. The applicant must notify the Licensing Authority and submit a fresh application for a new licence in accordance with the MDR, 2017.
All post-approval change applications and notifications, including software-version updates and changes contemplated under an ACP, must be submitted through the Online System for Medical Devices to the Central or State Licensing Authority, as applicable.
Post-Marketing Surveillance
Once MDSW is placed on the market, the manufacturer or importer must continue to monitor direct and indirect harm, reduction in effectiveness and vulnerability to intentional or unintentional security threats.
A post-marketing surveillance plan proportionate to the risk class of the device must be submitted. The plan should cover complaint handling, adverse-event reporting, software-patch tracking, AI-drift monitoring, cybersecurity monitoring and field corrective action.
Where the software does not meet its requirements, the nonconformity should be contained to prevent unintended use or distribution, corrected and investigated. Corrective action should address the cause and prevent recurrence, while preventive measures may also be introduced where a potential nonconformity is identified.
AI, ML and adaptive systems should be monitored for performance, bias and drift. Monitoring should include model-performance drift, error rates, false outputs, clinical safety signals and user feedback.
Manufacturers and importers should maintain documented procedures for post-marketing response, including recalls, bug fixes, cybersecurity alerts, software patches and Field Safety Corrective Actions. They should also establish mechanisms for collecting real-world evidence from Indian healthcare settings and monitor performance across the intended patient groups and healthcare environments.
The licence holder must report any suspected unexpected serious adverse event and the action taken, including a recall, to the relevant State or Central Licensing Authority within fifteen days of the event coming to its notice. An importer must also report, within fifteen days, specified foreign administrative actions arising from an adverse reaction, including market withdrawal, regulatory restriction, cancellation of authorisation or a finding that the device is not of standard quality.
Where MDSW placed on the market may be unsafe, the manufacturer or importer must immediately inform the appropriate Licensing Authority. A software recall may involve stopping distribution through some or all channels or uninstalling or decommissioning the software from affected networks or devices.
MDSW approved for marketing after a clinical investigation must be closely monitored after launch. The manufacturer or importer must also submit Periodic Safety Update Reports in accordance with the MDR, 2017.
Conclusion
The CDSCO Guidance brings together the regulatory requirements applicable to Medical Device Software under the MDR, 2017 and explains how they apply across the software lifecycle. The regulatory route turns primarily on the intended medical purpose of the software, its risk classification, whether it has a predicate device and whether clinical investigation or Clinical Performance Evaluation is required.
The Guidance also sets out the requirements that apply before and after commercialisation, from test licensing, clinical evaluation and manufacturing or import permissions to technical documentation, cybersecurity, software changes and post-marketing surveillance.
Regulatory oversight continues after the software is placed on the market. Software versions, algorithmic changes, cybersecurity risks, performance, adverse events and other post-market issues remain subject to the applicable requirements under the MDR, 2017 throughout the product lifecycle.
Authors: Manisha Singh and Shivi Gupta