Introduction
Software has become near ubiquitous, including within healthcare and medicine. Programmable medical devices such as pacemakers and drug delivery systems have been in development and use since the 1970s.Footnote 1 Whilst once state-of-the-art, many such devices are now a standard part of therapy when it comes to medical practice. Now the state-of-the-art is located not in the mere existence and use of such software, but in the multiple and varied innovative uses these can be put to or in the advanced algorithms they employ. For instance, machine learning and artificial intelligence (AI) software are now at a stage where they are used for clinical applications such as diagnostic and imaging tools,Footnote 2 amongst others. Meanwhile, an increasing proliferation of health, well-being, and medical apps for smart phones are available either for use by clinicians or directly by individuals themselves. Given this greater connectivity and complexity of the medical devices’ ecosystem, we now talk not only of the Internet of Things,Footnote 3 but the Internet of Medical Things.Footnote 4
Whilst there is much promise of improved care from such medical devices, their complexity and risk profile present serious issues for regulators, developers, and end-users alike. Of interest to us in this paper is the fact that there are several gaps and uncertainties regarding the application of the medical devices regulations in the case of software – in particular, standalone software or software as a medical device (SaMD). As we will see, the issue is not whether software falls within the ambit of the relevant regulations; it unequivocally does. Instead, we will demonstrate that there is a bad regulatory ‘fit’ between SaMDs (including AI as medical devices – AIaMDs, defined here as including AI-enabled medical devices) and the medical devices regulatory frameworks, as they currently stand, in both the European Union (including Northern Ireland (NI)) and Great Britain (GB)). Fundamentally, there is a mismatch between the intangible nature of SaMD and sets of regulations whose origins and provisions are better suited to dealing with physical devices. The result is a number of definitional and interpretative difficulties with the application of medical devices regulations to SaMDs. Recent changes to medical devices regulation and newer guidance – along with further proposed changes – go some way to addressing the challenges we lay out here. Nevertheless, we will argue that these do not yet properly get to grips with the foundational mismatch at the heart of regulating SaMD.
Faulkner has previously asked ‘[w]hen is a medical device not a medical device?’Footnote 5 Although his purpose in asking this question is to draw attention to ‘the significance of the ordering of socio-technical boundaries for regulation of technological sectors and zones’,Footnote 6 the question is germane here. This is because asking it prompts us to examine the different elements that affect whether and how any particular ‘device’ is captured by the Regulations and, in so doing, highlights how the definitional and interpretative difficulties inherent in the Regulations impact on ‘the boundaries of “deviceness”’,Footnote 7 making their application in the context of software problematic. To these ends, we begin in Section 1 with a brief overview of the place of software within medical devices regulations.Footnote 8 In Section 2, we advance our argument by discussing three areas which demonstrate that, for the regulations, there is a ‘boundaries of “deviceness”’ problem when it comes to software: (1) the application of the ‘intended purpose’ criterion for determining whether something is a medical device; (2) the lack of fit of the definition of ‘manufacturer’ in light of open-source (OS) software; and (3) the inadequacy of meeting statutory requirements regarding device conformity in the face of SaMDs which can change rapidly and frequently. Each area is accompanied by case studies to illuminate the challenges and risks posed. Respectively, these are: (1) Femtech and digital mental health apps; (2) OS software generally and open-source automated insulin delivery systems (OS AIDs) more specifically; and (3) AIaMDs as a particular instantiation of SaMDs. These case studies represent software innovations which highlight a set of distinct but overlapping gaps and grey areas regarding the place of software within the various regulatory frameworks for medical devices. Whilst each identifies specific points of tension, the challenges of interpretation and application cut across all the examples and will likely do so for many SaMDs. Section 3 then looks to recommendations which might alleviate some of the challenges identified and argues that, whilst these make some progress, they are insufficient because they do not resolve the conceptual challenge that SaMDs pose to medical devices regulation.
1. Regulating digital medical devices
Post-Brexit, the Medicines and Medical Devices Act 2021 (MMDA 2021) is the primary legislation regarding medicines and medical devices in the UK. It is, however, little more than a skeleton Act, containing broad discretionary powers enabling the Secretary of State to make new regulations adding to or amending the existing regulatory framework.Footnote 9 As such, the Medical Devices Regulations 2002 (SI 2002/618, as amended, referred to here as the 2002 Regulations) remains the principal substantive statutory instrument governing the regulation of medical devices in the UK. One consequence of the UK’s exit from the EU is that the interpretation and application of these Regulations is far from straightforward.Footnote 10 Via the 2002 Regulations, the UK now operates a dual system of regulation between GB and NI. GB continues to be governed by the pre-Brexit version of the 2002 Regulations, which implemented three older EU Directives: the EU Active Implantable Medical Devices Directive 90/385/EEC (AIMDD), the Medical Device Directive 93/42/EEC (MDD), and the In Vitro Diagnostic Medical Device Directive 98/79/EC (IVDD). Meanwhile, NI is now subject to EU Regulation 2017/865 on Medical Devices (EU MDR) and EU Regulation 2017/866 on In Vitro Diagnostic Medical Devices (EU IVDR).Footnote 11 Both the newer EU Regulations and the UK’s older EU Directive-derived Regulations follow an explicit risk management approach, setting minimum standards (essential criteria) for devices entering the EU/UK markets. These are classified into different categories depending on the level of risk to the end-user.Footnote 12 To be placed on the market, all medical devices must carry a conformity mark, with complex post-Brexit rules in place for determining what type of mark is needed, depending on the origin of the device (GB or NI) and its final destination (GB, NI, or EU).Footnote 13
The regulatory landscape will continue to be in flux for the foreseeable future. The UK, through its ‘Medical Devices Regulatory Reform’ programme, has pursued a series of policy and legislative changes partly in response to Brexit and the burgeoning issues relating to SaMD and AIaMD.Footnote 14 These changes, ongoing since 2021, include new post-market statutory requirements,Footnote 15 as well as updated guidance for crafting an intended purposeFootnote 16 and producing the Good Machine Learning Principles for medical devices.Footnote 17 Additionally, in 2025, the UK Government established the National Commission into the Regulation of AI in Healthcare, a non-statutory body to advise on a new regulatory framework.Footnote 18 Coinciding with these changes, the five-year review of the UK’s MMDA 2021 is due in 2026.Footnote 19 Meanwhile in the EU, in October 2024, the European Parliament called for a revision of the relatively new EU regulatory framework, citing concerns about depressed device development, slowed regulatory approvals, and inconsistent interpretation of the Regulations across Member States.Footnote 20 In December 2025, the European Commission laid out updated legislation to respond to these concerns, with a series of proposals to roll back and simplify current rules relating to medical devices.Footnote 21 Whilst the full regulatory changes to be brought about by these ongoing reforms are not yet known, from what we do know, as we will argue in Section 3, the proposed reforms are unlikely to fully address the challenges highlighted in this paper. This is because the changes and proposals so far do not grapple sufficiently with the less-than-ideal fit between the intangibility of SaMDs and the framing of the different Regulations.
The issue here is not about whether software fits into the regulations in a doctrinal sense. There are no difficulties in determining whether software falls sensu stricto within the various regulations. Regardless of whether software is integrated with hardware or is standalone, it could be captured by them. For instance, both the GB and the NI interpretations of the UK Regulations explicitly include software as part of the definition of a medical device.Footnote 22 There are minor differences in definition between the two interpretations of the Regulations, reflecting the differences between the older EU Directives and newer EU Regulations. The GB version covers any ‘instrument, apparatus, appliance, software, material or other article … intended by its manufacturer to be used specifically for diagnosis or therapeutic purposes or both’. Meanwhile, the definition of a medical device in NI ‘has the meaning given in Article 2(1) of Regulation (EU) 2017/745’ which, in addition, lists reagents and implants, and explicitly includes ‘devices for the control or support of conception’ amongst its listed purposes.Footnote 23 On the whole, however, the definitions are broadly similar.
There are a number of issues which have been, and continue to be, the subject of long-running debate in relation to medical devices regulations in the EU and UK; for instance, the need to strengthen rules relating to Notified/Approved Bodies, the adequacy of the essential requirements, quality assurance, vigilance, market surveillance, and transparency.Footnote 24 Whilst these have undeniably received more attention in the new EU RegulationsFootnote 25 and in recent UK statutory instruments,Footnote 26 our concerns relating to medical devices in general, and SaMD in particular, go beyond these issues. Fundamentally, as we are about to see, SaMDs challenge the conceptualisation and boundaries of ‘deviceness’ contained within the medical devices regulations.
2. Problems of interpretation and application
For a device to fall within the ambit of the medical devices Regulations (EU/NI or GB), there needs to be a device within the meaning of the statutory definition. This, on the face of it, is relatively straightforward. Software, when used for a defined set of medical purposes, is explicitly included.Footnote 27 Problems arise, however, when we look at other elements within the Regulations. First, a device must be ‘intended by the manufacturer’ to have one (or more) of a particular set of listed purposes.Footnote 28 Secondly, the Regulations presume the existence of an identifiable person or organisation within the definition of ‘manufacturer’.Footnote 29 Thirdly, all devices placed on the relevant market – be it GB or EU/NI – must undergo conformity assessment to determine whether the device meets the statutory essential requirements, as appropriate to the risk classification of the device. If passed, the device will receive a relevant declaration of conformity (eg UKCA or CE markFootnote 30) which, vitally, covers any significant device changes or updates. Yet, each of these elements is rendered problematic in the context of SaMDs.
(a) Intended purpose: Femtech and digital mental health apps
As Ludvigsen and colleagues have noted, the construction of Article 2(1) of the EU MDRFootnote 31 makes intended use central to the definition of ‘medical device’. It is ‘any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used … for one or more … specific medical purposes’.Footnote 32 Likewise, following the definition in the original medical devices Directives, the UK’s 2002 Regulations (GB) contain an equivalent provision. In this way, intention functions as a ‘gatekeeper’ within the Regulations.Footnote 33 The problem, as Ludvigsen and colleagues argue, is that ‘intended use’ is a ‘grey area’Footnote 34 where manufacturers can potentially skirt around the margins of the requirements, thus avoiding devices being captured by the Regulations.
To see why this is the case, we need to ask how the purposes and uses of a medical device as intended by the manufacturer are determined. According to the UK’s 2002 Regulations (GB and NI versions):
‘intended purpose’ means—
-
(a) in relation to an active implantable medical device, the use for which it is intended and for which it is suited according to the data supplied by the manufacturer in the instructions relating to it;
-
(b) in relation to any other medical device, the use to which the device is intended according to the data supplied by the manufacturer on the labelling, the instructions for use and/or the promotional materials …Footnote 35
The wording within the EU MDR and EU IVDR is on the face of it slightly more expansive, and includes packaging, instructions, marketing, the description in a device’s performance evaluation, and other statements.Footnote 36 But whilst the inclusion of ‘other statements’ goes beyond what is contained in explicit device materials provided by manufacturers, it is broadly similar to the requirements as set out in the 2002 Regulations (and thus the older Directives). The take home message is that whilst intended purpose can be imputed from a range of sources – labelling, instructions for use, promotional materials, etc – it is in essence a manufacturer-driven and controlled process.Footnote 37 This is supported by the decision in the preliminary ruling of the 2017 Court of Justice of the European Union case of SNITEM. Footnote 38 It is not necessary to rehearse the exact details here, but both the preliminary Opinion of the Advocate General and the judgment addressed the question of what ‘constitutes a medical device within the meaning of that directive’.Footnote 39 Of particular interest is the Court’s finding that:
it is … necessary that the intended purpose, defined by the manufacturer, is specifically medical … Software which does not meet that condition may fall within the scope of that directive only if it is an accessory to a medical device within the meaning of Article 1(2)(b) thereof.Footnote 40
The impact of this is ‘that the intended purpose of the manufacturer remains the most important factor to be considered in the assessment of whether a product qualifies as a medical device’.Footnote 41 Two examples emphasise the central challenge of this manufacturer-driven assessment and why this is a problem for SaMD: Femtech and digital mental health apps. Both demonstrate the blurring of the line between whether something has a ‘wellness’ or ‘medical purpose’ in a way that is less problematic in the case of tangible devices. Let us look at each to see why this is the case.
Femtech covers a range of ‘software, diagnostics, products, and services that use technology to focus on women’s health’.Footnote 42 This focus could be viewed as a positive development (particularly against a backdrop of medicine and medical innovation which has often neglected womenFootnote 43). But, as McMillan points out, ‘the market is now saturated with devices for personal use aimed at tracking and improving women’s biological processes, including fertility, breastfeeding, and sexual pleasure’.Footnote 44 A large proportion of these include digital devices and apps to aid menstrual tracking or ‘that aid in contraception and/or conception’.Footnote 45 Strictly, and as we saw earlier, those apps and other software aimed explicitly at the ‘control of conception’ – that is, intended by the manufacturer as such – will fall under the Regulations.Footnote 46 However, those apps, or software that have ‘tracking’ as their sole purpose will not fall under the definition of medical device as this is not one of the ‘listed medical purposes’ outlined in the Regulations. Moreover, the new EU Regulations specifically state that ‘software for general purposes, even when used in a healthcare setting, or software intended for lifestyle and well-being purposes is not a medical device’.Footnote 47
Mental health apps present a parallel example of the fluidity in drawing distinctions between devices with a medical purpose and those aimed at general lifestyle or well-being. Defined by the UK’s Medicines and Healthcare products Regulatory Agency (MHRA) as ‘software and digital products that support mental health and wellbeing’,Footnote 48 these can capture a range of activities relating to mental health including symptom tracking tools, diagnostics, treatment advice, and access to human or computationally autonomous chat functions. Applications can cover an array of acute and chronic conditions, such as anxiety, stress, psychosis, eating disorders, PTSD, and self-harm.Footnote 49 Many of these apps can be downloaded direct to personal devices from online app stores or through the developer/app owners website (although some may require referral from a healthcare professional). Whilst specific conditions (such as anxiety) are sometimes included in the name or description of some apps, many claim to focus on supporting well-being more generally. Mind – one of the biggest mental health charities in England and Wales – hosts an online library where links to ‘Mind approved’ apps are shared. Of the eight apps recommended, only one is identified as a medical device.Footnote 50 The others (including one for the prevention of self-harm or suicideFootnote 51 and one for support managing eating disordersFootnote 52) claim not to offer diagnosis, monitoring, or treatment (which would capture them within the Regulations) but to offer support in identifying warning signs/personal needs relating to particular conditions, tracking (including that of symptoms) or general guidance, and information about condition management and self-care (which leaves them outside the regulatory net).
Femtech and mental health apps therefore can have a range of uses – some of which may be explicitly intended and some of which may not be. Whilst manufacturers might claim that a particular app is explicitly intended, for instance, merely as a menstrual tracker or for general well-being, actual real-world use may differ. In the context of Femtech, tracking one’s periods is possibly the oldest way in which women seek to control conception. They can be used as a guide to when ovulation occurs and, thus, the optimal time in which to try to become pregnant, or, as a contraceptive aid, to know when to avoid engaging in intercourse to reduce the chances of becoming pregnant. Mental health apps may be used to seek diagnosis, monitoring, and treatment in the face of limited access to treatment.Footnote 53 Nearly 1.8 million people were referred for NHS talking therapies (eg cognitive behavioural therapy) in 2022/2023.Footnote 54 Mental health provisions are undoubtedly under pressure with such significant demand, and apps offer options for people to access diagnosis and treatment quickly, conveniently, and (often) at low cost. Our concern is that there is sufficient ambiguity in the potential functionalities and uses of such apps that users are exposed to risks. Whether because manufacturers in good faith do not see their devices as ‘medical’, or because bad actors seek to circumvent the Regulations by claiming that the intended purpose/use is as mere decision support tools and that the device, therefore, falls outwith the ‘listed medical purposes’.Footnote 55
As noted by Ludvigsen and colleagues, ‘manufacturers stating that their software is not supposed to be a [medical device] or not mentioning it at all serves as the easiest way of preventing the MDR [and other relevant Regulations] from applying’.Footnote 56 This is concerning because lack of reliability and efficacy may lead to user harm.Footnote 57 As McMillan rightly notes in the context of Femtech, these ‘products pose clear fields of physical and socio-cultural risk to users’ with ‘demonstrable impacts on individual users in the form of inaccurate advice and results, which can lead to traumatic experiences such as unplanned pregnancy’.Footnote 58 Meanwhile, current systematic reviews of smartphone apps for mental health present a mixed picture of their efficacy and raise concerns about the quality and representativeness of existing research which claim benefits.Footnote 59 The risks of using inefficient or unreliable mental health apps are significant: they can delay engagement with appropriate services or result in patients not reaching out at all, thinking such treatment ineffective.Footnote 60
To reiterate, the risk with this subjective approach is that an improper or insincere framing of devices leads to those who arguably ought to be caught in the medical devices regulatory ‘net’ falling outside its purview. This, at best, exposes individuals to ineffective products and, at worst, endangers them with unsafe ones. The very unreliability of these apps can lead to these harms. We, therefore, agree with McMillan when she says that in practice ‘little attention [is paid] to ways in which companies can get around the regulatory requirements that are present with ease (with or without intention), despite having potentially devastating consequences’.Footnote 61 Because a device’s ‘intended use’ has a direct impact on whether or not that device is captured by the Regulations, it is important that the obligations placed on manufacturers in respect of intended use are clear and appropriately circumscribed. Arguably, the current understanding of ‘intention’ allows manufacturers excessive leeway in this respect.Footnote 62 The sharp increase in the number of these apps means that too heavy a reliance on the subjective assessment of the manufacturer has become a more pressing issue.Footnote 63
Moreover, whilst the importance and challenges of crafting an appropriate intended use statement impact all medical devices, it is the intangibility of SaMD like Femtech and mental health apps which heighten these risks. Recent MHRA guidanceFootnote 64 on digital mental health technologies has attempted to provide clarity on intended use statements but, as we discuss below, whilst a step in the right direction, this does not yet sufficiently deal with the problems laid out here. These apps can be developed more quickly and cheaply than physical devices. As such, apps can reach consumers at a rapid pace and be downloaded at home to personal devices, facilitating access without the need for a clinical intermediary and in such a way could be said to disrupt the doctor-patient relationship. Bypassing such clinical oversight and guidance may increase the potential for misuse of these devices. In this manner, the very immateriality of software and information is part of why manufacturer intention becomes problematic in these contexts. This speed and volume of development relate to another challenge, namely the difficulties of effectively enforcing the intended purpose requirement. SaMD – particularly Femtech and mental health apps – have rapidly proliferated and it is not clear whether regulatory bodies have the capacity to review the number of apps published. Practical enforceability challenges which arise due to the intangible nature of SaMD also occur in our next example of the poor fit between the regulatory framework and software: the question of who counts as a manufacturer in the context of (OS) software.
(b) The definition of ‘manufacturer’: open-source software (OS software) and open-source automated insulin delivery (OS AID)
OS software refers, generally, to software (and its underlying source code) which is shared publicly for anyone to use, modify, and re-distribute.Footnote 65 It is often created by communities of individuals and shared with no – or very few – barriers to use and distribution.Footnote 66 Such software projects do not carry with them the same physical and geographical limitations on development that comes as part and parcel of medical devices hardware manufacturing. Moreover, they lend themselves to collaborative, decentralised models of development in a way that hardware manufacturing may not. The freedom from geographical and physical limitations mean that their development is not contained within an organisation that can be easily identified as a ‘manufacturer’. This has implications regarding whether and how they might be captured by the current Regulations. Consider here the definition of ‘manufacturer’ in the 2002 Regulations (NI and GB interpretations). Here:
‘manufacturer’ means—
-
(a) 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, regardless of whether these operations are carried out by that person himself or on his behalf by a third party; or
-
(b) any other person who assembles, packages, processes, fully refurbishes or labels one or more ready-made products or assigns to them their intended purpose as a device with a view to their being placed on the market under his own name, apart from a person who assembles or adapts devices already on the market to their intended purpose for an individual patient …Footnote 67
This is slightly different from the definition given in the EU Directives and the newer EU Regulations. The former additionally state that the manufacturer will be ‘a natural or legal person’,Footnote 68 whilst the latter narrows the scope of ‘manufacturer’ to be ‘a natural or legal person who manufactures or fully refurbishes a device or has a device designed, manufactured or fully refurbished, and markets that device under its name or trademark’.Footnote 69 Inherent in each of these is a presumption that there is an easily identifiable central company or (natural) person responsible for manufacture.
For physical devices, determining who or what organisation is a manufacturer should be reasonably straightforward. If a major medical device manufacturer produces and builds an insulin pump, this will be done at a physical manufacturing plant located in a particular geographical region. To have a manufacturing plant on the scale required for tangible devices there would normally need to be a registered business and a legal entity responsible for the various obligations pertaining to a physical place of business. Furthermore, the logistics of the manufacture of medical devices hardware would normally require a legal entity that has ultimate control and responsibility for the product and can enter into the contracts needed for such an enterprise. In contrast, developing OS software does not require a physical location or manufacturing equipment to produce the end-product (other than internet connected computers). For this reason, software development generally, and OS software specifically, better lends itself to collaborative OS outputs and modes of working. There may also be far fewer costs associated with software development in contrast to those required in the manufacture of physical devices.
Medical devices hardware development may also have these aspects. The design of these, for instance, could tend more towards a globalised, collaborative model, even within the confines of a large multi-national manufacturing company. However, ultimately, the production of the hardware is more materially bounded than software development. Consequently, within the potentially ‘diffuse’ nature of software development in general, and the decentralised, collaborative nature of open-source software projects in particular, there may not be a readily identifiable natural, or legal, person who could be considered as the manufacturer or assigned responsibility. Moreover, the relative ease in setting up and developing apps (and software generally) means that new types of creators (or manufacturers) are emerging, including amateurs and enthusiasts unfamiliar with and potentially unaware that they could be subject to the requirements of the medical devices regulations.Footnote 70
Consider the example of OS AID (open-source insulin delivery) systems. Under the moniker #WeAreNotWaiting, these have been developed by and for people living with diabetes as part of voluntary, community-driven efforts.Footnote 71 These systems use existing technologies – continuous glucose monitors (CGMs) and insulin pumps – and connect them using innovative OS software, enabling the CGM to ‘talk’ to the insulin pump, (semi-)automating the process of insulin delivery. Significantly, the different OS software used to create the AID systems – of which there are severalFootnote 72 – are largely unregulated. The OS source code, along with extensive instructions, enables users to download, unarchive, and compile the code into software in the form of an app. Further online instructions then guide the user in setting up the system, testing it, and using it to automate their insulin delivery. Once it has been set up, troubleshooting and device support are community-led and offered through online fora.Footnote 73 As collaborative projects, these systems are devised, developed, monitored, updated, and maintained by multiple persons across the globe.Footnote 74 For example, the oref0 code – the foundational algorithm for OpenAPS – has been developed by a large and evolving group of contributors on Github. These numbered over 100 when we last checked.Footnote 75 Given this globalised and distributed context, it becomes difficult to identify a single natural or legal person who can plausibly be said to fit the definition of ‘manufacturer’ for the purposes of medical devices regulation.
This is not to say that solutions could not be found. For example, a person or group of people could assume the responsibilities of being a ‘manufacturer’, or a legal entity could be established to assume this role. However, whether or not this aligns with the open, collaborative ethos underpinning these forms of development will likely depend on how this is done.Footnote 76 As recently argued by O’Donnell and Quigley, ‘[t]he primary goal [of the #WeAreNotWaiting movement] is not to bring innovations to market but to meet the shared needs of a community of [people with diabetes]’.Footnote 77 Thus, initiatives seeking to enclose the diabetes commons would sit uneasily with the approach of the community so far. As we return to in Section 3, fundamentally, there is an inherent tension between the realities of open, distributed, and decentralised software innovation and the assumptions – more suited to physical goods manufacturing – underlying the definition of ‘manufacturer’ in the medical devices regulations.
(c) Managing change: AI as a medical device (AIaMD)
A final example of the poor ‘fit’ between the existing medical devices regulatory framework and the intangibility of software is AIaMD. AIaMD is a particular subset of SaMD and generally refers to medical devices which rely on complex algorithms which have been ‘trained’ using machine learning techniques to generate an output (eg a diagnosis or recommended treatment) in response to user inputted data (eg patient symptoms or clinical imaging). AIaMD has attracted significant policy attention in recent years, including how best to appropriately regulate systems which autonomously adapt in light of new inputted data: the so-called ‘update’ or ‘adaptability’ problem.Footnote 78
Medical devices, including SaMD, can – and do – change for any number of reasons. In the case of digital technologies, new software can be introduced or updated to add new features, to respond to how devices are used in practice or be deployed to patch ‘bugs’ which impact system performance. There are associated established frameworks for managing these changes to ensure devices remain safe, and do not stray beyond their initial regulatory approval. In GB, significant changes to a device may require regulatory re-approval to ensure continuing conformity with the essential requirements laid out in the 2002 Regulations.Footnote 79 Moreover, MHRA guidance states that any change to devices must be justified and that the Approved Body overseeing the technology must ratify any significant change to digital technologies before deployment.Footnote 80 Article 10(9) of the EU MDRFootnote 81 similarly makes provisions around continuing compliance with the Regulations in the event of changes to devices, something which may include changes to a device’s risk classification. SaMD specific guidanceFootnote 82 states that ‘manufacturers shall evaluate the potential impact of any changes to the function, intended use, essential design, and manufacturing characteristics on the software’s qualification as [medical device software] and its classification’. It also notes that manufacturers are responsible for ensuring the safety and performance of SaMD throughout the lifecycle of the device.
The problem when it comes to SaMD in general, and AIaMD in particular, is reconciling a regulatory framework which certifies medical devices as safe and effectiveFootnote 83 at a fixed point in time, with systems which, once deployed, may autonomously adapt in ways which can impact the safety and effectiveness of the device. This can be problematic in the context of medical devices regulations which ‘seem geared toward a relatively static concept of devices … [which] change slowly and methodologically, if at all’.Footnote 84 Consider, for example, myAir: an FDA-approvedFootnote 85 mobile phone application (not an AIaMD).Footnote 86 This provides information to use a paired physical device (the AirSense wearable device for tracking sleep apnoea), tracks patient sleep, provides sleep therapy coaching, and provides read-outs for sharing with medical professionals. myAir was updated 25 times between March 2023 and May 2025, with some updates occurring as little as eight days apart.
Notwithstanding the fact that this rate and frequency of change is undoubtedly fast when compared to physical medical device changes,Footnote 87 it is nothing when set against certain AIaMD.Footnote 88 Some machine learning models are designed to adapt incrementally in response to new training data. Where this data is continuously streaming (for example, pulling from electronic health records as they are updated in real timeFootnote 89), algorithms are constantly fed new data points and adapt in response to this, shrinking the time between changes from days to hours and minutes. This continuous updating is more than just a matter of increased frequency in device change; it is an integral component of AIaMD.Footnote 90 This ability to adapt promptly, in real-time, to respond to imminent patient and clinician need is, at least in part, what has generated significant excitement about the possibility of algorithms in healthcare.Footnote 91 However, at what point does an accumulation of continuous ‘minor’ changes translate into ones which are more substantial and which, therefore, (ought to) trigger the more substantive review and (re)approval requirements mandated by the Regulations? The answer to this is important because, for SaMD, small ‘tweaks’ to software functionality or scope already risk becoming a significant change which could impact safety and efficacy. For AIaMD that rely on continuous streaming data, this risk is heightened because of the increased volume of small ‘tweaks’ which might rapidly become a ‘significant’ change.
There is no detail in the 2002 Regulations, EU MDR, or recently released guidance relating to SaMD about how to address the challenges here, although the MHRA has identified the need to review and potentially refresh change management requirements for SaMD.Footnote 92 Currently, developers are directed to the Notified Body Operations Group Guidance which states that determining whether a particular product change is ‘substantial’ should address questions about impact on intended purpose, whether new hazards or risks are identified, and whether changes relating to manufacturing processes, facility, or equipment impact product safety or performance.Footnote 93 MEDDEV Guidance on SaMD and the EU MDR is similarly light on detail. It directs manufacturers to evaluate the impact of any changes to device function, intended use, and classification.Footnote 94 However, there is no information in either about assessing the cumulative effect of change(s).
A related challenge is the fact that the existing regulatory framework assumes that any changes will be ex ante and be driven by humans (the manufacturer or developer), rather than autonomously via the system itself. Device manufacturers are subject to a range of obligations to ensure that the impact of any change is considered prior to its execution. The MHRA guidance, for example, states that any change needs to be justified, and that any significant change to a device requires ratification by an approved body before deployment. The Notified Body Operations Group guidance begins with a ‘need or wish’ by the device manufacturer to change the device before determining whether such change is substantial or not. Similarly, ISO13485 – an international standard for quality management systems for medical devices – requires manufacturers to validate and approve changes before deployment, including understanding the impact of said changes (to performance, useability, safety, intended use, and compliance with regulations). The BSI Standard BS EN62304 on software life cycle processes also requires manufacturers to adopt a controlled approach to software changes and start any substantive change with a change request.
This ex ante approach works well with physical devices that embed software, and with standalone software where any new data, patches, and so on can be planned and assessed in advance. It does not work well for systems which update in light of continuously streamed data. First, there is a knowledge problem. Certain machine learning processes – such as deep neural networks – can update in ways not obvious to developers or users.Footnote 95 Identifying and assessing these changes before they are made is therefore difficult to achieve in practice. Secondly, given the frequency of the likely changes, it is not necessarily desirable that manufacturers should seek re-approval before each change a continuous streaming system may make. It would place an unwieldy burden on both the manufacturer and notified/approved bodies to require such re-approval, stretching already overloaded regulatory processes.Footnote 96
3. Square pegs, round holes? SaMD and regulatory proposals for change
As noted above, medical devices regulation is undergoing an (arguably extended) period of change. Some of the planned consultations and roadmaps to bring about updates and revisions to the regulatory frameworks address the challenges we have mapped out in this paper. However, these proposals do not fully take into consideration the lack of ‘fit’ between the intangible nature of software and a regulatory framework originally developed – and thus conceptually oriented – around medical devices as physical products. In this final substantive section, we discuss recent and proposed changes with regard to each of the areas discussed so far: intended use; the definition of a ‘manufacturer’; and managing change in AIaMD. We argue that whilst these are to be welcomed, they do not sufficiently address the conceptual mismatch between software and the framing and approaches of the different medical devices regulations.
(a) Intended use and ‘reasonable foreseeability’
According to the 2021 MHRA ‘Consultation on the future regulation of medical devices in the United Kingdom’, ‘intended purpose’ (at least within the UK’s Regulations) is ‘best interpreted as an objective test … assessed at the standpoint of an objective observer and is not a question of what the subjective intention of the manufacturer might be’.Footnote 97 We agree. Intended use/purpose would be best viewed as an objective test. However, it is not clear that – at least up until now – it has operated as such; something which is clear if we revisit SNITEM, discussed in Section 2(a). In this case, both the Advocate General and the Court drew on MEDDEV 2.1/6 guidance on standalone software, which stated that ‘only the intended purpose as described by the manufacturer of the product is relevant for the qualification and classification of any device’.Footnote 98 Whilst the MEDDEV guidelines applied to the MDD and have been replaced by EU MDR/EU IVDR-specific guidelines,Footnote 99 the effect of SNITEM is that ‘the court elevated these into binding case law’.Footnote 100 Moreover, notes made in the Opinion of the Advocate General suggest that the prevailing understanding is that the ruling would also be broadly applicable to the MDR.Footnote 101 Regardless, allowing ‘intended use’ to hinge almost completely on the manufacturers’ say so is unsatisfactory. An overreliance upon manufacturer intent arguably allows manufacturers too broad a discretion, meaning devices with clear possible medical purposes can escape regulation. We have seen from previous scandals, including pelvic mesh, that past provisions of the medical device regulations were framed too widely, allowing patently risky devices to lawfully enter the market without appropriate oversight.Footnote 102 We suggest that in the era of mounting healthcare apps, a similar scenario may play out against the backdrop of the current framing of ‘intended purpose’, where apps that may pose pertinent medical risks escape regulatory oversight.
Given this, a reorientation towards a more objective test for intended use, as suggested in the MHRA Consultation, and reflected in its more recent guidance on SaMD, is to be welcomed. The guidance notes that, ‘[a] manufacturer’s stated view of their product is not solely determinative as to whether their device is or is not a medical device’.Footnote 103 It continues, saying that ‘intended purpose must be construed objectively from the standpoint of an objective observer’ based on information in the labelling, the instructions for use and/or promotional materials, and technical documentation including the clinical evaluation report.Footnote 104 The guidance also lists a number of specific elements which manufacturers ought to take into account in their device’s intended purpose statement. These are the structure and function of the device, along with the intended target population, the intended user, and the intended use environment. Manufacturers are also required to document ‘scenarios of reasonably foreseeable misuse’ which are then used to influence the key elements of their stated intended purpose and feed into risk management and design.Footnote 105
Notwithstanding the marked step forward that the MHRA guidance represents, there remain areas of concern. First, ‘foreseeable misuse’ is not defined or clarified, something which would help those crafting their statements to know where the boundaries are being drawn (for the regulator).Footnote 106 Consider again, from our earlier Femtech example, that all period trackers might in fact be used as aids to contraception. Where is the line to be drawn between simple tracking and the (surely obvious) reasonably foreseeable ‘(mis)use’ of these for contraceptive or conceptive purposes? The answer to this is important because it is the ‘misuse’ of these which push them from being well-being apps into the medical devices (regulatory) sphere and it surely ought not to be enough for manufacturers to simply avoid labelling these as medical devices, or even to explicitly state that they are not intended to be used as such. They should consider what the average user might use it for; for example, as contraception or as an aid to conception in the context of menstrual trackers or as providing diagnostics and/or treatment of mental health conditions in the context of mental health apps. This approach is supported by the Blue Guide, the EU’s guidance document on the implementation of EU product rules, which requires manufacturers ‘to consider the conditions of use which can be reasonably foreseen prior to placing a product on the market’ and ‘to place themselves in the position of the average user and envisage the ways in which they might reasonably (mis)use the product’.Footnote 107
For digital mental health (including apps) the MHRA has recently gone further in attempts to clarify how to craft an appropriate intended use statement which seems to address some of the above concerns. The Digital Mental Health Technology (DMHT) guidance states that to fall within the regulations an app must have both a ‘medical purpose’ and ‘high functionality’.Footnote 108 In the context of mental health, devices are considered to have a medical purpose if they are intended to be part of the ‘broad process involvement in the management of mental ill health’. The device must perform a clinical task (such as diagnosis, monitoring, etcFootnote 109) and target clinical conditions and symptoms ‘at levels considered diagnosable or clinically relevant’.Footnote 110 Devices will be considered as targeting a clinical condition/symptom both if it states so explicitly (eg an app aimed at treating major depressive disorder) and if it can be inferred from the device description (eg if an app states it is intended for those with ‘symptoms of depression’). The labelling, instructions for use, promotional materials, and technical documentation all contribute to this inference. The guidance states further that intended use ‘can be assessed by checking understanding of typical users and monitoring how a product is actually being used’.Footnote 111
The DMHT guidance therefore begins, to introduce the requirement for some external evidence (via inferences and assessment of user knowledge and use) which goes some way to addressing the problems of overly relying on the subjective assessment of device manufacturer’s intent. However, it only applies to digital mental health apps leaving issues relating to other health care apps, such as Femtech, unresolved.Footnote 112 Further, it is unclear from the guidance who is responsible for assessing the understanding and use of a typical user, or at what point this assessment takes place. Whilst this statement is included in a section dedicated to determining whether DHMT has a medical purpose, its phrasing suggests that information would be gathered in post-market surveillance. As with our earlier discussion of the subjective assessment of intended use,Footnote 113 this surveillance would only be required if the product is placed on the market as a medical device in the first instance. If a manufacturer advertises their product as ‘wellness’ and avoids reference to specific mental health conditions within their marketing, it would continue to fall outside the regulation and not be subject to consequent assessment regardless of how the device is used. Relatedly, the guidance is aimed at manufacturers who are actively crafting their intended purpose statement as part of a device’s conformity assessment; it does not address those manufacturers who do not know, or actively deny, that their device may fall within the Regulations. Yet, it is on this boundary between wellbeing and the medical that the uncertainty lies.
Regardless of the ways in which a device might avoid initial regulatory scrutiny, to ultimately be brought within the regulatory net, the MHRA must become aware of the device prior to taking investigative or enforcement action. However, the mechanisms for alerting the MHRA to potential regulatory breaches are suboptimal. User reports via the Yellow Card scheme may flag devices in need of investigation, but awareness and utilisation of the scheme is low.Footnote 114 Horizon scanning may provide an opportunity to identify potential breaches, but it is not clear the MHRA have the capacity to conduct the breadth of scanning needed, nor investigate and enforce breaches of the Regulations given the sheer volume of SaMD placed on the market. The intangible nature of SaMD consequently makes it easier for manufacturers to skirt the relevant regulations, and harder for regulators to enforce them.
A further issue is that mental health apps – and SaMD more generally – are being dealt with solely via guidance rather than embedding the changes and requirements within the relevant statutory frameworks. This is, to a certain extent, a pragmatic approach. The problem of regulating emerging technologies and the risks of implementing change too early in legislation are well recognised.Footnote 115 Indeed, it is arguable that this is part of why the EU is revisiting medical devices regulation so soon after the MDR reached full implementation in 2021. Nevertheless, when it comes to issues such as reasonable foreseeability, it is at least arguable that we need to go beyond guidance.
Whilst guidance presents a potentially flexible regime for handling technological change, placing ‘reasonable foreseeability’ on the face of the Regulations would be preferable. First, we can see from other contexts that there is often insufficient awareness of guidance and, as such, a failure to shape behaviour in the requisite ways. For example, the Independent Medicines and Medical Devices Safety Review found that a lack of awareness of guidelines, including recommendations to discontinue prescription of sodium valproate, was partly responsible for continued harms.Footnote 116 Secondly, the risks involved are sufficiently high that they deserve the legal heft of legislation, combined with effective enforcement mechanisms and sanctions. Finally, introducing a definition of ‘reasonable foreseeability’ is not a specific technical standard easily outstripped by the pace of technology in statute; it has a more general application that does not require the flexibility of guidance to remain cogent to the application to medical devices.
A statutory test of ‘reasonable foreseeability’ could therefore go some way to addressing the risks arising from intended use. It may also encourage SaMD developers/manufacturers to consider whether their applications fall within the regulatory net by requiring them to consider potential uses and misuses of their devices. It could be argued that many fitness or wellness apps do not represent the same level of risks of harm as other medical devices and making it a statutory requirement could overstretch already burdened regulators with a proliferation of devices. However, being captured by the regulations would ensure that manufacturers could be more easily held accountable for the risks their devices do present.
(b) Globalised, decentralised software development: manufacturers and markets
In Section 2(b) above, we used OS software to illustrate the difficulty of determining who (or which entity) counts as the ‘manufacturer’ within the ambit of the different medical devices regulations. We saw that within the context of a globalised, decentralised model of software development, this may not always be straightforward. The MHRA, as part of its change programme, has dedicated a work package to identifying a manufacturer where OS software is used to create SaMD, though no guidance has yet been published.Footnote 117 The only statement hinting at what may be proposed is that if available code is ‘… modified, the entity making the modified version may take on the responsibilities of the manufacturer of this modified code if it qualifies as a medical device’.Footnote 118 Whilst this offers a glimpse into the potential approach of the regulator, it nevertheless does not (on its own) resolve the challenges discussed in this paper. Moreover, it raises more questions than it answers in its current brief form.
Although this statement deals with the manufacturer question vis-à-vis modified code, it does not say how the initial creators of that code ought to be viewed. In our OS AID example above, the software projects are hosted on sites such as GitHub and the code is being continually altered and updated. Does each individual who modifies the code on GitHub take on the responsibilities of a manufacturer? These are collaborative OS software products and, as such references to ‘the manufacturer’ do not seem an easy fit. Further clarification would, therefore, benefit from grappling with the specifics of OS software. This could include clarifying the status of the original manufacturer, how best to handle plural developers/coders/creators, and jurisdictional questions where this plurality of creators collaborate on developing OS software across the globe. Clarity is also needed on what modifications would give rise to taking on the responsibilities of a ‘manufacturer’. Changes to software can be relatively minor and inconsequential to their functioning as medical devices, or they can be substantive. It is not clear that all changes ought to give rise to such responsibilities. For instance, if an entity modifies the code to improve its user experience or to patch security concerns, do they assume the responsibility of a ‘manufacturer’?Footnote 119
A further issue is that who counts as a manufacturer is intertwined with considerations of what it means to place a device on the market, something which is important because not all activities and actors are meant to be captured by the medical devices regulations. Yet, the exact contours of what is captured in these respects are somewhat difficult to determine. The framing and language of the Regulations presume an overt commercial context for medical devices development. Consider section 2 of the 2002 Regulations (in both GB and NI interpretations) which defines ‘placing on the market’ as ‘the first making available in return for payment or free of charge of a new or fully refurbished device, other than a device intended for clinical investigation, with a view to distribution, use, or both, on the … market’.Footnote 120 Whilst the medical devices Directives did not define ‘making available’, both the EU MDR and EU IVDR state: ‘“making available on the market” means any supply of a device, other than an investigational device, for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge’.Footnote 121 As such, if placing on the market is equivalent to the first making available, then we should take a product to be placed on the market when that product is supplied, for the first time, for distribution, consumption, or use in the course of a commercial activity. This understanding can also be found in the EU Blue Guide which says that ‘[c]ommercial activity is understood as providing goods in a business-related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context.’Footnote 122 It goes on to say that ‘[i]n principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business-related context’.Footnote 123 Interestingly, the new EU Product Liability Directive takes a similar stance by excluding hobbyist products. And whilst it brings software explicitly into the remit of ‘product’ for the first time, it nonetheless excludes ‘free and open-source software’.Footnote 124
The difficulty here, as the examples of OS software and OS AID demonstrate, is that there are contexts that are made explicitly and purposefully non-commercial yet where the activities of ‘mere’ hobbyists could reasonably be construed as amounting to the manufacture/development of SaMD. OS AIDs involve voluntary initiatives, by the diabetes community for the diabetes community. They are frequently framed in direct opposition to the activities of commercial entities.Footnote 125 Despite this, OS AID developers are involved in the creation and distribution of products that could lead to (potentially significant) harm. As such, there may be a public interest in ensuring that any potential harm is minimised – something which, in the case of medical devices, we generally seek to ensure via the extensive provisions within, and systems enabled by, the various medical devices regulations.Footnote 126
(c) AIaMD: pre-determined change control plans
Above, we showed how the adaptability problem poses difficulties for the regulation of SaMD and, in particular, AIaMD. In this final section, we turn to the proposals for the use of pre-determined change plans (PCCP) to address the challenge of how medical devices regulation can best ensure that (continuous) updates to software remain within the confines of device conformity requirements (as originally granted). A PCCP is a document, drafted by the manufacturer, which lays out certain planned modifications to devices, the process for implementing these modifications, and an impact assessment of the proposed changes. It is one way in which monitoring the performance and addressing the risks of change over the lifecycle of a device can be accommodated.Footnote 127 Further MHRA guidance establishes five guiding principles for writing a PCCP namely that any plan: (1) is focused and bounded; (2) is risk-based; (3) is evidence-based; (4) is transparent; and (5) takes a total product lifecycle perspective.Footnote 128
Whilst these will likely encourage manufacturers to think through the implications and risks of their devices, once deployed, these principles – and therefore PCCP based on them – are nonetheless a less-than-ideal fit in the AIaMD context. For a PCCP to be ‘focused and bounded’ the manufacturer must describe the planned implementation of specific changes, including the extent of the change and plans to safely modify the device within the bounds of its original intended use. To be evidence based, a PCCP must demonstrate that, for any change, the benefits outweigh potential risks; to be transparent, the document should share the details of the comprehensive testing conducted for any change. Principle 2 also requires that ‘individual and cumulative changes remain appropriate over time for the device and its use environment’. Thus, there is some attempt to recognise that small tweaks can become substantial cumulatively and over time. But adherence to these principles is based on changes which are, in an ideal world, pre-planned, limited within the context of the original intended purpose, and rigorously tested prior to implementation. It is not clear how this works where systems update autonomously and can do so continuously at speed and at a high frequency (such as the earlier example of AIaMD which rely on continuously streaming data).
In addition, the principles do not address the knowledge problem, where the decisions and changes to algorithms are occluded from view for both developers and users. Neither do they adequately grapple with the question of when a small change becomes a substantial one (which may require re-certification of device conformity or – depending on the size of the change – re-assessment of device class).Footnote 129 The only nod to this is in Principle 2, which states that manufacturers should be cognisant of the potential cumulative changes but provide little in the way of when and how to seek re-approval. The core challenge here is, as argued above, the non-physical nature of AIaMD. The PCCP principles remain focused on a conception of change as ex ante and ultimately deployed by a human, assuming that change is generally slow, pre-determined, and (ideally) fully risk assessed and tested prior to its implementation. Whilst this is apt and achievable in the case of physical goods, it is less suited here.
An alternative is offered by Gerke and colleagues, who argue that one of the key issues is that regulators take a product approach; that is, they only assess the device itself.Footnote 130 They reason that a systems approach would expand the regulatory lens from solely devices to include human and environmental factors.Footnote 131 This would include detailed information about how SaMD/AIaMD were integrated into workflows, staff training, how healthcare professionals interact with the devices, and monitor for shifts in human practice (including, for example, checking for automation bias) on top of the existing regulatory requirements for surveilling the performance of the device itself.Footnote 132 Initial regulatory approval would be for a short period of time and regulators would more closely monitor and reassess the device (and other social and environmental factors) for conformity.
This ‘systems’ framing of regulation would likely prove particularly useful in the case of SaMD because it shifts the assumption of device regulation that devices are relatively static to conceptualising them as dynamic.Footnote 133 Such an approach could take account of updates to the product itself, as well as shifts in how the device is used in different social and environmental contexts. Yet it is not without limitations. Even fully staffed and fully resourced, it is questionable whether regulators or Approved/Notified Bodies would be able to (or we would want them to) properly consider the volume of changes a continuously learning algorithm may involve given the opacity of such changes to its users. It also does not resolve the question of at what point a series of small changes becomes a substantial one necessitating reassessment of device conformity. Moreover, shifting to a systems approach – as Gerke and colleagues recogniseFootnote 134 – would require a wholesale reimagining of the scope and boundaries of medical devices regulation which would likely challenge current medical devices regulatory paradigms.
Concluding thoughts
The regulation of medical devices in the UK and Europe has not kept up with the technological state-of-the-art. Whilst there is much promise in SaMD, the complex and non-physical nature of such devices poses distinct risks, with associated significant challenges for their regulation. Despite recent updates to the regulation of medical devices in the UK and EU (outlined in Section 1), these frameworks do not yet properly grapple with the fundamental conceptual mismatch between a system designed for physical devices and the intangible nature of software. The result is a number of difficulties in the application and interpretation of these regulations when it comes to SaMD. In making our case, we analysed three key issues: (1) how the ‘intended use’ of digital devices impacts on whether they are captured by the medical devices’ Regulations; (2) the problems created by the boundaryless nature of software for determining who or what (legal) entity counts as the device ‘manufacturer’; and (3) the challenges of managing changes to SaMD, especially those which can be updated rapidly and frequently. Here, we examined dedicated case studies to highlight the interpretative difficulties between SaMD and existing medical devices regulation.
First, we examined Femtech and mental health apps, showing how an overreliance on manufacturer intention to establish the ‘intended use’ of a device allows excessive leeway. It risks manufacturers circumventing the Regulations by marketing their digital devices as health or well-being apps. These examples were chosen as they demonstrate the acute risks where devices can too easily fall outside regulation designed to ensure effectiveness and patient safety – namely, the potentially life-altering consequences for those relying on such apps for con(tra)ceptive purposes or mental health treatment. Secondly, we used the examples of OS software and OS AID to demonstrate how the current definition of ‘manufacturer’ does not adequately capture the decentralised and collaborative models typified by OS approaches to device development. We argued that the current approaches of the UK and EU for establishing who or what entity counts as a ‘manufacturer’ presume that there is an easily identifiable legal or natural person. Yet, pinning this down may be much more elusive when it comes to software than it is for medical devices hardware. Finally, we considered AIaMD as a particularly challenging instantiation of SaMD, arguing that existing regulatory approaches to managing device change do not sufficiently take into consideration the speed and frequency with which such devices can update. The current framework continues to assume that change is something ex ante and conducted after rigorous testing, which does not reflect the reality of AIaMD.
Current EU Regulations and the newly published guidance from the UK’s MHRA make an important start in tackling some of the challenges outlined here. Nevertheless, there is more to be done if medical devices regulation is to be fit for purpose in the digital age. In this paper, we offered three potential suggestions that could be incorporated into planned changes in the UK and EU. First, future regulations could tighten up intended use requirements by incorporating ‘reasonable foreseeability’. Placing this on a statutory footing, as opposed to within guidance, would require SaMD developers/manufacturers to more fully consider the realities of how their devices can and could be used. Regarding the manufacturer question, we noted that future MHRA guidance will likely require individuals who modify the code to take on the responsibilities of a ‘manufacturer’. However, this leaves significant questions unanswered, not least regarding the status of the original creators of the OS code. We argued that any future developments must address this and take account of the globalised, fragmented, and decentralised nature of OS software development. Finally, with regard to the adaptability problem and AIaMD, we argued that a systems approach might be apt. This would shift the regulatory lens from viewing devices in isolation to viewing them as one part of a whole system. This would at least offer a promising start by recognising the realities of AIaMD as dynamic devices.
With updates to the UK’s medical devices regulatory framework (including the five-year review of the MMDA 2021 and work of the National Commission on AI in Healthcare) continuing for the foreseeable future, as well as the European Commission’s draft proposals for amending the EU MDR/EU IVDR published for debate, now is the time to properly address the conceptual mismatch at the heart of medical devices regulation. It is the lack of fit between regulatory frameworks with physical goods at their core and the intangible nature of software that underpins the challenges we have outlined. Given this foundational problem, simply layering provisions and guidance onto the current system is unlikely to suffice in the longer-term. In a digital world, where the development and use of SaMD are becoming increasingly integrated with standard care, it is crucial that we have regulation that is capable of appropriately capturing the nuances and risks specific to software.Footnote 135 As such, we need to find better ways to make a regulatory framework originally designed with physical products in mind work with the reality of software development, distribution, and use.
Open access
