CE marking is not a choice: the importance of safe innovation in healthcare
Written by Derek Tersmette MD LLM, dr. Joris Janssen and prof. Daan Dohmen, March 19th 2020
The use of digital care has accelerated rapidly. All manner of medical applications (“apps”) have found their way into the doctor’s office. Excellent news. But this rapid development also raises questions. Because, as a healthcare provider, how do you know that the software you use meets all the requirements for safety and quality? After all, in certain cases, software is deemed a ‘medical device’ according to the law. This means that a software product and its developer must comply with strict requirements. But not only that. Healthcare providers also have a responsibility. And that responsibility is far from negligible. This article provides an explanation and some specific examples.
Apps as medical devices
“Software is a medical device if the manufacturer has made the software for medical use…”, states the website of the Dutch Government. For such software, a CE marking is mandatory. This marking signifies that the manufacturer (or developer) claims that the product complies with European requirements. In accordance, there are two important questions that healthcare providers should ask themselves when getting started with a particular app.
Question 1: Is the app considered a medical device?
Not all apps are medical devices. The Medical Devices Act (Wmh) stipulates, in short, that a product (such as an app) is only a medical device if it is intended by the manufacturer (developer) for a medical purpose, such as the diagnosis, treatment or monitoring of a disease or disability (Article 1 Wmh). Without getting too legal, as a general rule of thumbany instrument, device or equipment, any substance or any other article intended by the manufacturer for use in humans to detect, treat, relieve or prevent disease or disability is a medical device. Software that has such a medical purpose is therefore also a medical device.
To illustrate: a sports app that keeps track of your activity is not a medical device, as it serves no medical purpose. But if this app predicts the risk of you suffering from heart disease based on the logged values, then the app is a medical device. And if the data in the app is intended for therapeutic purposes (for example, alerting a healthcare provider, monitoring the health of a patient or promoting patient self-care), the app is also a medical device. There are several flowcharts that can help with this assessment, such as the flowchart that NICTIZ released previously (in Dutch).
Question 2: Which class is the medical device (app)?
Once it has been established that a product is a medical device, the Medical Devices Act becomes applicable. It is then important to determine in which risk class the medical device falls. This risk class dictates which requirements apply for certification. For example, whether the developer may affix a CE marking directly, or whether this requires an external audit by a competent authority, or a ‘notified body’. Much can be said about the classification, but generally, under the European Medical Devices Directive (93/42 EEG), or MDD (see more below), software that does not have a measurement and analysis function qualifies as class I, and software that does have a measurement and analysis function as class IIa or higher.
Intended use
When determining the class, the element of ‘intended use’ is very important. This intended use must be declared by the developer and partly determines in which risk class a medical device falls. But the healthcare organisation or healthcare provider that uses the software should be aware of this, too. After all, the ultimate use of the app within the medical process must be in accordance with the intended use, as declared by the developer. The functionality that the software offers and how the developer markets the app, for example, the claims made on the website or social media, are similarly important.
Specific example
An app that is used in medical care with the aim of collecting medical data is a class I medical device. This means that the manufacturer (developer) carries out the certification personally. If the applicable requirements are met, the software may bear the CE marking as a class I medical device. However, if this software is intended to monitor vital physiological functions, such as blood pressure or heart rate, and includes a dashboard available to healthcare providers to display alerts for patients with anomalies in vital signs, then the software is a class IIa medical device. This means that an external audit by a notified body is required before the software can bear the CE marking. In that case, the requirements are much higher to guarantee safety and quality.
The transition from MDD to MDR
Without intending to complicate matters, it is also important for a complete picture to realise that changes in legislation are currently taking place. The new Medical Devices Regulation 2017/745 (MDR) will replace the existing MDD. The Medical Devices Act and the accompanying Medical Devices Decree will be amended accordingly. Originally, the MDR was intended to take effect in 2020, but this has been postponed due to corona. The new regulation will enter into force on the 26th of May 2021. The new rules are stricter with regards to the classification of a medical device: software that arrives on the market after the 25th of May 2021, has a high chance of being classified as class IIa or higher. In addition, there are more requirements that a medical device must meet. For existing software certified under the MDD, the developer has until the expiry of the current certificate (i.e., until 2024 at the latest) to make the transition from old to new regulations and obtain certification of the product under the MDR. Healthcare providers may continue to use that software as long as this requirement is met.
What does this mean for the responsibilities of innovative healthcare providers?
Numerous applications and apps have recently arrived on the market in the healthcare sector. That is wonderful, of course, but healthcare providers also bear a vital responsibility to ensure that these applications are safe. The recognised certification that follows ISO/NEN standards is certainly important, but it is not sufficient to actually use software that qualifies as a medical device in medical care. After all, when using the software, healthcare providers must also assess whether the aforementioned legal requirements are met.
Authorities, such as the Healthcare and Youth Inspectorate (IGJ) in the Netherlands, monitor both manufacturers and healthcare providers, and can impose fines or even prohibit the (use of) software if it fails to comply with legal requirements. As a healthcare provider, it is therefore very important to look closely at how you use certain software, what intended use this software has and whether the intended use of the software corresponds accordingly. This also means that adjustments in the functions of software at the request of the healthcare provider cannot be implemented just like that. In fact, under the rules of the MDD and MDR, additional tests must be carried out if software is substantially modified or given new functions, as the (renewed) software can even end up in another risk class. For healthcare providers, the Dutch Inspectorate for Healthcare and Youth (Dutch: Inspectie Gezondheidszorg en Jeugd) has drawn up the assessment framework ‘Use of e-health by healthcare providers’, which includes the implementation and use of e-health products and services (in Dutch). It is important for healthcare providers to take this into account during innovation processes.
And what should innovative companies take into account?
Companies need to be aware of their obligations. A great deal can and may be achieved in our current innovation climate, but these companies remain under the control of the authorities and therefore have the responsibility to comply with legal requirements. First of all, this means that they cannot offer software that does not comply with the requirements. And secondly, they are also unable to make claims or promote their software in any way that contradicts the law.
CE marking is therefore not a choice!
In the past year, we have put a great deal of effort into our certification. This is necessary for us to be pioneers. As well as initiating adjustments for the MDR, we have expanded our certification and aligned it with our intended use in the fields of monitoring and self-care. For this, we obtained certification in a higher class. In November 2020, we received the CE marking classifying Luscii vitals as a class IIa medical device. The audit was performed by KIWA, who will continue to conduct audits annually. A major task for sure, but an important step in responsible innovation. After all, safety and quality are crucial to innovation in healthcare.
About this article and the authors
This article was written by Derek Tersmette MD LLM, dr. Joris Janssen and prof. Daan Dohmen. Joris and Daan are co-founders of Luscii and Derek is Lead Link of the compliance circle within Luscii. Besides his work at Luscii, Daan is professor in Digital Transformation in Healthcare at the Open University and holds a PhD (cum laude) in behavioral science. Joris is the architect of Luscii’s holacracy and ways of working including the introduction of most of the mentioned tools. He holds a PhD (cum laude) on Human Technology Interaction from Stanford and Eindhoven University of Technology and is an inventor on 4 patents. Derek is a Medical Doctor and Lawyer. He joined Luscii in 2020 as Lead Link of the compliance circle, responsible for compliance including all quality, privacy and safety processes and Luscii’s certifications like ISO, NEN and CE. In Luscii’s Medium publication people working at Luscii share their experiences on creating a company that is not only successful from a business point, but also creates sustainable societal impact and strives to be a really great place to work and grow for individuals. More on Luscii can be found by clicking here.
