Digitalisation is making its way into all areas of life, including health care and patient monitoring. Taking a closer look, this means the use of software becomes prominent. But where are the lines drawn between software for patient management, software as a stand-alone or part of a medical device, and where is the intersection with a Digital Health Application (DiGA, German acronym for Digitale Gesundheitsanwendung)? MDCG 2019-11 “Qualification and classification of software – Regulation (EU) 2017/745 and Regulation (EU) 2017/746” offers help for decision-making.
Software included in products and standalone-software/medical apps
In medical applications, there are different types of software that are distinguished in regulatory terms:
- software can directly control a (hardware) medical device (e.g., software in a radiotherapy device).
- software can provide immediate information relevant to decision-making (e.g., software in blood glucose meters).
- software can support medical professionals (e.g., software for the interpretation of ultrasound images).
- software can analyse various medical parameters and diagnose diseases (e.g., risk of heart attack based on the ultrasound images).
- software can monitor mental/vital signs and warn the user in case of risks (e.g., smartwatch app that sends alert notification to user in case of irregular heartbeats).
- software can be used for patient management, billing and staff planning in a hospital.
Not all software used in the healthcare sector is also a medical device. But when is my software a medical device and thus relevant for approval?
When is a software a “Medical Device Software” (MDSW)?
In defining “medical device”, the MDR focuses on the type of product (instrument, apparatus, device, software, implant, reagent, material, or other article) and on the intended purpose of the product.
The European Commission has published a decision tree to help with the question “Is your software a Medical Device” and assist in the qualification of software as an MDSW (Figure 1).
Figure 1 : Decision steps to support qualification of medical device software (MDSW) according to MDR
The MDCG-2019-11 “Qualification and classification of software – Regulation (EU) 2017/745 and Regulation (EU) 2017/746” defines software as a set of instructions that process input data and generate output data. Input data is any data that is provided to a software to generate output data. Types of input data can be
- entered by humans via input devices,
- identified by speech recognition or
- read from a digital document,
Output data can include
- on-screen displays,
- print data,
- audio data or
- digital documents
The decision as to whether it is Medical Device Software or not can be made step by step according to the guide:
- Decision 1: If the software does not meet the given definition on software, it is not covered by the MDCG-2019-11 Guide.
- Decision 2: If the software controls or influences the medical device, does not itself fulfil a medical purpose and does not generate information for a medical purpose, it is not an MDSW and is considered only as a part/component or as an accessory of a medical device, it is not covered by the MDCG-2019-11 Guide, but must comply with the requirements of the MDR.
- Decision 3: If the software does not perform any action on data or any action beyond storage, archiving, communication, simple search, lossless compression, it is not an MDSWand not covered by the MDCG-2019-11 guidance and does not have to comply with MDR requirements.
- Decision 4: If the software is not for the benefit of individual patients, but e.g., for bringing together data of a population or for epidemiological studies, it is not an MDSW, does not fall under the MDCG-2019-11 guideline and does not have to fulfil MDR requirements.
Medical Device Software (MDSW) is software that is intended to be used, alone or in combination, for a purpose specified in the definition of a “medical device” in the MDR or IVDR, whether or not the software is independent of or controls or influences the use of a device [MDCG-2019-11].
- Decision 5: If the software does not meet the MDSW definition, it is not covered by the MDCG-2019-11 guidance and does not have to meet MDR requirements.
The risk of harm to patients, users of the software or other persons in connection with the use of the software in healthcare, including possible malfunction, is not a criterion for classifying the software as MDSW.
A similar decision tree was published for the IVDR (Figure 2). The individual decision-making steps are also described in the European Commission’s information document.
Figure 2 : Decision steps to support the qualification of medical device software (MDSW) according to IVDR
What is the class of my MDSW according to MDR or IVDR?
For classification according to MDR, all implementing provisions in Annex VIII of the MDR are taken into account, especially 3.3 and 3.5.
Rule 11 of the MDR is intended for software for decision-making with diagnostic or therapeutic purposes or software for monitoring physiological processes, therefore most MDSW is classified under Rule 11.
However, since the MDSW is also classified as an active medical device, even more rules of the MDR would be applicable:
- Rule 9 mainly categorises the risks associated with the exchange/delivery of energy for therapeutic purposes. This is relevant if the MDSW controls the energy delivery/exchange indirectly (directly is not possible due to the lack of hardware). By default, the MDSW is assigned to class IIa here. If a potential hazard is possible through the energy output/exchange, the MDSW is classified as class IIb. The same would apply if the MDSW (indirectly) controls or monitors class IIb products. If the MDSW (indirectly) regulates or controls the performance of active implantable devices, it is even classified as class III.
- Rule 10 categorises active devices for diagnostic and monitoring purposes and is relevant when the MDSW
- indirectly controls an energy delivery or a distribution of radiopharmaceuticals, or
- if it enables the direct diagnosis or control of vital bodily functions.
The standard case here is class IIa, in connection with the illumination of the patient in the visible spectral range even class I, and for the control of vital physiological parameters class IIb, if there is an immediate danger to the patient here. If the MDSW (indirectly) controls or monitors medical devices for radiological diagnostics or therapy or interventional radiology, it is also classified as class IIb.
- Rule 12 – Active devices intended to administer and/or remove substances –> Not relevant as MDSW cannot physically administer and/or remove substances.
- Rule 13 – All other active products –> relevant if no other rule applies –> class I
- Rule 15 – Contraceptive devices –> relevant for MDSW used for contraception –> assigned to class IIb
- Rule 22 – Closed Circuit Systems –> If the MDSW affects/supports an active therapeutic device with an integrated or built-in diagnostic function that significantly determines patient management by the device, it is classified as class III.
For IVDR classification, all classification and implementation rules in Annex VIII of the IVDR are considered. For IVDR-MDSW, all classification rules are relevant.
Headline 2: Are there any class I MDSWs left under the MDR?
Paragraph incl. picture and links:
Annex III of MDCG 2019-11 (Usability of the IMDRF risk classification framework in the context of the MDR) includes a table that compares the patient’s status (Non-serious, Serious, Critical) with the impact of MDSW on the patient’s status in terms of diagnosis or treatment to help interpret Rule 11 of Annex VIII of the MDR.
Figure 3: Classification guidelines for Rule 11
It is noticeable that class I does not occur here. Does this now mean that there are no MDSW class I medical devices under the MDR?
The clear answer is: No.
If neither the first two paragraphs of Rule 11 do apply nor one of the assignments of Rules 9 to 12 in Annex VIII of the MDR, Rule 13 automatically becomes relevant, i.e., the MDSW is class I. This may be the case for MDSW that, for example, contributes to the detection, monitoring, treatment, alleviation of a disease, injury or disability by providing tailored information. The MDCG 2019-11 Guidance itself gives an example of this in Annex IV (Classification examples): an MDSW app to assist conception by calculating the user’s fertility status based on a validated statistical algorithm is class I under Rule 11c.
How relevant are these “basics” for my DiGA?
Qualification as an MDSW and classification according to MDR are important components of the approval of software as a DiGA, as manufacturers of digital health applications must demonstrate that:
- the DiGA is a medical device,
- the DiGA has a medical purpose,
- the DiGA is assigned to a low-risk class (class I or IIa according to MDR or within the scope of the transitional provisions of the MDR, according to MDD) –> an extension to class IIb is planned,
- the main function of the DiGA is based on digital technology,
- the DiGA can demonstrate functionalities for the detection, monitoring, treatment, alleviation of disease, injury or disability,
- the DiGA can be integrated into the care process.
Almost all of these requirements are also the characteristics of an MDSW. Want to learn even more about the requirements for a DiGA? Read about it here on our blog
Did you come across this article by chance and did not even know that your planned app could fall under the MDR or the IVDR? Are you still new to the regulatory jungle? Don’t hesitate, find a way together with us.
Please note that all details and listings do not claim to be complete, are without guarantee and are for information purposes only.
