Guidance

Guidance for manufacturers on reporting adverse incidents involving software as a medical device under the vigilance system

Updated 15 January 2025

Introduction

This document provides guidance for manufacturers of software as a medical device. It outlines events that may cause indirect harm and are therefore reportable. Read it in conjunction with the guidance on post market surveillance which sets out the general adverse incident reporting obligations on all manufacturers of medical devices including software as a medical device. 

The aim of this guidance is to complement the requirements of SI 2024 No. 1368. You should read it in conjunction with this regulation. Device-specific guidance does not replace or extend these requirements.

What you must report

Any event which meets the three reporting criteria (see SI 2024 No. 1368) is considered an adverse incident and must be reported to the MHRA.

For software as a medical device (SaMD), indirect harm is the most probable outcome of adverse incidents and may occur as a consequence of the medical decision, action taken/not taken by healthcare professionals and/ or patients and the public based on information or result(s) provided by the SaMD.

Examples of indirect harm include:

• misdiagnosis
• delayed diagnosis
• delayed treatment
• inappropriate treatment
• absence of treatment or
• transfusion of inappropriate materials.

Examples of what indirect harm may be caused by:

• imprecise results
• inadequate quality controls
• inadequate calibration
• false positive or
• false negative results.

For self-testing devices, a medical decision may be made by the user of the device who is also the patient.

Examples of types of adverse incidents that may be reportable

Performance issues

Adverse incidents resulting from the failure to perform according to the performance characteristics specified by the manufacturer. Examples might include, but are not limited to the following:

• mental health tool fails to alert healthcare professional as per the instructions for use when user’s mental health status reaches a predetermined clinical threshold
• compatibility issues arising from operating system updates for continuous glucose monitoring (CGM) apps such as loss of ability to see real time data leading to inappropriate or absence of treatment or a delay in diagnosis
• remote monitoring of vital signs in mental health hospitals and care homes could lead to delay to diagnosis and treatment if it fails to detect the correct physiological parameters (for example, pulse rate, respiratory rate and oxygen saturation)
• activity tracker tools which fail to alert health professionals when a resident in a care home is deteriorating, or is at risk of physical deterioration, could cause delay to diagnosis and treatment
• artificial intelligence (AI) diagnostic and triage tools failing to identify clinically relevant brain image findings related to acute stroke leading to an incorrect, delayed or missed diagnosis
• AI tool intended to identify ‘normal’ x-rays misses an abnormality leading to an incorrect, delayed or missed diagnosis
• accelerated MRI software that degrades the appearance of anatomical and pathological structures leading to an incorrect, delayed or missed diagnosis
• software tools that read the result from a lateral flow test incorrectly resulting in an infected individual not isolating and therefore spreading a disease

Diagnostic accuracy issue

Adverse incidents resulting from the failure of diagnostic tools. Examples of reportable adverse incidents of devices such as symptom checkers (Guidance Appendix 1 – Symptom checkers) which are intended to be used by lay users.

• symptom checkers used to analyse inputted symptoms and possibly identifying an incorrect medical condition or failing to identify a correct condition leading to a misdiagnosis, false reassurance or delay to treatment
• dermatology apps used for melanoma detection providing inaccurate results which could stop an individual from seeking an expert clinical opinion from a healthcare practitioner

Decision support software resulting in harm

Examples of reportable adverse incidents of devices such as clinical calculators (Guidance Appendix 2 – Clinical Calculators) which are intended to be used by healthcare professionals.

• overestimated / underestimated scores in predictive algorithm used to support medical practitioners to help assess the potential risk of cardiovascular disease in patients - as a result, may cause inappropriate or absence of treatment
• medication error occurring from incorrect calculations of dose calculators
• patients receiving inappropriate treatment for radiotherapy due to incorrect dose calculations

Issue with connected hardware/software

Any harm caused by the device that runs the software should also be reported. Examples might include, but are not limited to the following:

• a multipurpose watch running a SaMD monitoring app causes skin burns
• use of non-compatible antivirus software causes malfunction of the SaMD

Human-device interface problem

Examples of adverse incidents which result from failures in the user interface:

• failure of keyboard or touch screen to allow accurate input of data
• failure to account for colour blindness leads to a missed warning in the interface
• unclear user interface instructions or usability resulting in variable understanding of required input data or inaccurate data entry (for example, when a user fills out a yes or no questionnaire, if the position of the yes or no option changes midway through the questionnaire, this may cause the user to select an incorrect option leading to inaccurate data entry - another example is when a user must select an incorrect option to proceed to the next question as the correct option is not available)

Use error resulting in harm

The manufacturer must report incidents occurring because of use error (see Medical devices: post-market surveillance requirements) if they conclude that they meet the above criteria, regardless of whether the incident has resulted in a serious deterioration in health. The report should include consideration of whether improvements in the device design including usability or clearer instructions/training could reduce the risk of reoccurrence of the use error and may be impacted by the number of use errors occurring. For example:

• triage tool used off-label (against disclaimer) results in a missed or incorrect diagnosis
• user makes mistake entering values into contraception app leading to user relying on incorrect output and consequently gets pregnant
• user instals an anti-virus tool not recommended by the SaMD manufacturer that causes performance issues with the SaMD

Inadequate labelling and instructions for use

Any incident which has resulted from inadequate or misleading labelling is reportable. Additionally, any adverse incident such as the example below resulting from confusing or inadequate instructions for use is reportable:

• inadequate or missing cleaning instructions for a tablet based SaMD leads to patient cross contamination - manufacturers shall consider the risks from the device system (for software this will include hardware equipment)

Computer system security problem

Examples of reportable adverse incident impacting dosing, functions, user interface, safety information and patient status due to systems identified as having vulnerabilities to a cyber-attack:

• during active patient monitoring, this could cause loss of monitoring and/or loss of alarm
• corruption of transferred patient data leading to incorrect, delayed or misdiagnosis

How to report

Follow the advice on reporting under vigilance in the MHRA guidance on post-market surveillance.

Report as individual events

Manufacturers must report adverse incidents, such as the examples in any of the above categories, to the MHRA. Manufacturers should monitor customer feedback on social media channels and UK app stores and report where appropriate. 

Each initial report must lead to a final report unless the initial and the final report are combined into one report. The final vigilance report should include the manufacturer’s final assessment, including root cause and details of any similar incidents and corrective or preventative actions with timescales as appropriate.

Report as periodic summary reports (PSR)

Some adverse incidents are appropriate for periodic summary reporting, see Medical devices post market surveillance. Details of the timing and content of periodic summary reports should be arranged on an individual basis with the MHRA.

Report at time adverse trend is identified

Manufacturers must submit a trend report (see Medical devices post market surveillance) to the MHRA if there is a significant increase in the number or severity of incidents compared to pre-determined thresholds based upon expected incidents, and therefore having the potential to adversely impact the required risk analysis.   

The manufacturer should have suitable systems in place to enable proactive scrutiny of trends occurring with their devices. A trend report is required where this is a significant increase in the rate of already reportable incidents, incidents that are usually exempt from reporting and events that are usually not reportable.

Report information

Individual reports are to be submitted via the MORE portal. To use the MORE portal, you must register with us.

We expect you to include hardware and operating system model and version numbers, if relevant, in the MIR form.

If you are interested in setting up an API to submit your reports directly from your internal IT systems to ours, contact us for further information. See the MORE production API guidance document for more information about how to set up your API.