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.
[1] In order to determine whether software is a medical device and, if so, in which risk class the product belongs, the Directive, implemented in the Netherlands in the Medical Devices Act (“Wet op de medische hulpmiddelen”) and the Medical Devices Decree (“Besluit medische hulpmiddelen”) must be taken into consideration. The Directive has been further explained, among others, in the Manual on Borderline and Classification in the Community Regulatory Framework for Medical Devices, the guideline of the European Commission MEDDEV 2.1/6 and case law of the European Court of Justice of the European Union. About the qualification “medical device”, we wrote in previous publications (https://www.vandoorne.com/Kennisbank/nieuws/ag-hof-van-justitie-eu-verduidelijkt–wanneer-software-kwalificeert-als-medisch-hulpmiddel/) and (https://www.vandoorne.com/Kennisbank/2017_12/wanneer-is-software-een-medisch-hulpmiddel/).
[2] CE marking is an important indication (however, it is not proof) that a product complies with the legislation and allows the free movement of goods.
[3] Article 11 of the Directive refers to Annexes II up to and including VII for each risk class for the conformity assessment routes.
[4] Article 4.4 Annex II to the Directive.
[5] Communication from the Commission – Guidelines for the implementation of EU product rules (“the Blue Guide”) 2016 (http://ec.europa.eu/DocsRoom/documents/18027?locale=nl), p. 17 – 19).
[6] Blue Guide, p. 17.
[7] Among other things, the Regulation will amend the classification rules. Just as under the Directive, the risk class under the Regulation also depends on whether anything has been determined about changes made to medical devices. For example, article 4.10, Chapter II of Annex IX of the Regulation states: ‘Changes to the approved device shall require approval from the notified body […], where such changes could affect the safety and performance of the device or the conditions prescribed for use of the device’.
[8] The UDI-DI is a unique numeric or alphanumeric code specific to a model of device and that is also used as the “access key” to information stored in a UDI database (Article 1 Annex VI to the Regulation).
[9] The UDI-PI is a numeric or alphanumeric code that identifies the unit of device production. The different types of UDI-PIs include serial number, lot number, software identification and manufacturing or expiry date of both types of date (Article 1 Annex VI to the Regulation).
[10] Article 29 Regulation.
[11] The UDI placement criteria are set out in Article 6.5.4 Annex VI to the Regulation.
[12] Article 6.5.2 Annex VI to the Regulation.
[13] Article 6.5.3 Annex VI to the Regulation.
