Europe: Medical Devices Coordination Group issues guidance on the classification of software as a medical device

The Medical Devices Regulation, the “MDR”, which comes largely into force in May 2020, will introduce significant changes to the way in which software used in a medical context will be regulated in the European Union. The medical devices industry has been eagerly awaiting additional guidance on how these new provisions are likely to be interpreted and this has now been provided by the Medical Devices Co-ordination Group, the MCDG.

The MCDG is a new body created by the Regulation to provide advice to the Commission and the Member States in order to ensure “a harmonised implementation of the medical devices Regulations.” Its members include representatives from the Member State competent authorities that are responsible for the enforcement of the Medical Devices Regulation and it is chaired by a representative of European Commission. A number of trade associations, non-government organisations, physician organisations and patient groups also attend meetings of the MCDG as observers. The guidance is stated, however, not to be a European Commission document and “cannot be regarded as reflecting the position of the European Commission.” It is, nevertheless, very likely to reflect the way in which Member States will approach questions concerning the classification of software as a medical device.

Software is defined for the purposes of the guidance (there being no definition in the MDR itself) as “ a set of instructions that processes input data and creates output data”. The basic rule, as set out in Recital 19 to the MDR is that “software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device.”

Software is deemed to be an active device and software which drives a device or influences the use of a device falls within the same class as the device. If the software is independent of any other device, it is classified in its own right.

The classification rules in Chapter 3 of the MDR provide at Rule 11 that

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: — death or an irreversible deterioration of a person's state of health, in which case it is in class III; or — a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.

All other software is classified as class I.”

Classification is important in determining the route by which a medical device can earn its CE mark and the type of data that the manufacturer will have to generate to support that submission.

The new Guidance from the MDCG provides some helpful algorithms to assist in determining:

(a) whether or not software falls within the definition of a medical device and thus falls to be regulated by the MDR; and

(b) what should be the classification of software determined to qualify as a medical device.

Some illustrative examples are also provided at Annex IV. The industry has been greatly puzzled by sub-rule 11 (c) which suggests that some medical devices may be classified as Class I and, thus, subject, to self- assessment by the manufacturer. The only example of software to be classified as class 1 is an app supporting conception by calculating the user’s fertility status based on a validated statistical algorithm. It is difficult to see, however, why this would not qualify under Rule 11 (b) as software intended to monitor physiological processes and thus fall into class II a. This example suggests that there may be some room for the exercise of sensible discretion by the competent authorities although companies would be wise to explore the boundary with the relevant competent authority during the development of a product intended to follow the class 1 route to conformity assessment and CE marking.

The European Commission has promised to release 47 more guidance documents in the coming days. Medical device companies will have much to absorb before next May.