This post introduces some of the gaps and uncertainties we are exploring in relation to software as a medical device
Advances in information technology have resulted in increasingly complex or “smart” medical devices that are capable of running software, lending these devices ever more complex functionalities. Often the relevant software comes as part and parcel of a physical medical device (e.g. a pacemaker). At other times the software is developed and available independently of any particular devices; to be downloaded and used, for instance, on a smart phone. Whilst there is no question that standalone software can be considered as a medical device in the eyes of the law, the application of this law is far from clear or satisfactory in the age of digital medical devices. As such, this post highlights some of regulatory gaps and uncertainties with regards to software as a medical device (SaMD).
What is (software as) a medical device?
The Medical Devices Regulations 2002 is the principle ex ante regulatory instrument governing medical devices in the UK and originally implemented EU Directives 93/42 on general medical devices, 90/385 on active implantable medical devices, and 98/79 on in vitro diagnostic medical devices. Post-Brexit the Medical Devices (Amendment etc)(EU Exit) Regulations 2019 retained and ensured the continued operation of the 2002 Regulations, and the 2020 Regulations of the same name put into place a dual system of regulation for the markets in Northern Ireland and Great Britain. Northern Ireland will continue to be subject to EU law as per the Northern Ireland Protocol, whilst Great Britain retains the current system, but with no further obligation to follow EU rules or interpretations. This also means that the EU Medical Device Regulations 2017/745 (EU MDR) and EU In Vitro Diagnostic Regulations 2017/756 (EU IVDR) due to come into force in May this year and May 2022 respectively will apply in Northern Ireland, but not in Great Britain.
The definition of a “medical device” as provided in Reg 2(1) of the 2002 Regulations as amended by Reg 2(h) of the Medical Devices (Amendment) Regulations 2008 is “any instrument, apparatus, appliance, software, material or other article… “intended by the manufacturer” to have one (or more) of the listed medical purposes including “diagnosis, prevention, monitoring, treatment or alleviation of disease”. Software was only added to this definition in 2008. In general, EU (and UK) law treats software as a “service” not as “goods” or “products”; the latter two being defined as “moveables” as part of the General Product Liability Directive. We, therefore, have the strange situation where software is treated as a “product” for the purposes of medical devices regulation, but as a service in nearly every other regulatory context (although we do note that the distinction between product and service has been rightly critiqued in relation to the IT sector).
SaMDs thus sit uneasily within a framework designed for physical goods. We can see this when reflecting on the definitions of “manufacturer” and “intended purpose” and in assessing whether a device is “placed on the market” in the SaMD context.
Who is the manufacturer?
For the purposes of the 2002 Regulations, a manufacturer is either “the person with responsibility for the design, manufacture, packaging and labelling of a device before it is placed on the market under his own name… or… any other person who assembles, packages, processes, fully refurbishes or labels one or more ready-made products or assigns to them their intended purpose… with a view to their being placed on the market under his own name…” This is slightly different to the definition given in either the EU Directives or the MDR and IVDR where a manufacturer will also be “a natural or legal person” and where the manufacturer also “markets the device under its own name or trademark”; language which implies an explicit commercial context. But it does similarly presuppose a tangible, physical object capable of “assembly” or “refurbishing”, as well as a model of device manufacturing with an easily identifiable central company or natural person responsible for manufacture.
Yet software development, especially collaborative open source projects, tend to be designed, developed, monitored, updated, and maintained by multiple persons across the globe. Further, the relative ease in setting up and developing apps (and software in general), also means new types of creator (or manufacturers) are emerging, including amateurs and enthusiasts unfamiliar with and potentially unaware that they could be subject to medical devices regulations.
The collaborative nature of many project may mean there is no readily identifiable natural person to whom responsibility could be (easily) assigned. And for some projects – such as the patient-led DIY artificial pancreas systems (APS) projects – there is no legally recognised body behind the project branding. This casts doubt on whether anyone in these projects come within the definition of “manufacturer” in the EU Directives and 2002 Regulations (and replicated in the EU MDR and IVDR). Moreover, the creators of software may not be – and indeed are not in the case of many health apps or DIY APS – one and the same as those who create the hardware which the software is destined to be installed on or to interact with.
The consequence is that the collaborative, decentralised structures and methods of open source software, and disaggregation between manufacturers of software and hardware, make more complex the potential chains of responsibility should something go wrong.
What is the intended purpose of the software?
The “intended purpose” of a device is ascertained “according to the data supplied by the manufacturer on the labelling, the instructions for use and/or the promotional materials”. Yet many lifestyle apps, whilst having the potential to be used as medical devices, may be marketed and instructed for uses that fall short of this, thus creating ambiguity over whether they are caught within the regulations.
What does it mean to place on the market?
To “place on the market” is “the first making available in return for payment or free of charge of a new or fully refurbished device… with a view to distribution, use, or both, on the… market”. Little guidance is given as to when a device is taken to be placed on the market. Although this might be relatively straightforward to determine for physical goods within a geographically defined area or market, software is a different matter.
Software may be downloaded from anywhere in the world to anywhere in the world challenging notions of when, where, or even how software as a medical device can be taken to be “placed on the market”, whether that be in Great Britain or Northern Ireland (or the EU for that matter). Indeed the proliferation of lifestyle and health apps for smart phones (and fitbits, etc.) means potential medical devices are available direct to consumers/patients without the need for a health professional intermediary.
Hence, if software is available globally to all online, then to what extent can it be said to be placed on a specific geographic or jurisdictional market? It seems unsatisfactory in the digital age that by simply hosting code on servers which are located outside of the UK, and indeed the EU (as is the case, for example, with DIY APS source code), places them outside those jurisdictional boundaries.
Further complicating the picture again, is that fact that the application of Art 2(2) and 2(1) of Regulation (EC) No 765/2008 the EU definition is slightly different. It stipulates that “place on the market” as the first “making available” of a device on the market must also be “in the course of commercial activity”, albeit one which need not involve money. This raises questions of what commerciality means here. For example, various projects may be branded, organised, and even engage in outreach (for instance DIY APS projects), but their not-for-profit nature makes it unclear if any of them would be considered as a “commercial activity”.
Whether and how such projects should be regulated is beyond the scope of this post, but they nevertheless reveal some of the ambiguities regarding SaMDs.
Does form matter?
It is not clear whether there is a distinction to be made for the law between pre-compiled software, which is downloaded in its final form ready for use, and uncompiled software which users have to take extra steps to compile themselves (the latter being the case with DIY APS). Current MHRA guidance suggests that uncompiled software may come within the ambit of the regulations if all instructions on how to install the software are provided.
However, this simply raises questions about the necessary breadth and extent of any instructions. In addition, there will be questions about who is providing said instructions and where they are located on the globe. It is not uncommon in relation of open source software to find relevant instructions on how to compile and use the source code being provided by individuals or groups other than the code’s creator(s).
We don’t suggest any easy answers to these questions in this blog; that is probably a task for an overly long paper. But it is clear that existing regulatory frameworks are left wanting in the SaMD context. But given the increasing development and use of such software, this needs to be addressed sooner rather than later.
Written by: Laura Downey and Muireann Quigley
Funding: Work on this was generously supported by a Wellcome Trust Investigator Award in Humanities and Social Sciences 2019-2024 (Grant No: 212507/Z/18/Z) Some initial work was also supported by a Quality-related Research Grant from research England.