Mehr Infos

How can you meet MDR requirements without usability engineering?

Author: Benjamin Franz

Reading time:

Dec 2022

You have an already developed medical device that was developed without usability engineering and would now like to know what options you have to still meet all the usability requirements of the Medical Device Regulation (MDR) (MDR)? That is the core question we would like to answer with this article.

In addition, you will learn what qualifies you for the various options and what they may look like.

 

Introduction: The goal is always a complete Usability Engineering File

The MDR requires you to comply with a number of points concerning the usability of your product. We have worked out the exact points in a separate article: In “Deep Dive: MDR” you will find all passages of the MDR that have to do with the usability of your product along with a “translation” of what the respective passage means for you. In summary, the MDR requires you to analyze and manage risks related to the use of a medical device. Most of these usability requirements are found in the “General safety and performance requirements” (Annex 1 of the MDR). The MDR provides you with the requirements, but does not dictate how you must implement them. However, in order to be able to argue convincingly before the Notified Bodies, you must prove that all requirements are met and that the intended users can use your product safely and in accordance with its intended purpose. What you need, therefore, is a Usability Engineering File that enables the intended users to use the product safely in accordance with its intended purpose. A Usability Engineering File is the collection of all documents that prove that your product meets the usability requirements. An article explaining the Usability Engineering File in depth will be published in the coming months. But how can you meet the MDR requirements without Usability Engineering? We have put together three options for you.  

Option 1: Your medical device can go through the User Interface of Unknown Provenance process of IEC 62366-1

What is the User Interface of Unknown Provenance process (in short “UOUP process”)? The process offers you the possibility to demonstrate conformity to IEC 62366-1, even if the medical device was developed without the usability engineering process included in the standard. It efficiently builds on existing documentation and data. The goal here is to generate a (compressed) Usability Engineering File. In addition, your risk management file is to be supplemented in such a way that it names all risks that can be traced back to the usability of the product.

But are you authorized to use the UOUP process? The basic requirements that must be met are as follows:

  • Your product was developed and approved before the introduction of the standard in 2015
  • The process requires PMS data from your medical device! (These are examined to determine whether they indicate usability problems).
  • Der Prozess setzt PMS-Daten Ihres Medizinprodukts voraus! (Diese werden dahingehend betrachtet, ob sie auf Usability-Probleme schließen lassen.)

The following must be considered: If parts of the user interface are subject to change or affected by new or changed components, the parts subject to change lose the “unknown provenance” status and must go through the full usability engineering process. More detailed information is provided in our article “When are you enabled to use the UOUP process?“.

Is your medical device qualified for the UOUP process? In our “Deep Dive: User Interface of Unknown Provenance“ article you will find all important information about the process and a complete sequence of the individual steps.

 

Option 2: You can argue with post market surveillance data and create a rationale

If your product is not qualified for the UOUP process, you have another option to “shortcut” a bit when it comes to proving whether or not you meet the usability requirements of the MDR. For this, you will also need Post Market Surveillance data.

How you do it? You create a rationale based on your PMS data. However, this only saves you the summative evaluation. A Usability Engineering File still needs to be compiled. Proper documentation is critical here. A deep dive article on PMS data analysis will be written by us soon.

What do you have to do? You examine the PMS data to see whether any conclusions can be drawn here about possible hazards or hazardous situations caused by the usability of the product. If this does not reveal any usability-related hazards, you can create your missing documentation based on the PMS data and thus bypass the summative usability evaluation by the rationale, if necessary. However, a summative usability evaluation provides you with a basis for argumentation that, as experience has shown, is much seldom contested. And for good reason: It is the most effective and safest method of proving the safety of use of a medical device.

 

Option 3: You can argue with summative usability evaluations or the PMS data of similar products

In this option, the procedure is very similar to that from option 2. You create a rationale based on PMS data here as well. In this case, however, from a similar product and not your own. If there is data from an existing summative usability evaluation of a similar product, you can also take this as a basis (instead of the PMS data or in addition to the PMS data). In both cases, this approach allows you to do without your own summative usability evaluation.

Again the following applies: You must still create a Usability Engineering File and ensure that the documentation is correct. A summative usability evaluation with your own product would also provide a stronger basis of argumentation when dealing with the Notified Body.

 

What do you need to do if none of the above options apply?

If none of the three options above apply, then you must create a complete usability engineering file and, at the end, prove the usability of your medical device with a final summative usability evaluation.

 

Implement MDR requirements pragmatically and efficiently in the future: The usability engineering process according to IEC 62366-1

As you can see, there is no way around a Usability Engineering file. The usability engineering process according to IEC 62366-1 has proven to be the most pragmatic and efficient way to fully comply with the MDR requirements for medical devices and to provide the correct documentation.

It is therefore recommended to integrate the usability engineering process into the development process right from the start. This will save you cumbersome work when subsequently creating the Usability Engineering File (or the correct documentation).

You want to know how the process works step by step? Then take a look at our article “Usability for medical devices according to IEC 62366-1“.

 

Conclusion

To prove that you meet all MDR requirements regarding usability, you need a complete Usability Engineering File.

Under certain circumstances, your product could use the abbreviated UOUP process of IEC 62366-1 for this purpose. If your product does not qualify for this, there is the possibility to argue on the basis of the Post Market Surveillance data of your (or a similar) medical device and to prove with an appropriate rationale that your product does not pose any unacceptable risks by its use. However, the latter may lead to unwanted discussions. A summative usability evaluation is often the safer way to go.

You want to know whether you can use one of the above options? We would be happy to talk through your specific case with you and to find out together whether your product qualifies for one of the options. In addition, we will be happy to help you pragmatically and efficiently in compiling the right documentation and creating a Usability Engineering File (or the Human Factors Report).

What is your specific case? Comment on this post or get in touch via our contact form. We look forward to hearing from you.

 

0 / 5 (0)

Subscribe for our newsletter

E-Mail *
This field is hidden when viewing the form
This field is for validation purposes and should be left unchanged.

Related Posts