CEThe CE marking of software, especially medical software made easy
with our expert support

• 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.

• The determination of the class of the device,
• Selection of the CE procedure to be used,
• Declaration of CE conformity of the device.

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.

• 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:

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.

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.

• 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,
• Testing: 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.

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.

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.