The new Medical Device Regulations (2017/745/EU) (MDR), published in May 2017, will replace the existing Medical Devices Directive (93/42/EEC) (MDD) and the Active Implantable Medical Devices Directive (90/385/EEC) (AIMDD). The new rules will apply after a transitional period, which will come to its end on 26th May, 2020. From that date on the new MDR will apply fully.

Due to the changes in the medical device legislation in the EU, there’s a lot of things you need to know as a medical device manufacturer. That’s why we’ve started a blog post series earlier, where we discuss about the new MDR and its effects. This is the next one, and it discusses shortly about the software as a medical device (SaMD).

The background

The new MDR brings some changes also in the medical device software classification, as the new MDR has implemented a new classification rule for software that must be considered when applying the definition to general medical devices. This means that most software as a medical device (SaMD) will be up-classified as Class II medical device in the new Medical Device Regulation (EU) 2017/745 in Europe. Earlier, most of the medical device software was classified into Class I in Medical Device Directive and in IVD directive.

This means that a valid CE-Mark Certificate issued by a Notified Body must be in place at latest in 26th May 2020. Additionally, you should also have a quality management system and a post-market surveillance system in place which should be proportionate to the risk class and the type of the device in question. In addition, in order to minimize risks or prevent incidents related to devices, manufacturers should establish a system for risk management and a system for reporting of incidents and field safety corrective actions.

But how to get started with all this? Here are our tips on how to proceed!

Tip #1. Define the intended use for your software and find out if your software is a medical device under the new MDR

In the new regulation also a definition of a medical device has been a little bit changed.  The new regulation says:

"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. The following products shall also be deemed to be medical devices:

— devices for the control or support of conception;

— products specifically intended for the cleaning, disinfection or sterilisation of devices as referred to in Article 1(4) and of those referred to in the first paragraph of this point."

Now it seems that more software products are deemed as medical devices as earlier, for example because ‘prognosis’ is a new word in the definition of a medical device.

MEDDEV 2.1/6 (July 2016) gives also some practical information how to decide if the software is a medical device (qualification). However, it should not be used in risk classification any more, instead the rule 11 of the Regulation should be used.

Thus, the rule number one is to define the intended use for your software and find out if your software a medical device according to the new MDR. Be specific with the definition of the intended use so that you will not unintentionally define e.g. your wellness software to a medical device.

If you find out that your software is a SaMD, you have to first understand that it shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance.

You can find our general tips relating to regulatory requirements for designing medical devices from here.

Tip #2. Find out what is the classification of your software

There are 5 different risk-based classes for medical devices: Class I, Class I sterile, Class I with measurement function, Class IIa, Class IIb and Class III. As already said earlier, in future, due to the new MDR, most of the medical device software are up-classified into Class IIa under the MDR. That’s why it’s really important to check out in which classification your software will fall in according to the new regulation.

Annex VIII of the MDR says (in Section 6.3. Rule 11) the following:

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

• death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or
• a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I.”

Consequently, it seems that there will be hardly any stand-alone software left being classified as Class I any more. Entries tool is, for example, a helpful tool for classification of a medical device.

Even if you have a Class I SaMD, you must comply with the Regulation. Manufacturers of class I devices shall declare the conformity of their products by issuing the EU declaration of conformity referred to in Article 19 after drawing up the technical documentation set out in Annexes II and III. The quality management system is required for Class I manufacturers as well.  

When you have higher than class I SaMD there are different conformity assessment procedures that you can choose and find from Article 52 of the regulation. Then you need a ‘notified body’, a conformity assessment body designated in accordance with this Regulation, before you can place your SaMD on the market.

The Notified Body will e.g.

• assess your quality management system and the technical documentation
• review the manufacturer's procedures and documentation relating to clinical evaluation
• address the interface between the manufacturer's risk management process and its appraisal, and analysis of the pre-clinical and clinical evaluation and to evaluate their relevance for the demonstration of conformity with the relevant requirements in Annex I
• carry out appropriate surveillance audits and assessments
• carry out or request certain tests to verify the proper functioning of the quality management system
• perform unannounced on site audits
• etc...

Remember that ‘placing on the market’ means making available of a device, other than an investigational device, on the Union market.

Tip #3. Study the Regulation

There’s a lot of things you need to know as a medical device manufacturer. This is why we encourage you to study the whole regulation carefully. We collected here some pickups from the regulation where you can start from.

FIRST: Establish an appropriate quality management system.

The first one is that you should establish an appropriate QMS including a process for the software life cycle. The regulation says that “the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.”

The software life cycle process defined in IEC/EN 62304 Medical device software - Software life cycle processes is a good process to be followed. Study the standard, check if your software life cycle process meets the requirements of the standard and update the process accordingly. If you are outsourcing software design process, be sure that the subcontractor complies with this standard and has relevant needed procedures, such as risk management process, integrated to the software life cycle process.

SECOND: Create a robust risk management process.

The new MDR requires that manufacturers must establish a system for risk management. The risk management actions must cover the whole life cycle of a medical device and must be regularly updated. Don’t forget to remove or reduce as far as possible the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts.
The notified body will verify the adequacy of the risk management process and e.g. address the interface between the manufacturer's risk management process and its appraisal and analysis of the pre-clinical and clinical evaluation and to evaluate their relevance for the demonstration of conformity with the relevant requirements in the regulation. See more from the Annex I of the regulation.

THIRD: Create a process for the clinical evaluation for medical device software.

‘Clinical evaluation’ means a systematic and planned process to continuously generate, collect, analyse and assess the clinical data pertaining to a device in order to verify the safety and performance, including clinical benefits, of the device when used as intended by the manufacturer. And yes, software as a medical device must also be validated to prove that it works as intended. Start this process early enough as this validation is to establish that there is a valid clinical association between the output of a SaMD and the targeted clinical condition, and that the SaMD provides the expected technical and clinical data.

The risk management and clinical evaluation processes should be interdependent and should both be regularly updated. See more about clinical evaluation of software from here.

FOURTH: Pay attention on the technical documentation

Draw up and keep up to date the technical documentation for your SaMD. The technical documentation shall be such as to allow the conformity of the device with the requirements of the Regulation to be assessed. The technical documentation shall include the elements set out in Annexes II and III. The notified body will assess the technical documentation before the SaMD can be placed on the market.

FIFTH: Create a post-market surveillance system and a plan

In order to minimize risks or prevent incidents related to devices you should create a post-market surveillance system.  Your post-market surveillance system must be proportionate to the risk class and the type of the device in question. Read the requirements for the post-market surveillance system from the Article 83 Post-market surveillance system of the manufacturer’ of the Regulation. 

SIXTH: Take UDI requirements into account

In addition to taking the UDI requirements into account, remember to comply it with the obligations relating to the UDI system referred to in Article 27 and with the registration obligations referred to in Articles 29 and 31.

SEVENTH: Assign a person responsible for regulatory compliance.

Medical device manufacturers shall have available within their organisation at least one person responsible for regulatory compliance who possesses the requisite expertise in the field of medical devices. The person responsible for regulatory compliance shall at least be responsible for ensuring that:

• the conformity of the devices is appropriately checked, in accordance with the quality management system under which the devices are manufactured, before a device is released;
• the technical documentation and the EU declaration of conformity are drawn up and kept up-to-date
• the post-market surveillance obligations are complied with in accordance with Article 10(10)
• the reporting obligations referred to in Articles 87 to 91 are fulfilled
• in the case of investigational devices, the statement referred to in Section 4.1 of Chapter II of Annex XV is issued.

Read more about the person responsible for regulatory compliance from the Article 15 of the regulation.

Conclusion

As stated earlier, the new MDR brings changes also in medical device software development, and there’s a lot you need to know and follow as a medical device manufacturer. We hope that our tips help you to get started.

You should also remember that the qualification of software, either as a device or as an accessory, is independent of the software's location or the type of interconnection between the software and a device. So, you may have your software location outside Europe and still need to fulfill the requirements of this regulation if software is used in Europe.

We suggest you study the new MDR and its effect on your software as a medical device carefully. Alternatively, you can partner with some professional in the field that can help you to proceed with all the actions related to the new MDR; e.g., who has the needed processes in place including the documentation which fulfills the requirements of the regulation – by which the software safety and performance are demonstrated.

Sources used, and more information about the topic:

• Regulation and other information from EU 
• EU Guidance
• IMDRF guidance related to Software as a Medical Device

This was our short discussion on how to ensure that your product and it’s software are compliant with the new regulation. In the future posts we will introduce more our thoughts on how to prepare for the coming MDR. So stay tuned!

Meanwhile, you can get yourself familiarized with that how to ensure the quality compliance during the whole life cycle of the medical device in practice. You can download our White Paper including insights related to that. It shows an illustrated outline of the stages in developing your idea into a worldwide selling product in the medtech/healthtech sector. These phases demonstrate how to ensure compliance to enable medical devices to be placed on the market as smoothly as possible. Please download your free white paper below!