Most common mistakes leading to MDR certification delays

You are about to finish your medical software. The only thing separating you from marketing your product is going through conformity assessment as required by Medical Device Regulation. Yet, you get stuck in this process. What happened? Why does it take so long? Let’s get into the most common mistakes resulting in MDR certification delays.

TL;DR

When developing medical software according to Medical Device Regulation, you must undergo a conformity assessment. If the risk class of your product is IIa, IIb, or III, this process will include a notified body – which can extend the overall timeline.

Yet, some manufacturers fall into the trap of overlooking compliance. They often make avoidable mistakes, such as not defining intended use, misclassifying the product, disregarding traceability, ignoring risk analysis, lacking collaboration between software developers and regulatory affairs specialists, and rushing to meet deadlines.

Top mistakes that cause MDR certification delays

Medical Device Regulation (MDR) regulates the marketing of medical devices, including medical software, within the European Union. If you want to introduce your breakthrough app to European citizens, you must meet the requirements set by this regulation.

How does this process work? Once you’ve developed a medical software, carried out clinical investigation, where necessary, and completed the crucial documentation (including QMS according to ISO 13485), you must undergo a conformity assessment. If the risk class of your product is IIa, IIb, or III, this process will need to include a notified body – meaning additional time before marketing your product.

The process of developing safe medical software requires a lot of resources – knowledge, experience, money, and time. The last thing anybody wants is to make this process even longer and tiresome.

Yet, working with medical software ourselves, we notice that some companies make mistakes that translate into a longer development process and increased costs. These mistakes are usually due to either a lack of knowledge or a rush. What are they?

1. Not considering compliance from the beginning

One of the most common mistakes we notice is that companies do not consider compliance from the beginning of the development process. Some manufacturers build medical software first and then think about regulatory requirements later. Also, it happens that some companies build their solution as a typical software, to later on find out that their product fits the definition of medical device.

Unfortunately, in both cases, they will have to do much rework, resulting in MDR certification delays and costs increasing.

2. Lack of defined intended use causing classification issues

There are four classes of medical devices regulated by MDR – I, IIa, IIb, and III. They come with their requirements, tasks, and demands described in our article on that topic. Unfortunately, sometimes companies aren’t aware of which class their product belongs to or for which class they would like to aim.

Let’s imagine the following situation – a company has prepared a document stating the intended use of their medical software, which fits into the III class. However, they are unaware that the class III product certification is more costly than they anticipated.

The solution is to prepare the intended use and classification of the medical software carefully. It’s crucial to understand how it will influence the classification and further requirements you must meet. Discussing intended use with regulatory affairs specialists familiar with developing medical software under MDR would be helpful. Sometimes, small changes in the product design or intended use can lead to lowering or raising the class.

3. Disregarding traceability

MDR and IEC 62304 are compatible – both impose traceability requirements on medical device software manufacturers.

Meaning that a manufacturer should document every step taken during the development process (and, of course, later during maintenance). Although companies specialised in developing medical software know how to maintain top-notch documentation, which could be part of the technical documentation in accordance with Annex II of the MDR, some manufacturers might not be aware of its importance.

Yet, notified bodies expect a well-documented process, so if a company catches up at the last minute, it can add months to the time required to pass the audit positively and obtain the conformity assessment.

4. Ignoring the risk analysis

Risk analysis (as demanded in ISO 14971) is a crucial aspect of developing medical software, as potential misuse might result in the decline of health or, in some cases, even the death of the patient.

Yet, sometimes, companies either aren’t aware of the importance of risk analysis or are unsure how to prepare a thorough one. Some companies might be focused on documenting existing risks, instead of actively assessing risks throughout the product development process.

Introducing risk analyses from the very beginning helps prevent errors and ensures that all potential risks are addressed before they become critical. Thus, it is essential to have a good moderator of the risk analysis meeting who knows what questions to ask, how to motivate the group, and how to make this process as pleasant as possible.

5. Lack of collaboration between teams

We are well aware of the fact that regulatory affairs specialists and software developers think, work, and use language differently. These two groups often seem to be in constant competition, each focusing on their own priorities and challenges, which can create friction and misunderstandings.

Regulatory specialists are focused on meeting demands set by MDR and other relevant standards. On the other hand, software developers are used to using Agile methodologies, which provide them with greater flexibility and autonomy in their work.

So, if those two teams aren’t aligned from the start and don’t know how to work together on a common goal, compliance becomes tiresome for both parties.

6. Rushing to meet deadline

The last problem is the rush to meet deadlines at the expense of neglecting the processes of preparing medical software for conformity assessment. Some companies focus so strongly on getting the final product ready as quickly as possible that they overlook important documentation and regulatory elements.

Ironically, rushing can actually lead to delays in the finalisation of the conformity assessment and, ultimately, the ability to legally sell the product. If documentation is missing or incomplete, companies often have to invest more time and resources into correcting these issues, which can significantly extend the timeline. In some cases, missing documentation can even double the time it takes to reach the point of legal market access.

How to prevent MDR certification delays during development?

If you want to avoid these mistakes and ensure your MDR certification process is swift and seamless, you should check out our article 6 tips to avoid MDR certification. We share our tips and tricks from years of experience working with developing medical software.