The Challenges to Medical Device Software Regulation in ‘Digital India’

Sagar Suresh Kumar
MUNner’s Daily
Published in
5 min readOct 25, 2020
PC: Fernando Zhiminaicela from Pixabay

Although a pioneer in several fields, India’s entry into medical device regulations was late compared to its global peers. Before the Medical Device Rules(MDR) in 2017, medical devices had no specific governing regulations, and the Drugs and Cosmetics (D&C) Act of 1940 and Rules of 1945 till then regulated only a handful of devices such as contraceptives, hypodermic syringes, and so on. The MDR 2017, although inspired by its western predecessors, the European Union (EU) MDR and those of the US FDA, was made with the intention of invigorating the domestic production of medical devices, and thus, fits well into the government’s ‘Make in India’ initiative.

As per the new rules, to obtain a license from the Central Drugs Standard Control Organization(CDSCO), a range of quality requirements are to be met by medical devices before market entry. These include the classification of devices into 4 categories based on the risk of using them, the need to conform to Quality Management Standards, and so on.

With regards to what constitutes a medical device, from April 1, 2020 onwards, all devices including software and accessories intended for the diagnosis, prevention, monitoring, and treatment of any disease, disorder, injury, or disability will be notified as ‘drugs,’ under the purview of the D&C Act and the amended MDR of 2020.

So, in “Digital India”, with so much talk about software regulation with regards to issues such as privacy, data protection, etc., how about that for the medical field? Firstly, let us look at developments in the west, and then, how India can learn from them to develop a framework that suits its interests.

The Rise of Medical Software Regulation and Issues

It was the Therac-25 radiation accidents in the US that instilled a worldwide consensus for software-specific regulations in the medical field. The Therac-25 was a computer-controlled radiation therapy machine that resulted in at least 6 accidents involving death or serious injury, between 1985 and 1987, due to large overdoses of radiation.

AECL, the manufacturer, reused the software from the previous Therac versions and felt only a hardware-specific risk analysis was required and thus, overlooked the software race conditions which led to the overdose. The incidents shed light on the then-existing blind trust in reused and off-the-shelf software and led to the creation of the IEC 62304 standard, which specifies life cycle requirements for medical software, harmonized by the both the US and EU.

In its push for safe software, the EU, in its updated MDR of 2017, put forward Rule 11, in which most of the software previously classified as the lowest class (class 1) would now be classified as class 2 or higher, much to the dismay of small-scale firms and start-ups who may not be able to afford and overcome the regulatory formalities associated with higher-risk devices such as the need to involve notified bodies for conformity assessments.

Rule 11 of EU MDR 2017/745. Evidently, it is extremely unlikely for a device to be classified as class 1.

As per Rule 11, software intended for physiological monitoring or used to make decisions with a diagnostic and therapeutic purpose, which would include something as simple as software to operate a thermometer, are to be classified higher than class 1. Also, if the decision taken using the software may have impacts that lead to death or serious injury, it must be classified as the highest class (3).

So, theoretically, even if a piece of software performs a harmless function such as diagnosis based on a test result, the rule applies if the resulting decision could have the aforementioned impacts. This is rather problematic as there are few decisions in the medical field that could never lead to death or irreversible deterioration.

Hence, experts have warned that the Rule 11 of the EU MDR 2017/745, which may treat software that calculates drug dosages in the same line as one that controls an implanted cardiac pacemaker, will affect small-scale firms and hamper European innovation by leading to a more monopolistic market.

In the end, only something as trivial and borderline medical device like a fitness training app may fit the class 1 criteria. Conversely, the FDA has been following a strategy of digital deregulation of medical software.

Developing a Pro-Innovation Regulatory Approach in India

Coming back to India, which currently has a booming start-up eco-system, it is unlikely the government will go for a hardline approach as taken by the EU. Bearing in mind incidents such as the Therac-25 accidents, they should definitely recognize software as a distinct class of medical devices and introduce a specific regulatory framework. However, ascertaining the finer details is where the challenge truly lies. In bringing a solution, it is absolutely necessary for patient safety to come first, but at the same time, a lack of medical devices could affect patient and community health in the long term.

Perhaps, instead of the EU’s decision-focused classification, India can adopt a risk or functionality-based approach by taking inspiration from the IMDRF risk framework for medical software. Software that aids in the diagnosis of non-serious conditions such as astigmatism can be given the lowest risk classification, and those that don’t possess a clinical risk can be relieved of regulations.

Medical Devices are currently valued at USD 5.2 Billion and are projected to reach USD 50 Billion by 2025. PC Narendra Modi at Flickr. Licensed under CC BY-SA 2.0.

The current directive is too broad in its scope and can create issues in determining whether a particular software can be even considered a medical device. For example, an application with no clinical risk such as one that allows users to check their symptoms or learn about medicines would still need to regulated as a medical device, which seems to raise similar issues like that of Rule 11 of the EU MDR. Another issue that needs to be addressed is that — will medical software be monitored under the Drugs (Prices Control) Order, 2013? If so, developers may no longer be in control of the prices of their software.

It is also necessary for the regulations to be up to date with the recent technological advancements and ethical concerns, especially for such a rapidly changing field like software. Take the FDA for example, which recently developed a framework for using artificial intelligence and machine learning in medical software.

To conclude, an efficient regulatory framework can help India harness its burgeoning IT and digital potential to be a medical software manufacturing powerhouse, and thereby set a fine example for the west and the rest of the world.

Read More

.

.

.

We are now on LinkedIn! Do follow us there!

Follow us on Medium for more for International events, news, MUN tips and tricks, and detailed analysis. Get in touch with us on Social media to stay in the loop -

Facebook| Instagram|Telegram Channel |YouTube|Twitter|LinkedIn.

We also invite guest writers to publish their material via this blog!

--

--

Sagar Suresh Kumar
MUNner’s Daily

MS Biomedical Eng from UniGlasgow| Writes on diverse issues with a focus on technology and healthcare. Research Profile: https://orcid.org/0000-0003-2841-1488