How to Create a Winning Usability Engineering File for FDA Submissions
There is a good chance that your medical device development team isn’t fully considering the needs of your clients when making key design decisions. While all the obvious information may be neatly organized in a product requirements document supporting your FDA submission, there’s more to it than that.
The team needs to understand how and why its requirements were chosen, and this presupposes prior thorough analysis of all the details that contribute to the experience a person is going to have with your product.
Organizing your usability design efforts is challenging. It makes sense that clients frequently ask us for tips.
Sometimes we uncover a need for a central repository for all usability design information and files. One client, for instance, had important reports in multiple, difficult-to-access locations.
We also encountered a client who, despite their efforts, fell short when it came to ascertaining user needs. And it was too late in the device development process to stop some unfortunate consequences from that lapse.
Both companies had protocols in place, as does yours. Unfortunately, their development teams didn’t know about them or consider them within the context of a perfunctory checking of FDA regulatory boxes. Fortunately, a well-organized Usability Engineering File can inform your entire design process and save you from these pitfalls.
Understanding Your Usability Engineering File
The FDA-required Usability Engineering File contains all of the use-case, user needs, and user testing data for your medical product development project. Actually it isn’t a “file” at all, which leads to misunderstandings. The Usability Engineering File is a table of contents that points to all the usability information and process evidence required for your project.
The human factors group at a company should be responsible for the Usability Engineering File, including all contents. Unfortunately most medical device companies, especially start-ups, don’t have a dedicated in-house human factors team. The responsibility usually defaults to the person in charge of FDA regulatory compliance. Once that happens, there’s only a slight chance that your design team will reference it during early development.
Tips for Effectively Reviewing the Usability Engineering File’s Sections
Consider reviewing section 5 of the standard IEC 62366-1, Application of Usability Engineering to Medical Devices. It explains the nine sections of your Usability Engineering File.
Here are some tips for each:
1. Prepare use specification
The use specification document is a required part of your medical device’s FDA submission packet. This document states how your product will be used, by whom, and under what conditions. As you prepare it, you’ll elaborate on your product’s intended use environment, patient population, medical indication, and more.
The use specification document sets the tone for the product you ultimately develop. In order to tailor your product to meet your users’ needs, you must construct a thoughtful and comprehensive use specification document.
2. Identify user interface characteristics related to safety and potential use errors
You are designing a medical device to be used by specific people in a specific way. It’s your obligation to make sure it can be used safely by identifying potential use errors before they happen. A task analysis of the use scenarios is a great way to flesh them out.
3. Identify known or foreseeable hazards and hazardous situations
Once the potential use errors are identified, you need to describe the effects they might have and how they might harm someone. Team brainstorming on how someone might misuse or be injured by your device can actually lead to new breakthroughs to help make your device even safer.
4. Identify and describe hazard-related scenarios
Combining the intended use scenarios with the potential errors you identified will result in potential hazard-related scenarios. Learning what’s likely to go wrong will allow your design team to design around such hazards.
5. Select hazard-related scenarios for summative testing
You can test all or just some of the hazard-related scenarios during summative testing. It depends on how much risk your company is willing to assume.
A common mistake is selecting scenarios too late in the design process to be useful to your development team. It’s an easy mistake to make because summative testing doesn’t happen until development is about 90% complete.
We recommend identifying hazard-related scenarios on day one of your project. Make sure they are in plain sight so your design team can eliminate them early.
6. Establish a user interface specification
A user interface specification contains all the user interface requirements and all the ways in which people will interact with your device. It builds off the previous three sections we just discussed. One tip is to make the requirements as specific and measurable as you can because they will need to be tested.
7. Establish a user interface evaluation plan
Formative and summative user interface evaluations should be included in your master project schedule on day one. In our experience, they’re usually missing or sufficient time and resources are not allocated.
Knowing early on what will be evaluated over the course of a project will allow your design team to plan their tasks better.
For example, many interface evaluations require some type of prototype to be provided by the technical team. The time and resources required to make one or possibly more prototypes needs to be planned well in advance.
8. Formative evaluation
User evaluations of your team’s assumptions, concepts, and prototypes should be performed early and often. They are the holy grail of user feedback and promote intimate collaboration between your design team and users. When conducted properly, they will give your development team the feedback needed to deliver a great user experience.
9. Summative testing
Remember the hazard-related scenarios identified in step five above? The purpose of summative testing is to make sure a person can operate your device safely in those specific scenarios. The FDA expects you to test about 15 primary users under very specific conditions. Keep in mind that if both doctors and nurses are considered primary users, you’ll need to conduct testing with 30 people (15 doctors + 15 nurses).
Capitalize on Your Usability Engineering File to Guide Your Design Process
Your Usability Engineering File is the best way to organize your human factors design effort. You already have to do it, but following the advice laid out above will make it more effective.
Make sure an expert in human factors takes ownership of the device at the beginning of the development process. Waiting for your regulatory team to address it is too late. Consider your Usability Engineering File a tool to be used and referenced throughout your product design and development process.
If you’re like most medical device companies, your team is heavily staffed with technically minded engineers, right? You probably don’t have a full-time expert in human factors at your disposal.
We can help. Contact us to discuss your user needs challenges and learn more about how we can help deliver a great user experience for your customers.