Medical Device Software: between old Directive and new regulation
The current regulating framework, based on Directive 93/42/EEC, regulated the software intended by the manufacturer to be a medical device (or to be part of it) quite marginally. The Directive mentions it seven times: just once to establish that it is to be considered as an active medical device (e.g. as an electro-medical device), and two more times in the definition itself of medical device. Actually, the only explicit provision, representing an Essential Requirement, is given by point 12.1a of Annex I.
This subordinates the validation of the software to the state of the art of the reference sector, taking into account the principles of development lifecycle, risk management, validation and verification. All other provisions regard active medical devices and are therefore based on a much wider group, which is varied and essentially not finalized to immaterial products (as a software essentially is).
This approach had a double effect. On one side, manufacturers found themselves in the material difficulty of understanding if their software could actually be framed as a medical device, so much so that the issue was the subject of a specific guideline (MEDDEV 2.1/6), from which a practical algorithm was derived to solve the problem. On the other side, the compliance with the Essential Requirements imposed by the Directive was almost entirely based on the provisions regarding active medical devices, mostly improper when applied to a software. Even more, no classification rule includes software, so its classification is based on that of active medical devices (Rules 9 to 12, Annex IX). The problem of having many software framed in class I according to Rule 12, because not falling under previous Rules with higher classification but little suitable or too restrictive for the intended use provided for for a software, has soon followed. On the contrary, the compliance with the Essential Requirements, to be considered as an issue coming after the legal frameworking, was solved thanks to point 12.1a based on the application of quality management system (based on ISO 13485), being in itself one of the harmonised norms specific for software that is essential in the medical in sector. A specific harmonised norm based on IEC 62304 was also used. Both norms contributed to balance the general aspects compared to the specific ones, also succeeding in being complementary on aspects that are not directly addressed (above all, the exclusion of the software validation and final release from the field of application of norm 62304, even when this is a separate medical device).
The fate of the software that is integral part of active medical devices is easier, thanks to the relevant harmonised norm, implementing IEC 60601-1, along with point 12.1 of Annex I. In this case, according to point 2.3 of Annex IX, the software can be classified directly based on the active medical device it operates, while the provisions detailed by IEC 60601-1 made the rest.
The new Regulation
The new Regulation (EU) 2017/745 to be applied as of May 2020, obviously resorting to all the expertise of the technological development occurred since the drafting of the old Directive, addresses software (mentioned 53 times) more explicitly, directly and in details. The old points 12.1 and 12.1a of the Directive become points 17.1 and 17.2 of Annex I, specifying that the whole point 17 also regards software directly.
Here, under point 17.3, there is the provision regarding the software intended to be used on mobile computing platforms, aware of today’s tendency of any apps to be designed to work on any support, such as smartphones. The provision under point 17.4 is curious because the obligation to specify minimum requirements for hardware, information nets and safety measures, including unauthorised access, could collide with the more peremptory burden expressed in Annex II regarding the technical documentation, where under point 6.1, letter b), forth indent, it is specified that the verification and validation of the software should take into account all the different hardware configurations and operational systems identified in the information provided by the manufacturer. Basically, on one side there is still margin left defining only one lower limit, while on the other there is the obligation to take everything into account.
This issue opens a matter that is quite relevant for the software, especially modern software that is already (at least) designed to work on any information system: the restriction or the freedom to be used on systems that have not been widely tested in advance. In fact, if there is a characteristic that is distinctive for software compared to other products is the ability to adapt to any different system setting, and we know that system changes are rather frequent in the common practice. The whole current regulating framework, as well as the one provided for by the new Regulation, is strongly conservative in terms of risks for users or patients. In fact, the approach more commonly followed by manufacturers of medical device software has always been to avoid contaminations, changes, interferences, free choices.
Supported and limited by the provisions of norms 13485, 62304 and 60601-1, careful manufacturers have always preferred a safe path, opting for a use strongly limited to particular systems with special configurations. The result is now quite clear in the clinical setting, where interoperability and compatibility of different medical devices belonging to different manufacturers, is much lower and limited compared to mass settings. In relation to this topic, the new regulation not only does not provide any solution but it also worsens the situation, expressly introducing the definitions of compatibility and interoperability found as General Safety and Performance Essential Requirements under point 14.5. The new Regulation will not go in the direction of system integrability.
Differently from the old Directive, the new regulation presents rule 11 (in Annex VIII), specifically introduced for software. This is quite general in terms of predictable situations and it will be able to include most of concrete possibilities, and for this it will increase the risk class of a software.
Finally, it is interesting to notice that the check and validation of the software are included among the characteristics of the dossier to be submitted to the investigator in the frame of a clinical trial (Annex XV, point 2.3).
In conclusion, the new Regulation addresses the topic of the software more extensively, amending many aspects of the current Directive, but it does not solve one of the main issues: the expectation of integration between different devices appealed for by many parts (health operators). A response may perhaps come from common harmonised or specific norms, but considering the strongly limiting aspects for a designer, this could remain just a utopia (i.e. information safety measures as protection against unauthorized access).
Written by: Amilcare Icomino
