Software is found in all aspects of our lives, including in healthcare settings. As a regulatory team we are often asked which software qualifies as a medical device. This article provides a few handy pointers that can help direct the thinking of anyone developing software and considering this question.
A stepwise analysis needs to be applied to determine whether the software could be a medical device. Any software needs to be assessed as a whole, considering the following information:
- What information 'feeds' into the software, or what are the 'inputs'?
- What 'assessment' or changes does the software make to the inputs, if any?
- What is the 'output' of the software?
- What decisions or actions are or might be taken by a user - a healthcare practitioner (HCP) or patient - using the 'output' from the software?
- What do the instructions for use (IFU)/label/marketing/advertising claim about the software's capabilities?
Software? What software?
Software is defined as 'a set of instructions that processes input data and creates output data'. This article focuses on standalone software, as opposed to software that is integral to a device that offers other features. Standalone software can be used alone or in combination with other products, including medical devices.
In considering whether the standalone software is a medical device, the intended purpose of that software must first be considered (but not of any device with which it is used in combination). If the software drives or otherwise influences a medical device and has a medical purpose in doing so, then that software will qualify as a medical device.
The location of the software is not relevant. It could be in a cloud, on a computer, on a phone app, or on a separate piece of kit and could be intended for use by HCPs, patients, or individual consumers.
What is a medical device?
Whether software is a medical device or an in vitro medical device is ultimately determined by the intended purpose of the manufacturer (we use 'medical device' for both throughout this article, unless otherwise indicated). The question here is not: 'does the manufacturer intend the software to be a medical device?', but rather: 'what is the manufacturer's intended purpose for the device, determined using the information from the answers to questions one to four above?'. These are to be assessed together, with a further and separate assessment of the intended purpose based on claims about the software (question five above).
Armed with the information in response to the above five questions, the intended purpose can be reviewed against the definition of a 'medical device' as set out by the EU in Article 2 of the EU Medical Devices Regulations 745/2017 (MDR), ie: ‘any…software…intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
- diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease
- diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability
- investigation, replacement or modification of the anatomy or of a physiological or pathological process or state
- control or support of conception
- cleaning, disinfection or sterilisation of devices.
If the intended purpose of the software is medical, ie it falls within the list of verbs in the definitions above in relation to a relevant noun - the disease, injury or disability, anatomy, physiology or pathological process or state - or if it is to control or support of conception, then the software will be a medical device.
Software with potential in vitro diagnostic (IVD) purposes should be reviewed against the additional list of intended purposes from the EU IVD Regulations 746/ 2017 (IVDR). A medical device that is software would fall within the definition of an IVD if the intended purpose is within any of the following:
- concerning a physiological or pathological process or state (by investigation of this process or state)
- concerning congenital physical or mental impairments
- concerning the predisposition to a medical condition or a disease
- determining the safety and compatibility with potential recipients
- predicting treatment response or reactions
- defining or monitoring therapeutic measures.
In the UK, the definitions are currently less sophisticated, but following the above EU analysis as a quick check is likely to come to a similar result in most cases. The UK regulatory body, the MHRA, has explicitly said that it does not intend to regulate software that simply systematises analyses that have previously been provided on paper.
In making the assessment about software that is not otherwise built into a medical device, the software must be qualified 'on its own', so excluding for example a measuring device to which it is connected, or any other device which communicates information to it, unless the software is driving or influencing the device. It is also not determinative of the software being a medical device simply because there is a risk of harm from use of the software, such as from inputting incorrect data.
What is an accessory to a medical device?
Software that does not fall within the definition of a medical device, but which works alongside a medical device, might be an accessory to it, if part of an 'article'. Such accessories are regulated as medical devices under the regulations, so it is important to undertake this further additional assessment where the software works with a medical device.
The definition of an 'accessory for a medical device' is an 'article' which is not itself a medical device, but is specifically intended by its manufacturer to:
- be used together with one or several particular medical device(s)/IVDs
- specifically enable the medical device(s)/IVDs to be used in accordance with its/their intended purpose(s)
- specifically and directly assist the medical functionality of the medical device(s)/ IVDs in terms of its/their intended purpose(s).
Software that is not a medical device
If the software acts on the information 'inputs' without changing that data, then it is unlikely to be a medical device unless claims made about the software indicate an intention for the software to have a medical purpose.
If the intended purpose of the software is constituted solely by the following activities, this does not itself indicate a medical purpose:
- storage
- archival
- communication
- simple search
- lossless compression (a compression procedure allowing the exact reconstruction of the original data).
Thus, software that offers a 'simple search' (ie retrieves records by matching record metadata against record search criteria) does not qualify as medical device software. Basic electronic patient record systems fall into this category.
However, software can be applied to patient records to provide determinations in relation to the individual patient. Some of these developments have a medical purpose, such as predicting treatment pathways, or the timing for a medical intervention. A recent study by Imperial College London checked women's shopping habits for purchases of indigestion tablets and painkillers, then showed how this information could predict a diagnosis of ovarian cancer. If this information is turned into an analytics tool used to predict risk and then send individuals for a medical investigation, this would constitute medical device software.
Non-medical purposes include invoicing or staff planning, emailing, data parsing and the usual functions of standard office software packages.
To qualify as a medical device the standalone software must be for the benefit of individual patients. Therefore, software that aggregates data to generate generic diagnostic or treatment pathways that are not intended to be applied in the care of individual patients will not be medical devices.
One note of care is the use of a 'Research Use Only' label on software provided into a healthcare setting where that software might influence individual patient care. In these circumstances, manufacturers should take care to ensure that the software will never be used by treating physicians for their patients. An exception is use of the software as part of a clinical study or performance evaluation that has been properly authorised by a competent authority and agreed to by the applicable ethics committee. Note that if individual patient data is obtained from use of the software without such authorisations, the data cannot then be used to support an application for a conformity assessment of that software.
Similarly, the addition of the words 'for information only' will not remove a software application from applicable medical device regulation if the software qualifies as a medical device.
Communication versus other activities
Software used to collect and communicate health data without alteration is unlikely to be a medical device. The action of the software on that data does not have a medical purpose and therefore this software is not a medical device, even if the information is of a medical nature. Some argue that because of the potential for injury if the information is not correctly communicated by the software, it is properly a medical device. However, the Medical Device Coordination Group (MDCG) guidance makes it clear that risk is not a determining factor in categorisation of software as a medical device.
See Annex II below for examples of types of software that are unlikely to qualify as a medical device unless medical claims are made.
Software qualifying as a medical device
In contrast, software with a medical purpose that collects data and then runs algorithms or other processes on it, and whose output is different from the input data - either in content or in a sufficiently different configuration or presentation - might be a medical device.
Software that undertakes any of the following actions in relation to medical information might qualify as a medical device if there is a medical intended purpose to those actions:
- process
- analyse
- create
- modify (eg in the representation of data that goes beyond merely cosmetic changes or processing to allow comparison).
All these actions go beyond the mere communication of information.
Software that 'monitors' physiological processes should also be considered. This activity involves taking readings which, again, goes beyond the mere communication of information. If that provision of physiological data has a medical purpose, the software will be a medical device.
See Annex I below for examples of types of software that are more likely to be software medical devices.
Software claims: question five
Software that is determined not to be a medical device in relation to questions one to four can nevertheless be brought within the definition of a medical device if claims of a medical purpose are made about it.
Claims might be made on the label, within an app, by sales reps, or in the IFU. If regulation as a medical device is to be avoided, care should therefore be taken about all claims made about the software. Words to avoid include any of the verbs or nouns in the bullet point list above in the definition of a medical device or IVD, and any disease definitions (including common terms such as dementia, head injury, bronchitis, asthma, eczema, mental health, menopause symptoms, depression, anxiety, etc). A non-exhaustive list of other medical terms to be avoided include cure, prevent, fight, restore, prevent, avoid, heal, protect (when used in relation to a disease), cognitive decline, and treatment or alleviation of pain.
However, such claims can be major selling points, particular for devices purchased by consumers directly. It can be worthwhile asking sales reps how they would characterise the software when trying to sell it. If medical claims are likely to be used, the manufacturer of the software should consider whether they have the time and the means to regulate the product as a software medical device. If the manufacturer wants to make sales of a device that would not of itself be characterised as a medical device in advance of jumping the regulatory hurdles, they should set a clear policy for sales reps forbidding the use of all medical claims.
It is often the case that software medical devices for consumers start life as wellness products. As their use case is justified through sales over time, they are eventually regulated as medical devices, which then allows medical claims within the IFU and justified by clinical data to be made. See our article: Is it a wellness app or medical device? A critical boundary issue in the smart wearables sector . The move to a regulated medical device provides competitive advantages, particularly if competing products are not regulated as medical devices. This allows the manufacturer on the one hand to use substantiated medical claims in their marketing, and on the other to call in the regulators if the competitor tries to make medical claims for their unregulated device.
Creators of software that might be medical devices should be aware that the MHRA scours advertising to UK consumers for medical claims. The MHRA contacts anyone it finds making medical claims for software that is not registered as a medical device and requires them to cease use until the software has been properly regulated. Ignoring the issue or hoping that it will go unnoticed is therefore not recommended.
As a first step, you could use the Taylor Wessing MDR Medical Device Checker tool and follow up with a full legal analysis, particularly if you are unsure of how to characterise your device, or if you consider your device on the borderline, or have questions about what might constitute 'medical claims'.
Annex 1: medical device software examples
Examples of software more likely to be characterised as a medical device include software that:
- makes or offers information for a diagnosis (such as DNA analysis)
- calculates clinical risk (whether a percentage or scale such as red/amber/green)
- ·offers a prognosis of future disease risk
- is linked to a specific medicine or device (could be an accessory)
- provides clinical decisions (even if the final decision is made by the clinician)
- ·offers treatment decisions (such as medicines and dosages)
- monitors drug usage or biological analyses (eg insulin/blood glucose)
- matches organ donors with recipients
- treats or might prevent a disease
- assesses images uploaded to it to make a diagnosis or assessment or to monitor a disease state or potential disease state
- provides remote access to any clinical condition of a patient (whether including an alarm)
- provides an automated treatment pathway for an individual patient
- provides compensation for physical impairment such as magnification of images or amplification of sounds alongside claims for use by the visually/auditorily impaired
- detects contraindications or drug interactions and excessive doses
- uses data to facilitate conception or contraception, even if the data is input manually by the patient.
Annex 2: examples of non-medical device software
Examples of software unlikely to be characterised as a medical device, unless medical claims are made, include software that:
- records images (without clinical interpretation)
- provides statements of risks specifically relevant to the general population or a large proportion of it (so that its applicability to any individual is limited)
- monitors heart rate or nutrition or glucose levels for sport or fitness or general wellness purposes
- is a medication reminder
- provides a log/journal/tracker without analysing or changing the data
- provides tips or advice on prevention for a wide group of the population of support groups
- reproduces a paper document in digital format (in the UK)
- follows a public/known procedure/treatment (no decisions) (in the UK)
- has decision points, but the HCP makes the decisions on the pathway (if all relevant pathways are included) (in the UK).
