With fast-developing technologies, software products have become essential to the healthcare industry. While the technical development of innovative software may be relatively quick, gaining market access for a software product within the scope of medical device regulations is no walk in the park. Do you know what determines if your software is regulated as a medical device?
To answer this question, let's start by revisiting the fundamentals of medical devices. Any product intended for medical purposes is considered a medical device and is subject to medical device regulations, regardless of whether it is software or hardware. The definitions of the medical intended purpose are provided in applicable medical device regulations (e.g. MDR 2017/745 in Europe or Food, Drug and Cosmetic Act in the US) and may vary slightly from one jurisdiction to another.
As an initial step, you’ll have to check the exact definitions of the applicable regulations against the product’s intended purpose(s). With some simplifications, a medical intended purpose encompasses diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation or compensation of a disease, injury or disability. If the device relates to any of these, you are probably looking at a medical device. For example, software reading the output of a thermometer and generating an alarm below a given temperature will not be regarded as a medical device if the intended purpose is to warn you when your ski chalet temperature drops below freezing temperature. The same software is (thankfully) considered a medical device if intended to alert nurses or doctors that a neonate’s body temperature drops below a safety-critical level: same product, different intended purposes, and different regulatory requirements.
It looks pretty straightforward, doesn’t it? As always with medical devices, the devil is in the details…
Let’s start with the unavoidable exceptions to the rule. Medical device regulations govern not only products with a medical intended purpose as defined above but also some categories of products without medical intended purposes. Examples are products falling within the scope of EU MDR Article 1(2), further specified in Annex XVI. While the product categories listed in Annex XVI are hardware-based, a software component included in such products and participating in the intended purpose or qualifying as an accessory to such products would also be regulated (Article 1(2) and (4)). For example, software driving a liposuction machine is likely considered a medical device.
Additionally, the EU and the US regulations make it clear that (software) accessories to medical devices are regulated even when they do not have a medical purpose on their own. For example, software explicitly intended for calibrating a medical device is regarded as an accessory and, therefore, subject to medical device regulations.
In many cases, it may be challenging to determine if the software has a clear medical intended purpose. What about a risk calculator that provides a prioritization recommendation for hospital staff based on data coming from other medical devices? What about software used in the ICU or a non-life-threatening/time-critical context? The regulators have produced numerous guidance documents to support software manufacturers in performing their qualification evaluations in these cases. The MDCG 2019-11 guidance in the EU provides examples of regulated and non-regulated software. It clarifies that software acting on (medical) data other than “storage, archival, communication and simple search” for the benefit of individual patients will likely be regulated as a medical device. Also, the so-called “Borderline Manual” lists products (software and hardware) for which the MDCG’s Borderline and Classification Working Group came to an official qualification conclusion. The US FDA is also proposing several guidance documents clarifying the qualification criteria of borderline cases, such as general wellness products, medical device data systems, or clinical decision support software.
Determining whether a software product qualifies as a medical device is critical to identifying the applicable regulatory requirements and creating an appropriate go-to-market strategy. However, unambiguously answering this question is often complex, as many software products are borderline cases. A clear definition of the product’s intended purpose, functionalities and interfaces/boundaries is key to understanding if and how the product qualifies as a medical device.
Valentin Chapuis
Senior Quality & Engineering Support