Once software enters the market, software updates are inevitable. New security vulnerabilities, whether or not critical, are constantly discovered or introduced and require updates. Often updates are also necessary to improve the user experience, to fix software bugs (there is no 100% error-free software code after all) or to guarantee continued compatibility with third-party equipment or other software. And, of course, software updates may also introduce new functionalities. As users of smartphones, computers and other smart gadgets, we have already become so used to this, that we automatically install these updates (or have them installed) and hardly notice them anymore.

This is not much different with medical apps; updates are often installed unsuspectingly. With more complex medical software, this is obviously different and the installation of updates requires IT support. Especially in the world of medical software a more critical view is essential. Without updates, vulnerabilities remain and the safety of patients or patient data can be endangered. The updates themselves, however, can also introduce new vulnerabilities. With the ever-increasing digitalisation of healthcare this raises the question how updates of medical software should actually be handled. We will discuss this in more detail in this publication. 

Background: legislation concerning medical devices

The rules for placing medical software on the market are set out in the Directive concerning medical devices 93/42/EEC (“Directive“) and Dutch laws and legislation based on the Directive. If software qualifies as a medical device,[1] a conformity assessment procedure must be followed before the required CE marking[2] can be adopted. Only after that the medical software may be put on the market.

The steps to be taken when going through the conformity assessment procedure depend on the risk class in which the device falls (I, IIa, IIb or III). Classification is based on the risk: the higher the risk for the patient if the medical device fails, the higher the risk class. Once the risk class of the medical device has been determined, an assessment route must be established.[3] Based on the risk class, the manufacturer itself can choose a suitable route. For some (higher) risk classes, an external party, a so-called ‘notified body‘, must be involved in the conformity assessment. 

But what if the conformity assessment procedure has been completed, the medical software has been lawfully placed on the market and the manufacturer wishes to make changes to the software? For example, security patches are regularly required and subsequently updates are developed and implemented. This raises the question whether the entire procedure must be repeated. 

Rules for making changes to medical software

The Directive and further laws and legislation on medical devices do not provide clear rules for changes to approved and marketed devices. Some assessment routes require additional approval of the notified body for changes that may affect the conformity of the design with the essential requirements of the Directive (these are listed in Annex I) and/or the conditions of use.[4] For other routes, nothing has been arranged. 

The answer to our question can therefore be found in a guideline published by the European Commission on European product regulations (“Blue Guide“).[5] This document stipulates that ‘new products’ must be subject to a full conformity assessment. A product may be considered new if it has been subject to important changes or overhaul aiming to modify its original performance, purpose or type.[6] 

Maintenance operations are considered outside the scope of the legislation insofar as the original performance of a product is changed within the intended use, range of performance and maintenance originally conceived at the design stage. Provided that the product placed on the market is not changed in such a way that it no longer meets the applicable requirements, any software updates and repairs can be equated with aforementioned maintenance operations. 

Conclusion

It can be concluded from the above that, depending on whether a software update does not change the medical software to such an extent that it no longer complies with the applicable requirements, it qualifies as ‘maintenance operations’. Insofar as the maintenance operations only change the original performance of a product within the intended use, range of performance and maintenance as intended during the design stage, no new conformity assessment is required. 

The majority of software updates and security patches will qualify as maintenance work that does not change the intended use. Therefore, no new conformity assessment is required. For updates that add functionality to the software, for example, this is less obvious. We recommend that in cases of doubt updates are submitted to the notified body. 

Comments

Two comments should be made on the previous conclusion. Firstly, the Blue Guide is a non-legally binding communication from the European Commission. Binding interpretation of EU legislation is the exclusive competence of the Court of Justice of the European Union (“ECJ“) and the ECJ has so far not expressed an opinion on changes in medical software. 

Secondly, Regulation (EU) 2017/745 (“Regulation“) was adopted on 5 April 2017.[7] Among other things, the Regulation replaces the Directive and will apply as of 26 May 2020. It is questionable whether the Blue Guide, which is not focused on the Regulation, can also be used in its interpretation, or whether the European Commission will publish a new version of this document. 

The Regulation also introduces a Unique Device Identification (“UDI“) system requiring all medical software to be equipped with an UDI Device Identifier (“UDI-DI“[8]), and an UDI Product Identifier (“UDI-PI“[9]).[10] The UDI must be assigned to the device itself or its packaging.[11] 

A new UDI-DI shall be required whenever there is a modification that changes (a) the original performance, (b) the safety or the intended use of the software or (c) the interpretation of data.[12] Minor software revisions shall require a new UDI-PI and not a new UDI-DI. To define minor software revisions, the Regulation refers to bug fixes, usability enhancements that are not for safety purposes, security patches or operating efficiency.[13] 

Want to know more?

Our Digital Health team has extensive experience in the field of ICT contracts, privacy, financing and relevant healthcare laws and legislations. Contact Dimitri van Hoewijk, Louis Jonker or Lars Leemeijer.