The Intention; Requirements for Software as a Medical Device in EU Law

Abstract

The role of software in society has changed drastically since the start of the 21st century. Software can now partially or fully facilitate anything from diagnosis to treatment of a disease, regardless of whether it is psychological or pathological, with the consequence of software being comparable to any other type of medical equipment. Furthermore, software can be disembodied from the traditional role of medical equipment, which is clearly seen in the use of apps. %Make that clearer We see this with the medical device legislation, specifically the Medical Device Regulation (MDR) not being explicitly created for software, as well as unpredictable developments in the field such as contact tracing applications or self diagnostic tools in general. Any uncertainties concerning the interpretation of these rules must therefore be cleared, both for the sake of the manufacturer as well as the user. In this paper, we show how and when software is considered a medical device in EU law, more specifically in the Medical Device Regulation. To do this, we first create a framework for the intention of the manufacturer, since this would otherwise likely pose a barrier that would prevent software from being seen as a medical device at all. We show how and where software is specifically mentioned in the regulation, and how it is understood. We also include a comparison between US law and the EU regime, and take a quick look at contact tracing applications as such, as well as the practice of two European regulators. We finally create, from existing requirements, a decision diagram comprising a guide to determining whether a piece of software is a medical device or not under the MDR, to illustrate our findings and combine this with with the aforementioned manufacturer's intention framework. We find that in theory it is possible to determine whether software is a medical device, and therefore falls within the MDR's scope or not, but this assessment remains very unsure. This is because of the ambiguity of the criteria as well as how the MDR is designed. A literal interpretation of the Regulation yields immediate issues with whether a particular piece of software should be included or not. Furthermore, if software is considered to be a medical device, the software's manufacturer will be subject to strict organisational and cybersecurity obligations, and can face severe penalties such as withdrawal or bans on their software for infractions. At the same time, enforcement is left to national regulators in each Member State, creating potential inconsistencies in oversight and interpretations, as well as lacking a clear body of legal practice. We see that because of the pivotal importance of manufacturer's intention for triggering the application of the MDR, there exists an actual risk of circumvention of the MDR, and show that the Principle of Circumvention could be applied. However, we find that US law, via FDA guidelines, has measures that can be used as inspiration for reform of medical device law and practice in the EU, including an exclusion list and overarching federal penalties in the form of withdrawal, for not reporting which and how one's software is a medical device.