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

On May 26, 2021, the Medical Devices 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 list 12 key points of consideration.

Structure of the blog series

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

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

In this third and final blog in the series, 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 transition provisions.

Post-market obligations

The MDR requires manufacturers to have a system for post-market surveillance once the medical device is placed on the market. This system must be tailored to the risk class to which the medical device belongs and is part of the mandatory quality management system. Annex III of the MDR elaborates on what requirements the system must meet at least.

The underlying idea of post-market surveillance is that by systematically and actively collecting information about experiences with their medical device, manufacturers gain insight into the quality, performance and safety of the device. One way to gather such information is through a feedback and complaints procedure that is easily accessible to the patient and user (think of a contact form on the website and in the software).

If, based on collected data, it appears that the software is not functioning as it should, corrective and/or preventive measures can be taken to prevent undesirable effects on patient safety and health. Such measures may include withdrawal of the software from the market (if there is an immediate danger that cannot be eliminated by other means), modification of the design of the software (technical modifications, for example, by adding or removing functionalities) and/or modification of the instructions for use (for example, by giving (more) specific instructions for use). The information should also help the manufacturer to determine opportunities to improve the usability, performance and safety of the software. The information collected can also be used to keep the technical documentation up-to-date, inter alia, with respect to risk assessments and clinical evaluations. It should also provide a clear overview of preventive and/or corrective measures undertaken. The idea is that this will promote transparency and make it easier to monitor compliance with the MDR.

In addition to drawing up a plan for post-market surveillance, manufacturers are also required to draw up a report on the activities that take place as part of implementing the plan. If software falls into risk class I, then despite the fact that the preparation of a report on post-market surveillance is mandatory, it ‘only’ has to be made available to the regulator upon request. If the software falls under risk class IIa, IIb or III, the manufacturer must draw up a so-called periodic safety update report (‘PSUR’). For software in risk class IIb or III this must be done annually, and for software in risk class IIa at least every two years. The PSUR with regard to software in risk class III must be actively disclosed to the notified body via Eudamed. The PSUR on software in risk class IIa and IIb must be made available at the request of a notified body or the regulator.

Further, part of the post-market obligations is the so-called post-market clinical follow-up (“PMCF“). The PMCF is the ongoing process of updating the clinical evaluation of the software. The PMCF should be part of the post-market surveillance plan. Appendix XIV part b to the MDR specifies which requirements the PMCF must meet, at a minimum.

In summary, it is mandatory for manufacturers to:

  • Establish a system of post-market surveillance;
  • Prepare a report on post-market surveillance activities for software in risk class I;
  • Prepare a periodic safety report (PSUR) for software in risk classes IIa, IIb, and III; and
  • Keeping the clinical evaluation up-to-date through PMCF.

Vigilance

As part of the mandatory quality management system manufacturers must have a procedure for reporting serious incidents and field safety corrective actions. The notifications of serious incidents and field safety corrective actions must be recorded internally and have to be made available in Eudamed. Through Eudamed the competent authority of the Member State where the incident has occurred c.q. where the corrective action will be taken, will be informed. Since Eudamed is not yet in use (mid 2021), for the moment reporting to the competent authority is required. In the Netherlands, the competent authority is the Healthcare and Youth Inspectorate (in Dutch: Inspectie Gezondheidszorg en Jeugd (“IGJ“)), which supervises manufacturers of medical devices (such as software) partly on the basis of vigilance reports. The IGJ has specific information on its website about reporting serious incidents and remedial actions, the applicable deadlines and the actions that the IGJ can take. The IGJ is authorized to impose an administrative fine of € 870,000.- or a maximum of 10% of the company’s turnover in the financial year preceding the decision, whichever is higher, for failure to comply with the rules on reporting serious incidents.

But what is a serious incident within the meaning of the MDR? A serious incident is an incident that directly or indirectly resulted, could have resulted, or may result in:

  • death of the patient, a user of the medical device, or another person;
  • temporary or permanent serious deterioration in the health condition of the patient, a user of the medical device, or another person; or
  • a serious threat to public health.

If a report of a serious incident is made to the manufacturer, the manufacturer must conduct an investigation into the incident. The manufacturer of a medical device is then required to make a report through Eudamed immediately after a causal relationship is established between a serious incident and the use of the medical device, and no later than 15 days after the manufacturer becomes aware of the serious incident. Sometimes the deadlines for making a report in Eudamed are even shorter, such as in the case of a serious threat to public health (no later than 2 days) or in the case of the death of a patient or an unexpected serious deterioration in the patient’s health condition (no later than 10 days). If the manufacturer is still investigating a causal relationship between an incident and use of the medical device, it may be required to make a report anyway. This may initially be an incomplete report, which will be completed later.

If a serious incident has occurred, a field safety corrective action must often be taken to prevent further incidents. The mandatory investigation usually shows which corrective action is required. The purpose of the field safety corrective action is then to prevent or reduce the risk of a serious incident related to a device made available on the market.

The manufacturer must report in Eudamed which corrective actions will be taken before actually taking those actions, unless this is not possible in view of the urgency of the incident to which the action follows. Subsequently, the manufacturer must inform the users of the medical device of the serious incident and the corrective actions taken by means of a so-called “Field safety notice“. Again, only after reporting in Eudamed and in consultation with the IGJ, unless the urgency requires immediate action and information.

Person responsible for compliance with laws and regulations

New under the MDR is the mandatory appointment of a person responsible for compliance with the MDR, known as the Person Responsible for Regulatory Compliance (“PRRC“). The PRRC must meet a number of quality requirements, has various responsibilities and is protected by law in the performance of its function. This obligation does not apply to micro and small companies (companies with up to 50 employees and an annual turnover or annual balance sheet total of up to €10,000,000), although these companies must have access to such a person at all times.

As mentioned, the PRRC must have the necessary expertise in the field of medical devices. The ability to demonstrate that expertise is also mandatory. For example, through a diploma, certificate or other evidence of formal qualification on completion of a university (or equivalent) degree program in medicine, pharmacy, technology, law or other relevant scientific discipline. In addition, the PRRC must have at least one year of professional experience in the field of medical device regulation or quality management systems. In the absence of a university background, at least four years of professional experience in the field of medical device regulation or quality management systems is also sufficient.

The PRRC’s responsibilities include:

  • Verifying the conformity of a medical device in accordance with the manufacturer’s quality management system before it is placed on the market;
  • Preparing and updating the technical documentation and EU Declaration of Conformity;
  • fulfilling post-market obligations; and
  • fulfilling the obligations of reporting on serious incidents and field safety corrective actions.

Where there are multiple individuals jointly responsible for MDR compliance within a manufacturer, it is mandatory to document in writing the individual areas of responsibility and the individuals responsible for them.

In order to ensure that the PRRC can actually perform her or his job, it is stipulated that the PRRC must not suffer any disadvantage in the manufacturer’s organization with respect to the proper performance of her or his duties. In this regard, it does not matter whether the PRRC is an employee of the manufacturer or not.

Transitional Provisions

The rules of the MDR are more numerous and far-reaching than the old rules. For manufacturers of medical devices that were already placed on the market before May 26, 2021 (the date on which the MDR became applicable), a number of transitional arrangements apply. The transitional arrangements are quite complex and (as a result) do not excel in clarity. We discuss below the most important transitional provisions for software manufacturers.

For software that fell into risk class I under the old rules and falls into risk class IIa or higher under the MDR (due to the stricter definition of medical devices), the rules of the MDR do not have to be complied with until May 26, 2024. The only condition is that an EU declaration of conformity was already drawn up before May 26, 2021 (by means of self-certification).

For software that had already been assessed by a notified body before May 26, 2021 (software that fell into risk class IIa and above under the old rules), the certificate issued by the notified body remains valid till no later than May 26, 2024. With regard to the validity of the issued certificates, the following applies:

  • If the certificate was issued before May 25, 2017, the original period of validity remains in effect (unless there was an EC inspection, in which case the certificate loses validity no later than May 27, 2022); and
  • If the certificate was issued after May 25, 2017, the certificate will remain valid for up to five years after issuance and no later than May 27, 2024.

In all situations:

  • the software must continue to comply with the old rules regarding medical devices;
  • no significant changes should be made to the design and intended purpose; and
  • the requirements of the MDR in terms of post-market obligations, vigilance and the required UDI and registration in Eudamed must be met.

Software that feel in risk class I under the old rules and remains in risk class I under the MDR is not subject to a transition rule. This software must therefore comply with the rules in the MDR as of May 26, 2021.

In conclusion

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

  • Implement a post-market surveillance system (including mandatory reporting);
  • Keeping the clinical evaluation up-to-date through PMCF;
  • Implement as part of the mandatory quality management system a procedure for reporting serious incidents and field safety corrective actions; and
  • Appoint or have access to an internal or external Person Responsible for Regulatory Compliance.

With this third and final part of the three-part in-depth blog series on the MDR, we have discussed 12 key points of consideration for developers of medical software and apps. With this blog series, we have tried to provide guidance in answering some of the crucial questions that we believe medical software and app developers should always ask themselves:

  • Is the software or app I developed a medical device?

And if the answer to the first question is yes:

  • What risk class does the software or app fall into?
  • What rules do I need to comply with before bringing the software or app to market?
  • What rules do I need to comply with after I bring the software or app to market?
  • From what date do I have to comply with the rules in the MDR?

If you have clear answers to these questions for yourself, you will be able to bring your compliancy in order. So that you can then (continue to) market your software or app with peace of mind.

Want to know more?

Would you like to know more about the MDR, or advice on what the MDR means for you or your organization? Please contact Ernst-Jan Louwers.