11 HF Pitfalls That Trigger FDA AI Requests And How To Avoid Them

Human factors is one of the most common reasons FDA issues additional information (AI) requests following medical device submissions. FDA (CDRH) data suggests that less than 4% of human factors submissions to FDA are accepted without requests for additional information (AI), see Figure-1 [1]. That means there are an overwhelming majority of submissions that are resulting in AI requests, often due to preventable mistakes. AI requests can lead to costly delays that affect the bottom line of your business and deprive patients the benefits your device has to offer.

After 10 years in the medical device field as a human factors engineer, I’ve worked on many projects, I’ve seen FDA feedback up close and I know how much stress and chaos it can cause to internal teams, and I also know what FDA is looking for and how to deliver it. If your team wants an experienced HF professional to provide quick actionable feedback on the FDA-readiness of your HF Validation Protocol or HF file, you can reach out to me (jason@hfadvice.com).

11 issues with URRA and HF Validation

Below is a list of issues, reasons why FDA cares about them, and what you should do to avoid them. This is not a comprehensive list, but represents some of the most common issues FDA finds with HF submissions which I’ve found from my own experience, presentations from an FDA reviewer [1], and aggregation of HF practitioners experiences [2].

1.  No URRA completed

Why FDA needs this – without use-related risk analyses (URRA), FDA cannot tell if the manufacturer has identified and controlled use risk adequately, i.e. risks that occur as a result of users performing tasks differently than expected by the manufacturer. FDA explicitly calls for use-related risks to be uncovered in all of their guidance documents [3, 4, 5] and it is at the heart of the harmonized international standard 62366-1 [6] and it is also explicitly called out in 14971:2019 [7] as well.

Recommendation

• Always perform URRA. This applies to new product development, design modifications to marketed devices, devices and combination products, all regulatory classes, and any countries you intend to market in. The only exception is if your submission is for a design modification and there is no impact to user interface, users, intended use, use environments, training, or labeling.

• If you are deciding to what extent human factors processes should be completed for a design modification, have a trained human factors professional do an impact assessment. Very often engineers see a user interface as unchanged when a human factors professional or FDA reviewer would disagree. Additionally, many stakeholders do not consider the impact of changing an intended user group or use environment and how those factors may impact use safety.

• Include your URRA with your submission if you are going for 510k, PMA, De Novo and your URRA reveals any critical tasks (for new product development) or if changes result in new critical tasks or affect existing critical tasks (for changes to approved/cleared device) as outlined in the FDA Guidance on Human Factors Information for Marketing Submissions [3].

2.  URRA process unclear

If there’s no documented, structured approach to uncover potential use errors, how can a reviewer trust that you’ve uncovered all of them? If an FDA reviewer is looking through your risk documentation and cannot tell if you've considered all user groups (e.g. non-professional caregivers, medical assistants) or considered the complexities of how the real-world use environment may impact user-device interactions (e.g. noisy, distracting ICU makes it hard to notice or understand alarm meaning in critical situations) or if you've considered all use scenarios (e.g., installation, cleaning or reprocessing) then they will likely lose confidence that your HF process is robust and they are going to be more likely to ask for additional information. Keep in mind, FDA reviewers have likely seen similar products’ URRAs so they may already have expectation to see certain use errors in your documentation.

Recommendation

• Your HF/UE Report should summarize the activities you performed related to your human factors engineering process. See Section V of the Draft FDA Guidance on Content of Human Factors Information in Medical Device Marketing Submissions for details expected contents of HF/UE Report. A high-level overview of the recommended contents are below. Note: depending on your specific circumstances, you may only need to submit a subset of this. That determination is risk-based and should be done by a HF professional.

  
  

  • Section 1 - Conclusion and high-level summary

  • Section 2 - descriptions of intended device users, uses, use environments and training

  • Section 3 - Description of device-user interface

  • Section 4 - Summary of known use problems

  • Section 5 - Summary of preliminary analyses and evaluations

  • Section 6 - Analysis of hazards and risks associated with use of the device

  • Section 7 - Identification and description of critical tasks

  • Section 8 - Details of HF validation testing of final design

    
    

3.  Embedding URRA in broader product/design FMEA or risk management reports

Even if you have done a complete URRA, the formatting of your documentation may result in AI requests. FDA reviewers may struggle to find answers if you’ve lumped your use-related risk analyses in with other product/design/process risks, especially if they are not clearly identified. I've heard directly from FDA HF Reviewers that they do not like to search for information. This is a sure-fire way to frustrate a reviewer and possibly get a request for additional information for an easily preventable reason.

Recommendation

• Use a tabular format that contains a task description, potential use errors, harms, severities, risk controls, and validation methods because FDA prefers this for efficient review [1, 3]. See Figure-2 for an example of a URRA which does not include probability or overall risk index and clearly denotes critical tasks.

• Indicate which use errors are associated with critical tasks in the table as well, as suggested by the example in the URRA draft guidance from FDA [3].

Figure-2 Example URRA from the Appendix of FDA Draft Guidance, Purpose and Content of Use-Related Risk Analyses for Drugs, Biological Products, and Combination Products

4.  Non-specific risk control information

If risk controls are not specific enough, FDA reviewers will have a hard time determining if your human factors validation methods appropriately evaluated the effectiveness of the controls.

Recommendation

• Document planned validation methods simultaneously, and in the same tabular format so you consider how you’ll validate the effectiveness of the control long-before testing begins. See Figure-2 for example of expected specificity of risk controls.

• If you have doubts or questions, you can submit a Pre-Sub to FDA and you’ll receive feedback in 70 days, see Table-1 in Requests for feedback and meetings for medical device submissions: The Q‑Submission program [8] or if you have less time or don’t want to ask FDA, I can review and give actionable feedback in 1 week.

5.  No HF Validation Report

Why FDA expects this – human factors validation report is the documentation of a study dedicated to evaluating effectiveness of use-related risk controls. Without this, FDA has no evidence that controls listed in the URRA are effective.

Not all circumstances require HF validation. If your product has no critical tasks or if your changes do not impact critical tasks, it is possible you may be able to rationalize omitting HF validation. It is important to note, there are often changes that seem minor to non-HF professionals that may be viewed as impactful to critical tasks by FDA. For example, replacing textual information in a menu with iconography. FDA may ask for evidence that the device can still be used safely and effectively because of concerns that users may not interpret the icons meaning as intended.

Figure-3 Flowchart depicting risk-based approach to human factors engineering information for marketing submissions from Draft FDA Guidance on Content of Human Factors Information in Medical Device Marketing Submissions

Recommendation

• Include a human factors validation report in your submission if you are going for 510k, PMA, De Novo and your URRA reveals any critical tasks (for new product development) or if changes result in new critical tasks or affect existing critical tasks (for changes to approved/cleared device) as outlined in the FDA Guidance on Human Factors Information for Marketing Submissions [3].

• Make sure to include HF professionals in the decision-making process if you are considering skipping HF validation.

6.  Exclusion of key user groups or important user demographics from HF Validation

FDA expects representation of all users who are involved in meeting intended use in relation to use scenarios tied to critical tasks during human factors validation. They also expect inclusion of users whose have characteristics that may impact how they interact with the device, (e.g. hearing, literacy, etc.).

Note, that the FDA also expects users who participate in your human factors validation to be recruited from the US population. Increasingly, recruiting from geographically localized populations is becoming important to international regulation (China - NMPA's Guideline of Usability Engineering Review for Medical Devices, or Japan's Usability Engineering standard JIS T 62366-1:2022). This shouldn't be surprising to a human factors practitioner because of regional differences in workflow, language, or other cultural differences that impact how a user interacts with a user interface.

Figure-4 Excerpt from FDA Guidance on Applying Human Factors and Usability Engineering to Medical Devices Section 8 - Human Factors Validation Testing

Recommendation

• Check that you are not overlooking personnel include those responsible for field maintenance, reprocessing and cleaning, and procedure assistance (e.g. med techs and assistants).

• Do not include internal personnel as users unless they are actual users.

• Split up user groups that cover wide age ranges into multiple groups to ensure you’re gathering data from users with age-related limitations that would occur in real world use.

7.  Exclusion of critical tasks from HF Validation

FDA [4] and IEC 62366-1 [6] strongly suggest that probability of occurrence should not factor into decisions about which tasks are considered critical tasks. Too often, people have said, “that’ll never happen” and used that to justify not testing the effectiveness of listed controls. In reality, it’s very hard to say how likely something is to lead to harm in the real world and the FDA is trying to make sure it’s safe before it’s marketed.

Figure-5 Excerpt from 62366-1:2015 AMD1:2020 Subclause 5.5 highlighting reasons for using severity and not probability to derive critical tasks (hazard-related use scenarios).

Recommendation

• Include all critical tasks in your human factors validation. See Figure-4 for excerpt from FDA Guidance explaining why.

• Define your critical tasks by the severity of potential harm. Do not include probability of occurrence or overall risk in the decision. See Figure-2 for example of a URRA which does not include probability or overall risk index and clearly denotes critical tasks. See Figure-5 for excerpt from 62366-1 explaining why.

• When in doubt include more in your human factors validation rather than less. It may cost you a little more time and money, but excluding something can result in an AI and a re-validation or supplemental validation, which takes much longer and can be much more costly.

• Include in your protocol rationale for critical task selection, as well as traceability between use-related risk line items, use scenarios being evaluated in human factors validation, and success criteria.

8.  Overtraining test participants

FDA looks for realistic training in the human factors validation. Often manufacturers are tempted to provide excessively long or thorough training, make the training staff available during human factors validation testing when they wouldn’t be there in real world use, provide training without a representative training decay period prior to testing, or provide training to users who in the real world would not be guaranteed to receive training prior to use.

Recommendation

• Include an untrained group for each trained group if you cannot guarantee training will be received by users prior to use.

• Ensure that you include a training decay of at least 1 hour or longer.

• Utilize actual training personnel, using actual training materials, if possible, rather than using internal staff.

• Do not allow training personnel in the room during testing, unless you can justify that those personnel would be accessible during use.

9.  Unrealistic test conditions – production equivalent product, test environment

FDA expects production-equivalent user interface to be evaluated in realistic use environments, see Figure-2. Often manufacturers forget that user interface includes device hardware, software, training, labeling, instructions, quick start guides, and anything else a user might interact with to support intended use. It also include the environment, including supporting personnel, room lighting, room space, additional accessories or equipment.

Recommendation

• Document all elements of the user interface, including instructions for use, training, and anything else you expect a user may interact with to meet intended use in your human factors validation protocol or report.

• Describe the use environment you will test in and provide rationale as to how it is representative of the intended use environment, including supporting staff as applicable.

• Do not use internal staff as stand-ins for supporting staff during validation.

10. Interference with naturalistic use

FDA expects data from human factors validation data to represent real-world use as much as possible. They also expect manufacturers to gather possible root cause data from the study participants. It takes training to moderate a human factors validation test without interfering with task performance and to elicit root cause data without biasing participant responses.

Recommendation

• Moderating a human factors validation test should be done by a trained human factors professional to ensure the integrity of the data.

• Design validation should be considered separate, and any data used to support design validation should be gathered after completion of root cause analysis and should be documented in separate protocols and reports to avoid confusion from FDA reviewers.

11.  Test results indicating use-risk is not adequately controlled

FDA expects use errors. There are no human factors validations done without use errors. The goal of human factors testing (including hf validation) is to uncover use errors and determine if the risks have been adequately controlled. After submitting the FDA may have an opinion that risks could be better controlled through inclusion of other risk control measures.

Recommendation

• Develop use-related risk analyses early and do frequent formative evaluations focused on evaluating use-related risk controls to prevent uncovering need for design change late or after submission.

Conclusion

FDA’s expectations of use-related risk analysis and human factors validation make up the vast majority of their feedback to manufacturer submissions. There are a variety of specific issues raised here but the underlying theme is that FDA wants manufacturers to demonstrate they have uncovered all potential use errors that could lead to serious harm and designed and tested the effectiveness of risk controls for those use errors in a way that reflects the expected real-world use. You may have noticed that most of these issues are pre-validation, which suggests that there is time to catch and correct things prior to your validation that might otherwise trigger FDA AI requests.

If your team wants to submit with confidence here’s what you should do:

1. Begin your human factors processes early and carry them throughout development, rather than treat it as a checkbox at the tail end of development.

2. Follow the guidance in the references listed below.

   - Applying Human Factors and Usability Engineering to Medical Devices: Guidance for Industry and Food and Drug Administration Staff (2016)

   - IEC 62366-1: 2016 AMD1:2020

   - HE75:2025

3. Complete a Q-Sub and get feedback directly from the FDA prior to your submission (may wait up to 70 days).

4. If you want quick, actionable feedback on your HF documentation so you can submit (510k, PMA, IDE) with confidence, contact me (jason@hfadvice.com) for an independent review of your hf validation protocol or your full hf/usability engineering file.

References

[1] Wiyor, H. D. (2020, October 20). Risk assessment of medical products in human factors submissions with a focus on EU countries [Webinar slides]. Medical Human Factors Network.

[2] Wiklund, M. E. (2025). Medical product development: Meeting FDA’s human factors expectations. Human Factors and Ergonomics Society.

[3] Food and Drug Administration. (2022). Content of human factors information in medical device marketing submissions (Draft guidance for industry and FDA staff). U.S. Department of Health and Human Services. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-human-factors-information-medical-device-marketing-submissions

[4] Food and Drug Administration. (2016). Applying human factors and usability engineering to medical devices (Guidance for industry and FDA staff). U.S. Department of Health and Human Services. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices

[5] Food and Drug Administration. (2024, July 8). Purpose and content of use‑related risk analyses for drugs, biological products, and combination products (Draft guidance). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/purpose-and-content-use-related-risk-analyses-drugs-biological-products-and-combination-products

[6] International Electrotechnical Commission. (2020). IEC 62366‑1:2015+A1:2020—Medical devices—Part 1: Application of usability engineering to medical devices. IEC.

[7] International Organization for Standardization. (2019). ISO 14971:2019—Medical devices—Application of risk management to medical devices. ISO.

[8] Food and Drug Administration. (2025, May 29). Requests for feedback and meetings for medical device submissions: The Q‑Submission program (Final guidance for industry and Food and Drug Administration staff). U.S. Department of Health & Human Services. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/requests-feedback-and-meetings-medical-device-submissions-q-submission-program