When is software to be classified as medical devices and subject to CE marking?
The MDR (Medical Device Regulation) qualifies software as follows:
- If software is used independently of another device, it is to be classified as a stand-alone medical device; this is the rule for stand-alone software.
- The regulation for software connected to another device, hardware or software states that the software controlling a device or affecting the use of a device must fall into the same classification as the device. Software that is integrated into a medical device can therefore be called medical software.
What steps must be taken in the conformity assessment process for medical software?
Medical software goes through exactly the same process as other devices/medical devices to obtain CE marking before it is sold in the EU. The following phases are part of the CE marking process:
- The determination of the class of the device,
- Selection of the CE procedure to be used,
- Declaration of CE conformity of the device.
How is medical software classified under the Medical Devices Directive?
The MDR provides for classification rule II for software, which defines software for medical purposes as follows:
Software intended to provide diagnostic or therapeutic information shall be classified in Class IIa unless such information determines:
- the death or irreversible deterioration of a person’s state of health; in this case, it is assigned to Class III; or
- a serious deterioration in a person’s state of health or a surgical intervention, in which case they are assigned to class IIb.
software required to control physiological processes is assigned to class IIa, unless it is used to monitor vital physiological parameters, where the nature of the variations of these parameters could lead to an immediate danger to the patient, in which case it is assigned to class IIb.
All other software is classified as Class I.
- Class I: Manufacturers of medical devices can carry out the conformity assessment and the CE marking independently. They must notify their national competent and recognised regulatory authority.
Which software products should NOT be regarded as medical software and therefore must not bear the CE mark?
The following software examples are not medical devices:
- Software systems or applications that manage administrative patient data, such as scheduling, billing,
- Software related to prescription management systems, however, drug dose computers that use patient data such as weight or body mass index are medical devices,
- Systems that store patient data without data processing,
- Radiological Information Systems (RIS).
The following tabular classification gives a more detailed insight into software accepted as medical devices:
| Software as a medical device |
Software that is not considered a medical device |
| Intended use: For diagnosis |
Intended use: For diagnosis
Purpose: For documentation only |
| Intended use: For therapeutic purposes |
Intended use: For research and teaching |
| Monitoring of physiological processes |
Not specifically intended for a medical purpose |
Is the qualification of medical software subject to CE marking always clear?
However, it can sometimes be difficult to qualify software as a medical device. Borderline cases usually exist with standalone software, such as software, which could be used simultaneously for general wellness purposes or for treatment purposes. In this case, the qualification as a medical device results from the demands on the intended purpose.
Example:
- The purpose of a mobile app states that statistics are recorded and calculated about what the user eats and what amounts of carbohydrates, fat, etc. This app is intended for general wellness purposes, so the app is not a medical device.
- The intended use of the same mobile app (technically) indicates that statistics are recorded and calculated about what the user eats as well as the amounts of carbohydrates and fat, but this time for diabetes management. In this case, the app is a tool for treating a disease - so is a medical device.
Thus, the same software could be qualified as a medical device or not, depending on the decision of the responsible person about what to achieve with this software.
What is the procedure for obtaining the CE marking for medical software?
The procedure for obtaining the CE marking depends on the risk class of a medical device:
Annex II: Technical documentation
Creating technical documentation is an important part of any certification process. The term technical documentation (or technical dossier) refers to all documents that a medical device manufacturer must submit. The technical file is a prerequisite for the conformity assessment and thus for the approval of medical devices.
a) Medical Devices Directive 93/42/EEC (MDD)
Manufacturers are required by law to demonstrate compliance with the medical software requirements set out in the Medical Devices Directive (93/42/EEC). This conformity is demonstrated by the technical documentation. Section 4 of Annex II to the European MDD also states that manufacturers of medical devices entering the European market must have their design dossier reviewed by a notified body. The dossier should describe the design, manufacture and performance of the product and contain the documents necessary to assess the conformity of the product with the requirements. The entire content of the technical dossier should be included in the interpretation dossier, as the purpose of the technical dossier is to demonstrate compliance with the applicable directives.
b) Medical Device Regulation (MDR)
Annex I of the Medical Devices Regulation (MDR) defines the requirements for the product and Annex II defines the requirements for the documentation. This must include:
Marking of the product (e.g., with an UDI)
- Product description, including variants, configuration and accessories
- intended use
- Labelling (packaging, instructions for use, etc.)
- Information on the design and manufacture of the product
- Information on risk management
- Verification and validation of the product and thus proof that the product meets the general safety and performance requirements.
The MDR goes one step further by including post-market monitoring and its planning and implementation in the technical documentation. It shall lay down the relevant requirements in Annex III.
Manufacturers of class IIa and IIb medical devices are not required to submit a design dossier for verification by a notified body. In addition, manufacturers of Class I medical devices may carry out their own conformity assessment activities due to the low risk classification associated with the product.
Thus, only manufacturers of Class III products must submit a design dossier to a notified body. The design dossier should contain the technical documentation together with a declaration of conformity and a description of the design, manufacture and performance of the product.
What are the requirements for the user manual or manual of medical software?
Each medical device should be accompanied by instructions for use, unless the device could be considered as belonging to risk class I or IIa and could be used safely without such guidance. Directive 93/42/EEC clearly defines which items should be included in the instructions for use, such as safety instructions. Maintenance information should also be part of a user manual.
How are medical software bug fixes and enhancements handled from a CE marking perspective?
Annex XI deals with production, and software production consists of installation, configuration and testing:
- Installation: Transfer the software to a microcontroller, installation on a server, on clients, etc.
- Configuration: Define the right configuration files for the customer, using management tools,
- Testen: Test der für den Kunden definierten Endkonfiguration, Test der in einem Produktartikel integrierten SoftwareTesting: test of the final configuration defined for the customer, test of the software integrated in a product article
These steps need to be monitored very carefully, some can be done by the customer and need to be double checked. A deviation from the expected behavior is very common with software. It is therefore imperative to have procedures to handle these tasks for the software to work properly.
A complete quality system set out in Annex IX shall include procedures for correcting errors and extensions. This also applies to procedures set out in Annex XI. Collecting bugs and extensions is a mandatory task, based on the requirements of MDR Article 10.
What harmonised standards can be applied to medical software?
Applying the following standards is the best thing to do before any project on CE conformity of medical device software.
The harmonized standards (see Reference 4) for software are IEC 62304, IEC 62366 and Section 14 of IEC 60601-1. We can also add IEC 82304-1, which is not yet harmonised but is below the scope of observation of notified bodies. All four standards require manufacturers to have a software development control process.
Does the conformity assessment for medical software have to be carried out again with each update/upgrade?
Software is updated very frequently, with important changes to existing features or even new features. When software is updated annually with significant changes (which is often the case with standalone software), an annual Post Market Surveillance Report (PSUR) is required, regardless of class; there are differences in the sampling plans for Class IIa and Class IIb after the first conformity assessment. If you update your software every year, this sampling plan is not relevant because the notified body needs to review the changes, regardless of the class.
All this also applies to Class III software, but with more effort in the review of the clinical trial and clinical evaluation by the notified body and the group of clinical experts.
What do manufacturers have to do to obtain the CE declaration of conformity for medical software and to apply the CE mark?
If the documentation clearly follows a software development process that conforms to the standards cited above, a notified body will issue a certificate of conformity depending on the class of device. The manufacturer then declares conformity.
