Medical device legislation demands increased supervision of software

An increasing number of software products for healthcare professionals and for patients, gain a foothold in the healthcare sector. However, to get any real benefit from the software it is important to be able to distinguish between good, effective apps and less good, and possibly also less secure apps. We are thus seeing an increasing focus from several sides towards assessment of the quality of such software. The EU regulation (EU) 2017/745 on medical devices there is a focus on numerous software applications, and the legal requirements for marketing software with a medical purpose have been tightened.

Amended risk profiles

The EU legislation divides medical devices up into risk categories. In the current legislation Class I, IIa, and IIb are the most relevant for software. The legislation is structured so the lower the class, the less harm the software will be considered to cause. In line with this, Notified Bodies conduct more checks on high risk classes than on lower risk classes. 

In the EU regulation more focus has been placed on software, which has been given its own set of rules for risk classification. The requirements have also been tightened so that many apps and other software applications which are currently Class I will now be reclassified as Class IIa/b or even Class III. 

A typical example of software that will be reclassified, is a smartphone app which via manually entered data can generate information to help doctors in their decision making concerning specific patient diagnosis or treatment. This type of app has no interface to other devices and can - under present legislation - be classified as a Class I medical device. As the app is “intended to provide information which is used to take decisions with diagnosis or therapeutic purpose,” according to the regulation, it will end up in either Class IIa, Class IIb, or Class III.

There are many of these ‘decision-supporting’ apps on the market, and as many of them are presently classified as Class I, they will be reclassified.

One example of an application that will switch classes is an app for diagnosing sleep apnea, which will move from Class I to at least Class IIa. Another example is an app that helps to choose and calculate medicine dosage. This will move from Class I to Class IIa, IIb, or III. Patient data modules that are intended to provide information related to diagnosis and treatment, or give follow-up warnings for specific patients, are currently in Class I or IIa and can, depending on their purpose, end up as Class III.

The software applications that are most likely to remain in the lowest risk class are apps that are virtually harmless, even if an error should occur in the software, e.g. an app with specific workout suggestions.

Greater demands on the software manufacturer

When a product ends up in a high-risk class, the legislation increases the requirement for documentation and quality assurance.

In order to sell software in Class I the software manufacturer (often the same as the developer) must apply for authorisation with the Danish Medicines Agency. It is expected that the developer can produce technical documentation in relation to the applicable standards, including a risk assessment, test of the software, and evidence that the software can be used for the intended purpose. 

Software in the high-risk classes is subject to certification via a Notified Body, who reviews all the documentation regarding the software and checks whether the company has implemented a system for quality control and quality assurance in accordance with ISO 13485. The Notified Body will visit the company to check whether the quality system’s processes are being followed in practice. 

Additional demands are placed on Class III products, especially in regard to supplying evidence that the software is secure and clinically effective, and this information will be published and also updated at least once a year. More importantly, according to the wording of the regulation, a clinical trial will almost always be required for Class III products. Clinical trials are time consuming and it will therefore take longer to get the software onto the market. By comparison, clinical evidence for Class I software can often be based on standard protocols and references to specialist literature.

However, apps that may remain in Class I after the regulation cannot relax completely. Class I products must be updated to follow the regulation by May 2020 at the latest. One of the biggest changes is that all manufacturers must now implement a quality management system consisting of processes and tools to ensure product quality and avoid errors, for example in the R&D phase. Users of health apps have good reason to be please about this.

Check the CE mark

Doctors, nurses and other healthcare personnel and not least the patients should, once the regulation is in effect, have greater peace of mind when using desktop software and apps for smartphones. However, as a user, you should still remember to check whether the software is CE-marked. The CE mark is often located on the start-up screen or in the ‘About’ menu. In Class I software it will simply read ‘CE’. In Class IIa and higher classes it will read ‘CE-XXXX’, whereby the four digits indicate the number of the Notified Body that has issued the certificate. Based on the CE mark the user can thereby see whether the software is Class I or in a higher class. 

Consequences of the rules

For the software manufacturers (which have the overall responsibility for the development of the software) it will be a lot more expensive and time-consuming to launch a Class IIa/b or III product compared to a Class I product. It is therefore plausible that we will see a drop in the rate at which apps are brought onto the market. The number of app providers could also be expected to drop, which is not quite as good news for healthcare personnel and patients. However, this is still only speculations, as we have not yet seen how the regulation will be carried out in practice. 

Many of the Class I applications used today will expire in two years. This could prove critical. The current interpretation of the legislation means that all Class I products must be taken off the market unless they are upgraded to follow the regulation. How this will be handled legally remains to be seen, but one can only urge software providers to keep the regulation in mind and prepare for it.