What you need to know about the new Medical Device Regulation (MDR)

As of 26 May 2021, the 2017/745 MDR officially superseded the 93/42/EC Medical Device Directive (MDD) that came into effect in 1993 and is now a European Union central law. According to the Official Journal of the European Union, this regulation sets high standards of quality and safety for medical devices in order to meet common safety concerns.

We must point out here that this regulation covers two elements to a medical device being manufactured and distributed within the EU: the manufacturing of a device and the associated software of a device. For the purpose of this article, we will focus on Medical Device Software (MDSW).

There are two reasons behind the MDR being brought in.

1. The pre-existing Directives did not keep pace with innovations in technology and medical research science.
2. Historical crises including the breast implant and hip replacement scandals over the last few years have required greater regulation of the market, with patient safety at its core.

The purpose of this new regulation is to provide transparency of all information for medical devices and associated software, with the MDR placing great importance and focus on “clinical evaluation reports which provide an overview of the device’s design, intended applications and any revisions made to its documentation.”

Henceforth, all devices produced in, or supplied to the EU must now meet these strict safety and quality standards. It is also likely that existing medical devices may need to gain re-certification.

What is classified as Medical Device Software?

Under the MDR, certain software is now considered as Medical Device Software (MDSW) and as such, all design documentation relating to this software must meet regulatory requirements and be archived in the appropriate manner to achieve EU compliance.

Regardless of whether the software is independent, driving or influencing the use of a device, it must have a medical purpose on its own to qualify as a MDSW. A good place to start would be to consider the below questions to help determine if your software falls within this aspect.

• Is the software an accessory for a medical device?
• Does it benefit the individual user?
• Is the software a MDSW according to the definition of MDCG 2019 11?
• Does the software perform an action on data different from storage, archival, communication or search?

According to an article in Med-tech News, examples of what software types are qualified as MDSW include:

• It directly controls a medical device.
• It provides immediate decision-triggering information (e.g. blood glucose meter software).
• It provides support for healthcare professionals (e.g. ECG interpretation software).
• Is intended to process, analyse, create, or modify medical information when the software is governed by a medical intended purpose.

Who does this impact and what data must be retained?

Manufacturers, clinical trial sponsors, investigators and other regulated parties involved in medical device development, manufacture and distribution in the EU must act now.

Similar to an eTMF (critical clinical trial documentation) which must be retained for 25 years, all design documentation relating to the software must be retained for 10 years, with any further releases also held for 10 years. So, say your organisation releases version in 2021, the design documentation must be held until 2031. But if you release updated version 1.2 in 2022, then this documentation will have to be retained until 2032 on top of the documents being retained from version 1.

Sponsors of clinical trials for medical devices must retain documentation, including application forms, investigators’ brochures and performance study plans, for 10 years after the device’s clinical investigation has ended.

Technical documentation in software engineering encompasses all written documents and materials dealing with software product development. Documentation exists to explain product functionality, unify project-related information, and allow for discussing all significant questions arising between stakeholders and developers.

Software documentation can be divided into two main categories:

• Product documentation: describes the product that is being developed and provides instructions on how to perform various tasks with it.
• Process documentation: all documents produced during development and maintenance that describe the process.

Retaining data is more than uploading a file to the cloud

We cannot underestimate the difficulty in managing and protecting data throughout this retention period. When stored for anything more than a couple of years, data is at serious risk of degrading, becoming corrupted or lost. It is a common misconception that backing up data or storing it in a cloud environment such as AWS, GCP or Azure will ensure that it is safe, accessible and readable for as long as it is stored there.

Yet, these approaches do not provide any capability to mitigate against:

• Data loss
• Data corruption
• Software applications and operating systems becoming obsolete
• Hardware failure.

It is not possible to actively manage and provide secure and auditable access to your data in these backup and cloud systems.

The archive must be accessible and consistent throughout the retention period. It’s therefore essential that the correct processes and tools are in place to overcome any obstacles or unforeseen challenges which may arise, such as organisational changes or staff churn. Understanding the implications of successful retention upon your organisation and personnel will help you in deciding whether you should build this responsibility in-house or outsource to a third party.

What are the risks?

Accountability gaps and non-compliance may result in:

• Loss of EU market access
• Loss of contract
• Reputational damage
• Hinder sales and impact market share
• Penalties

Planning for the MDR

It is important for relevant organisations to prepare and react to these changes.

Quality of device software documentation will be crucial in meeting the standards set by the EU…it can be easy to miss uploading a document within your repository due to the sheer volume of documentation required to get a device or application to market.

With the regulation now in full effect, organisations that are covered under MDSW must endeavour to expand their understanding of these new requirements, and sequentially develop or outsource their document retention strategy in a manner which will enable them to continue marketing the device.

The EMA are currently working on updating guidance on quality requirements for medical devices and an updated Q&A.

For further advice, or to talk to one of our team members today get in touch with us.