Professor Muireann Quigley, Dr Laura Downey, Dr Louise Hatherall
Software is now everywhere in healthcare. From period-tracking apps and mental health platforms to artificial intelligence (AI) systems that help diagnose disease, software is reshaping how healthcare is delivered. Some estimates suggest there are now hundreds of thousands of health-related apps available,[1] while AI-enabled medical technologies continue to expand rapidly.[2]
Yet the legal frameworks governing medical devices were largely designed with physical products in mind: pacemakers, implants, surgical tools, diagnostic equipment, and so on. As software has become an increasingly important medical technology in its own right, an important question arises: can regulatory frameworks built for tangible devices adequately regulate intangible software? In a recent article in Legal Studies, we argue that the answer is often no.[3]
The problem is not that software sits entirely outwith medical device law and regulation. In both the UK and EU, software can qualify, and be regulated as, a medical device. The difficulty is that there is a fundamental mismatch between the assumptions built into medical devices regulation and the realities of how software is developed, distributed, and used. In this post, we highlight three areas – discussed in more depth in the article – where this mismatch is particularly problematic.
When is a health app a medical device?
The first challenge concerns what the ‘intended purpose’ of the device is. Whether a product qualifies as a medical device often depends on what its manufacturer says the device is intended to do. If software is intended to diagnose, monitor, prevent, or treat disease, it is likely to fall within the medical devices’ regulations (both EU and UK[4]). If it is framed as a wellness or lifestyle product, it may not. However, this distinction can be difficult to maintain in practice.
Consider Femtech, such as menstrual tracking apps. Aids to con(tra)ception are explicitly captured by the Regulations, whereas period trackers are not. Some apps are therefore marketed simply as tools for monitoring periods, thereby avoiding review by Notified and/or Approved Bodies (the third-party private organisations tasked with conformity assessing devices on behalf of the EU and/or UK regulators). Others are explicitly promoted as aids to contraception or conception and therefore fall clearly within medical devices regulation. Yet many users may employ period-tracking apps to make decisions about fertility regardless of how the app is described.
Similar issues arise with digital mental health technologies. Many apps provide symptom tracking, behavioural advice, or support for people experiencing anxiety, depression, self-harm, or eating disorders. Yet some avoid regulation by presenting themselves as wellness tools aimed at helping general mental wellbeing rather than products which provide diagnosis or treatment.
The concern is that manufacturers have significant discretion in defining the purpose of their products. This creates the possibility that software with genuine medical functions escape the regulatory safeguards designed to ensure safety and effectiveness.
Who is the manufacturer?
A second challenge concerns responsibility. Medical devices regulation assumes there is a clearly identifiable manufacturer. This makes sense when dealing with physical products produced by established companies. But software does not always fit this model. Open-source software provides a particularly striking example of this poor fit. Open-source projects are often developed collaboratively by geographically dispersed communities of volunteers. Code may be continually modified, improved, and redistributed by large numbers of contributors.
One important healthcare example is open-source automated insulin delivery systems. Developed through the #WeAreNotWaiting movement, these systems allow people with diabetes to connect glucose monitors and insulin pumps using community-developed software to (semi-)automate insulin delivery. The software often evolves through contributions from numerous developers around the world with troubleshooting, patches, and updates developed collaboratively via online fora, such as GitHub.
In such circumstances, identifying a single legal or natural person who can properly be described as the ‘manufacturer’ becomes difficult. Yet the regulation of medical devices relies heavily on there being a manufacturer who assumes responsibility for compliance, safety monitoring, and regulatory obligations.
The rise of open-source medical technologies, therefore, exposes tensions between traditional regulatory assumptions and emerging, decentralised forms of innovation.
What happens when software keeps changing?
The third challenge is centred on issues of change and adaptation. Medical devices regulation generally works by assessing a product at a fixed point in time. Before entering the market, devices must demonstrate conformity with regulatory requirements. Any future significant changes may require further scrutiny or approval. For physical products, which tend to develop slowly and incrementally, this is relatively unproblematic. However, software can change far more rapidly than physical devices.
Apps may be updated weekly, daily, or even more frequently. AI-enabled systems, in particular, create difficult regulatory problems because some machine-learning models can adapt over time in response to new data. In healthcare settings, this can mean algorithms continuously evolving as they encounter new patients and information. This raises difficult questions. At what point do lots of small changes become a significant change requiring reassessment by Notified and Approved Bodies? How can regulators evaluate systems that continue to evolve after deployment? And how should oversight operate when the inner workings of AI-enabled systems are unclear, even to the developers themselves?
Existing approaches, including predetermined change-control plans – which require developers to describe, risk-assess, and prepare for system changes before they are made – represent useful steps forward. However, they remain rooted in assumptions that such change can be anticipated, properly planned, and fully assessed in advance. That assumption is increasingly strained in the context of adaptive software.
Rethinking regulation for a digital healthcare future
Regulators in both the UK and EU are actively considering reforms to medical device regulation.[5] These developments are welcome and demonstrate growing recognition of the challenges posed by software and AI. However, our argument is that many current reforms do not fully confront the deeper conceptual issue. Medical devices regulation remains fundamentally organised around physical products, identifiable manufacturers, and relatively stable technologies. Software frequently troubles all three assumptions.
As healthcare becomes ever more digital, the challenge is not simply to add new guidance or extra rules. Instead, we may need to rethink some of the underlying assumptions that structure medical devices regulation itself. Since software has become central to modern healthcare, ensuring that regulation properly reflects the realities of software development, distribution, and use is no longer a niche regulatory concern. It is an essential prerequisite for safe and effective healthcare in the digital age.
A note on the robot in the room: This post grew out of a paper which we wrote with our own fair hands. We gave Copilot our paper and asked it to help us make a blog post out of the thing – a task involving structure, transitions, and a fair amount of prose. We checked the claims, fixed the mistakes, and smoothed out the prose to fit our own style. The arguments and research are ours; the robot helped us to get them into this particular outfit.
[1] Likely an underestimate due to the time lag between data and report. Organisation for the Review of Care and Health Apps (ORCHA), ‘Market Facts & Figures’. Available at https://www.orchahealth.com/market-facts-and-figures (accessed 29 September 2026).
[2] IQVIA Institute for Human Data Science, Digital Health Trends 2025: Business Models, Evidence Requirements, and Revenue Opportunities (IQVIA Institute, 2025). Available at https://www.iqvia.com/insights/the-iqvia-institute/reports-and-publications/reports/digital-health-trends-2025 (accessed 29 September 2026).
[3] Quigley M, Downey L, Hatherall L. Living in a Material World? Regulatory Challenges of Software as a Medical Device. Legal Studies. Published online 2026:1-20. doi:10.1017/lst.2026.10139.
[4] For ease, in this post we refer to these together. See the article in Legal Studies for a more nuanced treatment of the two sets of Regulations.
[5] See, for example, the Medicine and Healthcare products Regulatory Agency’s ‘Software and AI as a Medical Device Change Programme roadmap’, available at https://www.gov.uk/government/publications/software-and-ai-as-a-medical-device-change-programme/software-and-ai-as-a-medical-device-change-programme-roadmap (accessed 29th September 2026), and the European Commission’s ‘Proposal for a Regulation of the European Parliament and of the Council amending Regulations (EU) 2017/745 and (EU) 2017/746’, available at https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025PC1023 (accessed 29th September 2026).