All you want to know about classification of software as medical device

Dynamic progress in healthtech and MedTech has led to a transformative surge of the medical devices landscape, propelling the rise of new and innovative medical devices. However, preceding the amendments to the Medical Devices Rules, 2017 (“MD Rules”), only a handful of medical devices were regulated, with software escaping regulatory scrutiny. Recognising the myriad instruments affecting individual and animal health, the Government found it imperative to extend regulations to this rapidly evolving realm.

The regulatory regime surrounding medical devices, as it existed post the introduction of the MD Rules, changed on February 11, 2020, with a revision in the definition of “drugs” under the Drugs and Cosmetics Act, 1940 (“D&C Act”). The revision, designed to bring all medical devices under the ambit of the regulatory regime prescribed under the MD Rules, took effect from April 1, 2020. This seemingly innocuous amendment categorised as “drugs” all devices (including software) intended by their manufacturer to directly or indirectly assist in the diagnosis, prevention, monitoring, treatment or alleviation of any disease or disorder, etc., of human beings or animals. This new regime, which expanded the scope of regulatory coverage to encompass all medical devices, indicated the Government’s concerted effort to enhance the safety and efficacy of medical device standards across the board.

The Delhi High Court (“DHC”) judgment in the matter of Surgical Manufacturers & Traders Association v. Union of India[1]alsoupheld the Government’s decision to bring all medical devices within the ambit of the expression “drug” in terms of the D&C Act. The DHC referred to sub-clause (iv) of Section 3(b), which empowers the Central Government to bring within the ambit of the expression “drug” all “such devices” intended for internal and external use in the diagnosis, treatment, mitigation, or prevention of disease or disorder both in human beings or animals, although, after consultation with the Drugs Technical Advisory Board (“DTAB”). The DHC also did not find any words of limitation in the provision that could confine the expression “such devices” to some and not all devices. Moreover, the statute (being the D&C Act) confers the necessary power on the Central Government, ring-fenced with the obligation to consult the DTAB. The Government’s reasons for bringing all medical devices within the purview of the expression “drug” are manifold, including a desire to align itself with the international regulatory regime and to further the interest of the patients. The Supreme Court reaffirmed DHC’s position on the matter and declined to interfere with the DHC’s ruling.

Classification of software as medical device
The CDSCO, in September 2021, published a list of 60 software along with their risk classification and intended use. This list aimed to classify software as medical devices based on their intended use, associated risk, and other parameters detailed under the regulatory regime. The MD Rules also regulate software that drives or influences the use of a medical device and any add-ons to the medical-device software.

This list of software as medical devices served as the constructive first step in enabling the industry to understand the categories and classes of software being regulated. However, numerous questions have remained at the forefront for industry stakeholders and entities in the sector about the extent of possible compliance with the regulation, such as the rigorous manufacturing compliance, GMP requirements, quality and raw material control, inspections, advanced technical documentation, lifecycle updates, and labelling requirements prescribed for medical device manufacturers and importers.

Recently, the CDSCO released an updated Frequently Asked Questions document in relation to medical devices. These provide some clarity about some of the general concerns and challenges facing industry stakeholders. For example, the document clarifies that all software qualifying as a “drug” under the D&C Act need a license under the MD Rules and are not exempt from the prescribed labelling requirements. In case of any change (including updates) in the version of an “approved software,” the manufacture or importer would have to comply with additional requirements as prescribed under the MD Rules. The ambit of the regulatory regime governing software as medical devices stems from the intention of the software manufacturer. However, ambiguity and inherent difficulty exist in classifying modern, multifunctional software as medical devices. In response to a query relating to the regulation of software meant for monitoring of fitness, or wellbeing or wellness purposes, the CDSCO has stated that software that attract the definition of “drug” are regulated under the MD Rules.

The regulation of software as medical devices is currently at a nascent stage in India, and much ground needs to be covered before enforcing a feasible regulatory regime that is customised for software medical devices and addresses the medical software industry’s needs and challenges. The Government’s current “one shoe fits all” approach to regulate both hardware and software medical devices would be challenging to follow until software-specific regulatory requirements are prescribed. The Government might need to revaluate its decision to jointly regulate hardware and software or, at the very least, imminently revise the license forms/terms and conditions of manufacturing and sale licenses and prescribe suitable, software-centric manufacturing and distribution compliances. It could consider providing further clarity to the software industry by publishing a comprehensive set of guidelines that illustrate the regulatory pathway and mandatory compliances for medical software manufacturers – beginning from prototype development to licenses for commercialisation. Cyril Amarchand Mangaldas