While it may seem sensible to reach the conclusion that for something to be a ‘device’ it must be tangible, to maintain safety and efficacy, the law in the UK governing medical devices, which originates from EU law,  does not apply in this way.

Generally, the Medical Device Directive is most relevant in the context of software and was transposed into UK law by the Medical Devices Regulations 2002 (the “Regs”).  The Regs have since been amended to expressly call out software  in the definition of ‘medical devices’ which now reads as follows:

“A ‘medical device’ means any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:

• diagnosis, prevention, monitoring, treatment or alleviation of disease,
• diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
• investigation, replacement or modification of the anatomy or of a physiological process, control of conception,

and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means.”

As is evident, this is a long and complex definition. Therefore, in order to determine whether a piece of software amounts to a medical device and is governed by the Regs, it is necessary to consult various guidance produced by the Medicines and Healthcare products Regulatory Agency (“MHRA”),  and the EU Commission  (including MEDDEV 2.1/6) . MEDDEV 2.1/6 is particularly useful and sets outs steps to follow to determine whether the relevant software constitutes a medical device.

Step 1 – Does it meet the definition of “software”?

This test will likely be passed as the term software is broadly defined as, “a set of instructions that process input data and create output data”.

Step 2 – Does the software perform action(s) on data that exceed simple storage, archiving, communication, simple searches or lossless compression of the data?

For software to fall within the scope of the Regs, the software must do more than these simple, administrative, actions. For example, software that simply passes medical data from point A to point B fails to satisfy this test and therefore fall outside the Regs.

Currently, there is a grey area around software that passes data and is intended to support decisions made by healthcare professionals and further investigation is required. For example, if such “decision support software” performs a calculation, interprets or interpolates the data and healthcare professionals do not review the raw data, then the software is likely to be a medical device. Furthermore, MHRA’s guidance states that software is likely to be a medical device when it applies automated reasoning, (for example, dose calculations, symptom tracking, and clinicians guides to help decision-making). Whereas, software that is used only to provide reference information to support a healthcare professional, who then relies on their own knowledge and skill to make a clinical decision, is more akin to a simple transmission of data and is unlikely to be considered a medical device.

A recent case known as SNITEM  was the first Court of Justice (“CJEU”) decision on the classification of software in the context of medical devices and demonstrates a clear intention by the courts to interpret the definition of medical device widely. The software in the case was intended for use by physicians in anaesthesia and intensive care to support prescribing decisions. The CJEU held that the software was within the definition of a medical device as at least one function of the device made it possible for a physician to use patient-specific data to assist in prescribing or calculating the dosage for treating the patient’s condition.

Step 3 – Are the action(s) identified in step 2 being performed for the benefit of individual patients?

This should be evident from the purposes of the software, however, MEDDEV 2.1/6 helpfully lists some examples of when this isn’t the case, including aggregation of population data, generic diagnosis, treatment pathways, scientific literature, medical atlases, models and templates as well as software for epidemiologic studies or registers.

Step 4 – Did the manufacturer intend the software to be used for one or more of the purposes in the bullet point list of the medical device definition?

This test was reiterated in the SNITEM case. If one of these purposes are satisfied, then the software will fall within the scope of, and must comply with the requirements of, the Regs, including the requirement to carry the CE marking before it can be put into service or placed onto the market in the EU.

New medical device regulations

As a final point, the regime applicable to medical devices is above to change as the EU regulations for medical devices (“MDR”)  and in vitro medical devices (“IVD”)  came into force on 26 May 2017. We are currently mid-way through transitional periods before these regulations will fully apply (from 26 May 2020 for MDR and 2022 for IVD).

As part of the transitional arrangements, medical devices can either be placed onto the market under the Regs or MDR/IVD. However, after 25 May 2024 medical devices will need to comply fully with the MDR or IVD (as applicable) unless they wish to make use of the extended period of CE certificate validity.

We have not analysed the MDR in detail as part of this article but among other things, the MDR extends the scope of the Regs, provides new quality and risk management obligations for medical device companies and will bring about slight changes to the classifications of medication devices, which device manufacturers will inevitably need to review to ensure they remain compliant.

• Share this blog

• Twitter
• Facebook
• Linkedin