Warning! Your software may be a medical device!
Unless you have spent time working with medical device legislation in the past, the idea that software could be a medical device may be rather unexpected — a medical device is perhaps more traditionally viewed as a hardware product. Nonetheless, it is the case. Software is increasingly capable of medical functions such as making or assisting diagnosis, interpreting medical data, forming a prognosis, monitoring disease progression, and many others. It therefore makes sense to regulate software in line with physical medical devices.
Furthermore, the introduction of the Medical Device Regulation (EU) 2017/745, fully implemented from May 2021, expands the definition of medical device and makes it even more likely that software will fall under its jurisdiction.
The EU MDR represents the largest overhaul of medical device legislation in decades. The MDR introduces a wide range of changes including an extended definition of what constitutes a medical device. Following significant advances in the complexity and availability of software over the past decade, many types of medical software will fall within this extended definition and be subject to the full scope of the MDR.
So if you have a software product that performs a medical function, how can you determine if your software will be classed as a medical device? And what do you need to do to meet your obligations under the MDR?
Is my software a medical device?
Not all software associated with the provision of healthcare will be classified as a medical device. Medical device legislation is intended to apply only to software whose expected purpose is in line with the definition of “medical device” provided in Article 2 of the MDR. However, because medical software performs such a vast array of purposes across healthcare, working with the Article 2 definition can be challenging.
Understanding whether or not the MDR will apply to a product is a key first step in developing a product compliance strategy beyond May 2021. In this article we set out some basic principles that may help developers understand whether the MDR applies to their products.
First of all, software must have a medical purpose on its own in order to be classified as a medical device. This is important to consider with respect to ‘stand-alone’ software such as a diagnostic application, but even more important when software is an integral part of, or associated with, a hardware device. Determining whether or not software has a medical purpose depends partly upon the intended purpose specified by the manufacturer.
Secondly, it is important to consider the extent to which medical value is added to data entered into the software. For example, simple archive and retrieval software that stores serial blood sugar values without manipulating the data does not add real medical value and would not normally be classed as a medical device; whereas, if that same software highlighted worrying trends in the data and advised when a hospital visit may be needed, this is likely to be held as medical value and class the software as a medical device.
Direct autonomous medical actions performed by software are another factor that will draw a software product under the definition of a medical device. For example, an app that analyses skin rashes to make a diagnosis would clearly be classed as a medical device.
For the purposes of understanding whether or not an individual software product may be subject to the MDR’s rules, it may be helpful to consider several categories of function and purpose:
- Basic support/admin software
- Simple archive and retrieval
- Archive, retrieval and modify
- Data interpretation, advice and/or call-to-action
- Independent ‘smart’ diagnosis/prognosis/analysis
- Mixed purpose/modular software
- Combined hardware/software
- Closed loop products
- Contraceptive support
What needs to be done if software is a medical device?
If a software product is classified as a medical device, then the full range of provisions in the Medical Device Regulation 2017/745 (“The MDR”) will apply to the product. This will mean implementing a number of systems that may be unfamiliar to software companies, including:
- developing a Quality Management System
- implementing a Post-Market Surveillance (PMS) system to monitor performance of the product
- designing Post-Market Clinical Follow-up and Vigilance systems as components of PMS
- performing a Clinical Evaluation of the product and submitting a Clinical Evaluation Report (CER)
It will also be necessary to understand how to work with MDR Annex VIII to determine risk classification for the product, as well as learning how to use MDR Annex I that lists General Safety and Performance Requirements that must be adhered to for every product.
Where can I find help developing an MDR strategy?
Video: How to build an EU MDR compliance strategy for your medical devices
Working with the MDR is likely to be a daunting prospect for many software companies. If you find yourself wondering how to meet MDR requirements for your products, Mantra Systems is your ideal MDR compliance partner. We have extensive experience working with medical device legislation for all kinds of medical devices, including and especially software. We have a team of expertly-trained medical professionals who will work with you to build a tailored MDR compliance strategy for your software. Contact us to speak to our medical team to discuss your requirements further.
We also have a range of free resources including an EU MDR Compliance Guide written by our medical experts, and a free-to-download Software as a Medical Device White Paper.
