This browser is not actively supported anymore. For the best passle experience, we strongly recommend you upgrade your browser.

BioTalk

Powered by Bird & Bird

| 4 minute read

Navigating Digital Health: When Software Becomes a Medical Device – Critical Legal Considerations for Technology Suppliers in the Healthcare Sector

As digital health applications become increasingly sophisticated and telemedicine (the distribution of health-related information and services remotely) has become the new norm in the post-pandemic healthcare landscape, the line between software and medical devices has become increasingly blurred, creating critical compliance considerations that can significantly impact business operations and legal liability.

The Regulatory Framework

Under European Union Regulation 2017/745 on medical devices (“MDR”) and Regulation 2017/746 on in vitro medical devices (“IVDR”), software can be classified as a medical device when two cumulative requirements are met: 

  1. the manufacturer must intend it to be used for medical purposes, for example, for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; and
  2. it must achieve its intended effect without pharmacological, immunological, or metabolic means.

Various guidelines have been developed to aid enterprises in determining whether their software qualifies as medical devices (Software as Medical Device “SaMD”), an important example of which is the Guidance on Qualification and Classification of Software (MDCG 2019-11) by the EU Commission’s Medical Device Coordination Group (“MDCG”). 

These guidelines, together with the MDR and IVDR, provide for certain main rules that may help to draw the important line between a regular software and a SaMD. For example, if the software only stores, archives, communicates or searches data, it probably falls outside the definition of a SaMD. Further, if the actions performed by the software are not meant for the benefit of an individual patient, it is not a SaMD.

That said, how the law should be interpreted changes over time and especially the introduction of artificial intelligence has brought new questions causing the MDCG to introduce novel guidelines and update its existing guidelines. For example, the above Guidance on Qualification and Classification of Software (MDCG 2019-11) was recently updated in June 2024 to clarify that while a simple search of patient information does not make a software a SaMD, the use of NLP (natural language processing) in the search algorithm may render the software as qualifying as SaMD where those search actions contribute to achieving a medical purpose.

Furthermore, the traditional questions of what the intended purpose of the software is  continues to be relevant, and it may still come as a surprise to technology suppliers making their debuts in the healthcare sector that SaMDs are not only those software which directly interact in or on the human body – as confirmed by the European Court of Justice in its judgment C-329/16 of 7 December 2016 (for further information about this case, read our analysis here).

Interpreting the Manufacturer’s Intended Purpose

Although the question of whether the manufacturer intended their software for medical purposes is highly relevant in determining its potential nature as a SaMD, it is worth noting that from a legal point of view this is something that the manufacturer cannot simply decide. 

Instead, in assessing whether a software has a medical purpose under the MDR, the ‘intended purpose’ is defined based on the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements or as specified by the manufacturer in the performance evaluation.

This means that the definition of a SaMD is broad and may cover software that the manufacturer would prefer – or even disclaims – is not classified as a SaMD but legally is if the software is nevertheless being promoted for medical purposes. As the assessment focuses on all materials published by the manufacturer and not just the technical nature of the software in question, there may even be competing software products on the market - from which one is classified as a SaMD and the other is not. 

For the above reasons, it is highly important for all technology suppliers operating in the healthcare sector to bear in mind that even standalone or relatively simple software products may qualify as SaMD if they are marketed for medical purposes. 

Compliance Considerations and Market Surveillance Measures

The MDR and IVDR, respectively, impose wide compliance obligations on manufacturers of medical devices.

For example, before introducing a medical device on the market in the EU, the manufacturer shall ensure that they have been designed and manufactured in accordance with the requirements of the MDR and/or IVDR, and affix in a visible manner a CE marking to the device.  Certain medical devices also require that their legal compliance has been reviewed by a notified body as defined in the MDR. Consequently, the manufacturers should know  which class their medical device belongs to (Class I, Class IIa, Class IIb, or Class III) and understand the related compliance obligations (for example, in relation to conformity assessment, risk management, clinical evaluation, and documentation).

Medical devices not bearing the relevant CE marking, which bear an incorrect CE marking, or which are otherwise non-compliant may be removed from the market by the authorities. 

In Finland, software as medical devices is a topic that regularly attracts attention from the authorities, and this June, the Finnish Medicine Agency (“Fimea”) launched a targeted campaign for software-based medical devices. According to its press release, Fimea will approach Finnish healthcare software manufacturers whose products are registered as medical devices in the European EUDAMED database or whose products could be medical devices based on the company’s marketing. During the study, manufacturers will be asked for more detailed information on the intended purpose of their software and its functions to ensure its regulatory status. So, at least in Finland, the supervisory authority has taken an active role in ensuring that software products made available in the healthcare sector are legally compliant and it is likely that a similar approach can be expected also from other authorities in  EU member states as the regulatory environment together with the opportunities created by artificial intelligence keeps on developing.   

The practical implication of this for businesses is that  they also need to ensure that they keep up with the regulatory developments and that their software products used in the healthcare sector are reviewed carefully to confirm if they qualify as SaMDs. A negligent approach in this space could easily lead to injunction orders from the authorities which could lead to serious business implications especially for software products already existing on the market.

Tags

digital health, medical devices, software as a medical device, mdr, samd, medtech, regulatory, healthcare, regulatory and administrative, commercial, artificial intelligence, life sciences and healthcare, technology and communications, digital regulatory healthcheck, life sciences, western europe, central and eastern europe, biotalk, medical devices regulation