CE certification for medical software applications
Software for medical purposes needs to be CE certified. Usually this involves a notified body, which creates additional cost & lead times.
In this article we will discuss some fundamental facts and requirements around CE certification for medical software applications. This will be a rough first overview – there are many other requirements which would need many pages of information. Also please note that this information is not legally precise – it serves as a first overview of what needs to be done and considered.
MDR (medical device regulation) EU 2017/745
Starting with the 26th of May 2021, new medical devices (and medical software is seen as a „medical device“ under this regulation), need to follow the MDR in the EU. (Note: software might also be seen as an in-vitro diagnostic, where it would need to follow the IVDR which is closely related to the MDR. This is the case if the source data is predominantly from human tissue / fluid / … samples)
Quoting from the MDR:
„It is necessary to clarify 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. The qualification of software, either as a device or an accessory, is independent of the software’s location or the type of interconnection between the software and a device.“
Article 2 (1) defines a medical device:
(1) ‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
— diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
— diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
— investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
— providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations,
and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means.
Central to this definition is that the manufacturer sets an intention for the usage of the software for medical purposes. As an example, the audiometry test for Spotify (to adjust the equalizer) is not a medical device, even if it maybe even has a similar algorithm to a software used by a physician to measure the hearing capabilities of a patient. The latter is a medical device, because it is used for medical purposes.
In addition to that, the software should perform an action on data different from storage, archival, communication, or a simple search. Rule of thumb: The software should generate new information from the input data.Viewers & databases for patient data for example would therefore not fall under the medical device regulation.
Furthermore, the software should perform actions for the benefit of individual patients. As an example, software which handles the DRGs used for accounting purposes with the patient’s insurers would not fall under the MDR.
Classification
The software is classified in risk classes: (Class I), Class IIa, Class IIb, Class III. The higher the class, the more requirements of the manufacturer. Class I is in brackets because usually software will start in Class IIa. Only Class I is possible in self-certification, starting with Class IIa you need to work with notified bodies which will check your software, your technical documentation, your quality management system, your risk management system, etc.
The software is classified according to the risk level. Software which could result in significant, irreparable harm to the patient or death would have a higher risk class. The MDR offers several rules do decide in which class the software needs to be placed.
Class IIa
The notified body will verify the QMS (quality management system) and the technical documentation of at least one representative product of each product category.
Class IIb
The notified body will verify the QMS (quality management system) and the technical documentation of at least one representative product of each generic product group.
Class III
The notified body will verify the QMS (quality management system) and the technical documentation of each product.
Required Parts & Systems, and norms
The following items are part of the technical documentation, and therefore required for medical software projects. Generally you will need to check in which revision the standard is to be applied (as there are occasional updates to the standards, denoted by the year after a colon, for example: ISO 15223-1:2021).
Quality Management System
Usually EN ISO 13485 („Medical devices — Quality Management Systems — Requirements for regulatory purposes“) is used as a quality management system standard.
Product manual
The technical documentation also includes any product and service manuals for your software product.
Risk management
EN ISO 14971 („Medical devices – Application of risk management to medical devices“) is used as a risk management standard. A risk management plan needs to be created.
The process is as follows:
- risk analysis (can be done using FTA or FMEA for example)
- risk evaluation
- risk control
- evaluation of overall residual risk acceptability
- risk management report
And there is a production and post-production information part – you will need to monitor the market after your software is on the market, and adjust your risk management, react to unforeseen problems, etc.
Usability
IEC 62366 („Medical devices – Application of usability engineering to medical devices“) is used as usability standard.
Clinical assessment
EN ISO 14155 („Clinical investigation of medical devices for human subjects — Good clinical practice“) (Trials), MDCG 2020-13 (CER), MDCG 2020-1 (SW CER)
Electrical safety (where applicable – for devices which also use hardware)
IEC 60601 (IEC 60601-1 is: Medical electrical equipment – Part 1: General requirements for basic safety and essential performance). There are many substandards depending on the type of medical equipment you are building.
Software lifecycle process
IEC 62304 („medical device software – software life cycle processes“). This standard specified the life cycle requirements for the development of medical software and software within medical devices. It is one of the most important standard to know, as it directly impacts the software development process. Ideally it should be studied and understood before software development is started, so that the right tooling choices are made.
It requires a certain approach to software development, which needs to be documented well. It can also be set up as agile development with sprints.
The software is assigned a risk class (A / B / C, not related to I / IIa / IIb / III), and depending on the class additional parts need to be done. The risk class depends on how much harm the software can cause (where probability of software failure is assumed to be 1). Only risk control measures external to the software will be considered. For example, if there is a software controlled syringe driver, and a mechanical limitation how far it can go, this is a valid external risk control measure. If the software can cause serious damage or death, it will be assigned Class C.
For example, for Class C manual code reviews are required, which significantly increases the project cost.
Wikipedia has a good overview table.
A software configuration management process with change control is required. (for example using Git). You will also need to consider so-called SOUP: software of unknown provenance (which would be libraries you use, etc.), and control their revisions.
An audit trail is required for changes. For example, if the risk management assesment finds that certain features need to be changed (change request, along with a problem report), there needs to be an audit trail to this requirement – ideally up to code level.
Labelling
EN ISO 15223-1 („Medical devices — Symbols to be used with information to be supplied by the manufacturer — Part 1: General requirements“).
You will need to include certain labels and information in your software, easily accessible for the end user. This will include a certain thing called the UDI (unique device identifier). This identifies your product in the marketplace, and consists of two parts: UDI-DI (device identifier) and UDI-PI (production identifier).
There are certain requirements how you will need to present this information and include it on your devices, and CDs (if you ship CDs), etc.
More
There are more requirements to be met, depending on the software and/or medical device combination.
For example, the RED (radio emissions directive) needs to be applied to devices which intentionally emit and/or receive radio waves for the purpose of radio communication, etc. – devices using WiFi or Bluetooth need to observe this.
For other parts which are required, but not available as standards, „state of the art“ guidance should be used. Currently (?) there is no EU standard for cybersecurity, but there is an FDA guidance for cybersecurity which can be used.
Also something worth looking int is IEC 82304, which describes the software validation of health software.
Post Market Surveillance
Every manufacturer needs to do this for every product. This is an integral part of the quality management system. You have to collect data about the quality, performance and safety of your product.
There are certain reporting requirements for incidents related to your software.
You will also have to monitor similar products, and learn from their problems.
All this serves to increase the safety of the product, and allows to act quickly if a product is endangering users and patients.
Artificial intelligence products
A proposal for a regulation of artificial intelligence products within the EU already exists, since May 2021. It is to be expected that this regulation or a similar one will be enacted at some point, and part of the requirements for medical software applications which use AI.
For AI the selection of the training and test data is of paramount importance. You will need to have a sufficient amount of data, which represents the patients well. You will also need to have labels for supervised learning which follow a gold standard, or are state of the art. You will need to check that the labels are free of bias.
You will need to have the legal permission to use and store the data.
When using deep learning methods, which are essentially a black box, you will not be able to verify the algorithm. Therefore you will need to provide your reasoning why your deep-learning based AI system outperforms „classical“ code, or simple AI methods. In the risk management, you will also need to check for AI-specific topics, e.g. „label leakage“.
The FDA (federal drug administration, USA) distinguishes continuously learning and „locked“ AI models. Locked models will follow the usual certification procedure. Continuously learning AI models have additional risk – and need to be approached differently.
Do you need support with your medical software project?
We are able to support you and get you in touch with the right partners, who can support you for each part of this process. Contact us here