Software as a medical device in light of the new MDR: 12 points of consideration for developers (part 2 of 3).

On May 26, 2021, the Medical Device Regulation (EU 2017/745), better known as the Medical Devices Regulation (“MDR“), became applicable. The MDR builds on the old rules on medical devices, but at the same time is much more than the result of polishing up those old rules. The MDR brings change. Especially for developers of medical software (including apps). In a series of three in-depth blogs, we will list 12 important points to take into consideration.

Structure of the blog series

In the first blog, we discussed two points of consideration: the qualification of software as a medical device and determining the risk class.

In this second blog, we discuss six points of consideration: obligations for manufacturers (the term for software developers used in the MDR), the EU Declaration of Conformity and CE conformity marking, general safety and performance requirements, technical documentation, clinical evaluation, UDI and Eudamed.

In the third blog, we discuss the final four points of consideration: post-market obligations, vigilance (following up on incidents and calamities), the so-called Person Responsible for Regulatory Compliance (“PRRC“) and transitional provisions.

Obligations for manufacturers

Manufacturers are subject to numerous obligations under the MDR. One of the obligations is to ensure adequate financial coverage in case of liability if the medical device proves to be defective. In practice, the manufacturer can do this by taking out insurance, while taking into account the risk class to which the medical device belongs.

Another important obligation is to set up a quality management system to meet the provisions of the MDR as effectively as possible and in a way that is proportionate to the risk class to which the software belongs. The quality management system must be applied, maintained, updated and continuously improved. The MDR also specifies which aspects must at least be part of the quality management system. These include, inter alia:

• a strategy for compliance with applicable laws and regulations;
• identifying which general safety and performance requirements must be met and to what extent they can be met;
• the risk management system;
• clinical evaluation;
• product realisation;
• technical documentation;
• the system for post-market surveillance; and
• procedures for monitoring and reporting incidents and emergencies and processes for product improvement.

In this second and in the third blog, we address many of these obligations.

The marketing of a medical device requires a declaration of conformity. The declaration of conformity shows that a medical device manufacturer is in compliance with the obligations in the MDR. To determine if this is the case, the basic focus is on the quality management system and technical documentation. Without a sound quality management system, there will be no declaration of conformity, and without a declaration of conformity, there is no medical device that can be placed on the market. Thus, a sound quality management system is essential.

EU Declaration of Conformity and CE Conformity Marking

Before a medical device can be placed on the market, a conformity assessment must be carried out. It must be determined whether the medical device meets the requirements that follow from the MDR. The conformity assessment – there are several ways, which are laid down in Annexes IX through XI of the MDR – is (among others) based on analysis of the quality management system and the technical documentation. Depending on the risk class in which the medical device falls, the manufacturer may independently draw up an EU declaration of conformity (risk class I) or a so-called notified body must be involved (risk classes IIa, IIb and III). In the Netherlands there are three notified bodies.

The conformity assessment is followed by the EU declaration of conformity. This indicates that the obligations arising from the MDR has been met (naturally only if it follows from the conformity assessment). The EU declaration of conformity must contain the information listed in Annex IV of the MDR. This includes, for example, the name of the manufacturer, the trade name or registered trademarks, the product and trade name and the risk class of the medical device.

An EU declaration of conformity remains valid for up to five years. After that, a reassessment must take place as standard. Furthermore, the EU Declaration of Conformity must be continuously updated. Therefore, if the software is enriched with new functionalities, it is important to determine whether the changes in the software will affect the obligations to be met under the MDR. For example, a further development of software may result in the software falling into a different risk class.

The medical device should then, as far as possible, be provided with a CE conformity marking. This well-known CE mark indicates that the medical device complies with the requirements of the MDR. In principle the CE mark is on the medical device itself, but if that is not possible on the packaging. In case of a Software-as-a-Service (“SaaS“) solution, the EU Declaration of Conformity and the CE marking can be displayed via an information page in the SaaS solution.

General safety and performance requirements

A medical device may only be placed on the market if it complies with the general safety and performance requirements in Annex I of the MDR. To demonstrate compliance with these requirements, it is mandatory to perform a clinical evaluation (see below). The general safety and performance requirements in Annex I of the MDR apply to all medical devices, regardless of risk class.

It follows from the requirements, among other things, that the medical device must deliver the performance intended by the developer and be designed to be fit for its intended purpose under normal conditions. For software in particular, it must be designed to ensure repeatability, reliability and performance in accordance with its intended use. The software must be safe and effective and must not endanger the safety and health of patients and users. If there are risks associated with the use of the software, the risks (disadvantages) must be proportionate to the benefits to the patient. The software must be state-of-the-art and take into account information security, verification and validation. Specifically, the software must be designed and manufactured to eliminate or reduce as much as possible the risk of a potential negative interaction between the software and the IT environment in which the software will operate or interact. Manufacturers are therefore obliged to set minimum requirements for hardware, properties of IT networks and IT security measures and to include these in the instructions for use. Furthermore, the software must be designed to prevent unauthorized access that could impede the operation of the software (security by design).

In principle, the manufacturer is also obliged to provide instructions for use with the software, for example as part of the terms of use or via an information page in the software (for SaaS solutions). The instructions for use must include the intended purpose of the software, patient target group(s) and users, performance characteristics, (contra-) indications, risks for patients and the information that must be communicated to patients, any specific knowledge or expertise required from or by users and warnings and any precautions to be taken for patients and users. Information enabling healthcare providers to choose the appropriate software must also be included in the instructions for use.

Technical Documentation

Annex II of the MDR shows the requirements for the technical information that manufacturers must prepare. The technical information is the basis for the user manual. The information which must be included in the instructions for use must therefore also be apparent from the technical information. On top of that, the technical information goes a step further than the information in the instructions for use and must contain a (more) extensive description of (among other things) the design and technical specifications of functionalities, the risk management system and the results of verification and validation tests (both in-house and in a simulated or actual user environment).

Clinical Evaluation

In order to demonstrate that software meets overall safety and performance requirements, clinical evaluation must be performed on an ongoing basis. For this purpose, a clinical evaluation plan should be prepared. Annex XIV (part a) of the MDR specifies the minimum requirements for a clinical evaluation plan.

Clinical evaluation is the systematic and planned process of continuously generating, collecting, analysing, and reviewing clinical data to verify the safety and performance of the software, including clinical benefits, when the software is used as intended by the manufacturer. In other words, there is an obligation to substantiate on an ongoing basis – throughout the life cycle of the medical device – the operation and safety of the software and its compliance with safety and performance requirements with results from clinical research. Part of the clinical evaluation is the clinical data collected in the context of the also mandatory post-market surveillance and post-market clinical follow-up. This obligation goes (much) further than under the old rules, which “only” required the manufacturer to record reported incidents.

UDI and Eudamed

The MDR further mandates the affixing of a Unique Device Identification (“UDI“) code to medical devices, with the goal of better identifying and tracking medical devices. The UDI system is described in Annex VI, Part C of the MDR. It follows from this Annex, for example, that the UDI is assigned at the system level of the software and only for stand-alone software.

When the UDI must be applied to the medical device at the latest depends on the risk class:

• Risk class III: May 26, 2021
• Risk class IIa and IIb: May 26, 2023
• Risk class I: May 26, 2025.

An UDI database is also being set up, which will be part of the new European database on medical devices (‘Eudamed’). Based on the UDI code, medical devices will be searchable in Eudamed. Manufacturers will in future be required to include in Eudamed, among other things, the results of clinical trials and clinical evaluations.

It will be mandatory for distributors of software and users (like health care institutions) to check if software is included in Eudamed and has a CE mark. If the device is not included in Eudamed, it may not be used.

Eudamed is currently under development and is expected to go live in 2022.

Conclusion

The obligations for manufacturers are more numerous and far-reaching under the MDR than under the old regulations. For example, in this blog we discussed the manufacturer’s obligation to:

• ensure adequate financial coverage for liability if the medical device is found to be defective;
• set up a quality management system;
• draw up an EU declaration of conformity and apply a CE conformity marking;
• ensure that the software meets general safety and performance requirements;
• prepare technical documentation;
• perform clinical evaluation based on a clinical evaluation plan; and
• apply and register a UDI in Eudamed.

For software developers who are currently developing medical software, it is important to consider the obligations in the MDR already in the design process. Manufacturers of medical devices that complied with the old rules must take action to ensure that their medical device also complies with the new rules. As of when this must be done, we will discuss this in the third blog (transitional rules). In addition, all medical device manufacturers are now required to continuously monitor and control the safety and quality of the software throughout its life cycle (see the post-market obligations section in the third blog).

Want to know more?

Would you like to know more about the MDR, or advice on what the MDR specifically means for you or your organization? Please contact Huub de Jong or Marijn Rooke