MHRA-指南-独立软件.doc

Guidance on medical device stand-alone software (including apps)

The following guidance is for healthcare and medical software developers who are unsure of the regulatory requirements for CE marking stand-alone software as a medical device.
Introduction
Many manufacturers, software developer, academics, clinicians and organisations are using software for both healthcare and social care needs.
This guidance explains how this technology is regulated. It covers stand-alone software (also known as software as a medical device) but not software that is part of an existing medical device because this seen to be part of the device, eg software that controls a CT scanner.
Key points and existing guidance
Stand-alone software
Software which has a medical purpose which at the time of it being placed onto the market is not incorporated into a medical device.
Intended purpose
Regulation of medical devices is limited by the intended purpose as defined by the manufacturer. This will include claims given in promotional materials for the device, eg brochures and webpages.
Medical purpose
Software that has a medical purpose could be a medical device. A medical device is defined in the medical device Directive (MDD) as:
“software… 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….”
The other directive where this guidance is applicable is the active implantable medical device directive.
Systems
There is no definition of a system in the directive but there are specific requirements for products placed on the market that combine CE marked devices and non-CE marked products, eg a combination of laptop (not a medical device), software (a medical device) and heart monitoring hardware (an accessory) is considered to be a ‘system’ if these are placed on the market together.
Existing guidance
In January 2012, the European Commission (EC) published a set of guidelines in MEDDEV 2.1/6 - Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices.
These guidelines will help you decide if your software is a medical device or an in vitro diagnostic. The following documents provide useful information to help software developers understand regulations for medical device software:
· European Commission MEDDEV 2.1/1 Definitions of "medical devices", "accessory" and "manufacturer"
· European Commission Manual on borderline and classification in the Community Regulatory framework for medical devices
· Team NB FAQ on Implementation of EN 62304:2006 with respect to MDD 93/42/EEC.
· MHRA Borderlines with medical devices.
Software applications (apps)

Mobile devices have unique qualities because they store personal data, are generally always switched on, have a light source and a camera that can capture high quality images and can provide information such as orientation through in-built sensors. There has been an increase to use the software on these devices for medical purpose.

If these software applications meet the definition of a medical device, it will be regulated by MHRA as a medical device and will have to undergo a conformity assessment.

The words and phrases listed below are all likely to contribute to a determination by the MHRA that the app they were associated with is a medical device:
· amplify
· analysis
· interpret
· alarms
· calculates
· controls
· converts
· detects
· diagnose
· measures
· monitors
There are a number of different types of apps and these could be categorised by function such as;
· Decision support or decision making software that applies some form of automated reasoning, such as a simple calculation, a decision support algorithm or a more complex series of calculations, eg dose calculations, symptom tracking, clinicians guides. These are the types of software most likely to fall within the scope of the medical devices directives.
This includes software which provides personalised guidance based on information it has about a specific individual and makes use of data entered by them, provided by point of care devices or obtained via health records.
· Apps acting as accessories to medical devices such as in the measurement of temperature, heart rate, blood pressure and blood sugars could be a medical device as are programmers for prosthetics.
· Software that monitors a patient and collects information entered by the user, measured automatically by the app or collected by a point of care device may qualify as a medical device if the output affects the treatment of an individual.
· Software that provides general information but does not provide personalised advice, although it may be targeted to a particular user group, is unlikely to be considered a medical device.
· Software that is used to book an appointment, request a prescription or have a virtual consultation is also unlikely to be considered a medical device if it only has an administrative function.
Some decision support software may not be considered to be a medical device if it exists only to provide information to enable a healthcare professional to make a clinical decision as they ultimately rely on their knowledge. However, if the software or app performs a calculation or interprets or interpolates data and the healthcare professional does not review the raw data, then this software may be considered a medical device. Increasingly apps are being used by clinicians who will rely on the outputs from this software and may not review the source/raw data.
Telehealth and telecare

Telehealth is the delivery of health services or information using telecommunications technologies. It uses devices to monitor people’s health in their own home including monitoring vital signs (blood pressure, blood oxygen levels or weight). The data can then be transmitted to a healthcare professional who can observe health status without the patient leaving home. Increasingly, this latter function could be placed on a server and software could be used to interpret the patient data. This could be considered a medical device.
However, consideration should be given to the interface between social care, well-being and health, which can become blurred. For instance an app that uses an accelerometer or gyroscope as a falls detector in epileptic patients is likely to be regulated as a medical device but the same app or device could alert as to whether an elderly person has got up from a chair or bed in a social care context. As a detector of falls of a medical condition the app will qualify under the MDD and be regulated as a medical device but in the latter case it will not meet the definition of a medical device and the medical device regulation would not apply.
Home telehealth systems with connected monitoring devices
MHRA requires individual devices to be CE marked as medical devices but does not require a system to be CE marked as a medical device unless it is placed on the market as a single product. Items such as the hub and possibly the motion detector (depending on the claims of the manufacturer) are not likely to be CE marked medical devices as they do not have a medical purpose. However, the software that runs on the server and interprets or interpolates the patient data is likely to be a medical device and would be regulated as such.
General requirements

For all software and apps that meet the definition of a medical device, the following guidance will be applicable.
Classification
Advice on classification is given for general medical devices but for software, an active device, the following existing classification rules are most applicable:
· Implementing rule 2.3 - Software, which drives a device or influences the use of a device automatically falls into the classification of that device.
· Rule 9 - Active therapeutical devices are generally Class IIa – however if potentially hazardous then Class IIb.
· Rule 10 - Active devices intended for diagnosis are generally Class IIa – however if potentially hazardous then Class IIb.
· Rule 12 - All other Active Devices are class I.
· Rule 14 - All devices used for contraception or the prevention of the transmission of sexually transmitted diseases are in Class IIb.
While compliance class I devices is based on self-declaration by the manufacturer, all other devices require use of a notified body to assess compliance.
Manufacturers of Class I devices, must also register with MHRA.
Clinical data is required for all medical devices and for some novel software clinical investigations may be needed.
Post market surveillance
Manufacturers have a responsibility to implement an effective post-market surveillance system to ensure that any problems or risks associated with the use of their device once freely marketed are identified early, reported to competent authorities, and acted upon. This is known as the medical devices vigilance system.
For software, a system of registration / activation may aid the manufacturer trace devices that have been distributed by third party distributors or by app stores. This is important when undertaking any corrective action such as a recall.
Instructions for use (IFU)
These are not needed for Class I and IIa devices if they can be used safely without any such instructions. If instructions are needed, they can be provided electronically if the device is intended for ‘professional users’ and the electronic instructions for use of medical devices regulations apply. Otherwise, the paper IFU shall be provided with the device. This could be supplied at activation of the software. The IFU should contain all the information needed to verify whether the device is properly installed and can operate correctly and safely.
Validation
Software devices must be “validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification.”
Supplier/Distributer
Unlike the MDD, the UK’s medical device Regulations and amendments place requirements on suppliers of medical devices. UK suppliers/app stores should be aware of their responsibilities under the regulations.
Adverse Incident Reporting
Manufacturers should follow the guidance for reporting adverse incidents and field safety corrective actions to MHRA.
Specific software considerations:
Software for sports or leisure
In general, products for sport or leisure purposes are not considered to be medical devices. However, in some cases, products aimed at sports people may be considered to be medical devices. For further advice see MHRA borderlines with medical devices (378Kb).
Viruses and antivirus protection
Currently only a small number of smart phones are protected by security software. Any virus that attacks the mobile phone operating systems may also affect the medical device app and this may not work as the manufacturer intended and the user may be unaware of this. Incorrect use of antivirus software is also known to affect performance of medical devices (71Kb) .
Software that makes recommendations based on patient entered data
Software intended to carry out further calculations, enhancements or interpretations of patient images or data, is a medical device. It’s also a medical device if it carries out complex calculations, which replaces the clinician’s own calculation.
Software that replaces existing paper charts
These are not usually considered to be a medical device, however, the addition of complex functionality to the product can make it a medical device.
Software combined with non-medical products
A system can comprise medical devices that need to be CE marked for a medical purpose as well as other devices that could be used in a social care context but will not be regulated as a medical device.

In cases where the system incorporate devices which do not bear a CE marking or where the chosen combination of devices is not compatible in view of their original intended use, the system will be treated as a device in its own right and as such be subjected to the relevant conformity assessment.

The MDD requires the whole system to be safe. This is particularly pertinent to stand alone software, where the manufacturer must demonstrate compatibility with the recommended hardware platforms.
Other software types that may be medical devices
The following types of software may be medical devices if the manufacturer has assigned to them a medical purpose:
· spread sheets – particularly if they provide complex functionality that is beyond that of existing paper charts
· documents with macro or script enabled functions – complex medical applications can be written with languages such as visual basic
· interactive web pages – these can utilise programing languages such as JavaScript to produce medical applications
· un-compiled software – if all of the information is provided to install the software then the MDD may apply
· freeware / open-source software – the MDD will apply to both methods of software distribution, it applies to products that have been “placed on the market” rather than sold.
Software which uses a physical accessory
If the app has a medical purpose and relies on a physical accessory to obtain data to function, eg a device to position a smartphone’s camera, it will be a medical device and the device that positions the camera could be viewed as an accessory to the software. Accessories are classified in their own right separately from the device with which they are used.
Software that utilises a patient’s genetic information together with other data from a patient record for a medical purpose.
The guidance document MEDDEV 2.1/6 gives the example of "software that integrates genotype of multiple genes to predict risk of developing a disease or medical condition" and considers the software to be an in-vitro diagnostic.
Software for in-house use only
Guidance on in-house manufacture may be applicable.
Disclaimers
A number of apps have a disclaimer saying “for information only” or “for research use only” or other statements that try and reduce the responsibilities of the manufacturer. However, if an app qualifies as a medical device and is placed on the market for a medical purpose will still need to comply with the MDD.

General disclaimers (for example ‘this product is not a medical device’) are not acceptable if medical claims are made or implied elsewhere in the product labelling or associated promotional literature.
Anecdotal quotes and testimonials are considered to be implied claims by the manufacturer if they are repeated in product literature.
Software that is not a medical d