Human Factors in Medical Device Submissions

Two FDA guidance documents now govern human factors evidence for a medical device marketing submission. The 2016 guidance explains how to run the human factors engineering (HFE) process; the 2026 guidance sorts every submission into one of three HF Submission Categories, each carrying a different documentation burden. Read separately, the two invite confusion. Read as one system, they describe a single body of evidence viewed from three angles: submission, quality management system (QMS), and inspection.

Human factors engineering (HFE), also called usability engineering (UE), is the discipline that keeps a well-designed device from becoming a dangerous one in the hands of a tired nurse, a distracted parent, or a first-time lay user. FDA's expectations rest on two guidance documents that should be read together.

The first, Applying Human Factors and Usability Engineering to Medical Devices (February 2016), is the process guidance. It tells manufacturers how to characterize users, use environments, and the user interface, how to identify critical tasks, and how to run formative and validation testing — the how-to for building use safety into a device.

The second, Content of Human Factors Information in Medical Device Marketing Submissions (finalized May 29, 2026, from a December 2022 draft), is the submission-content guidance. It does not teach the HFE/UE process — it assumes the 2016 guidance was already followed — and instead answers a narrower question: given the work already done, what human factors information actually belongs in a 510(k), De Novo, PMA, or HDE? Its central innovation is a risk-based triage into three HF Submission Categories.

The two documents share a spine. Both define a critical task identically: a user task that, performed incorrectly or not performed at all, would or could cause serious harm. Both treat HFE/UE as a subset of risk management under ISO 14971. Both anchor to the same eight-section HFE/UE report structure. And both insist that the human factors record must exist and be maintained regardless of whether it is ever submitted to the FDA — the point that ties this paper together.

A marketing submission is the visible tip of the iceberg. The QMS is the body of it. An FDA inspection tests whether the body exists and matches the tip. This paper walks the same body of evidence from three vantage points: what a reviewer needs to see, what your design and risk files must hold, and what an investigator will expect you to demonstrate live.

A note on timing: the marketing-submission guidance became final in May 2026, with the FDA allowing roughly 60 days to operationalize and generally not expecting the newly recommended content in submissions received before August 1, 2026. In parallel, the Quality Management System Regulation (QMSR) took effect February 2, 2026, replacing most of the old 21 CFR Part 820 content with an incorporation-by-reference of ISO 13485:2016. Human factors documentation now lives inside a design-controls framework expressed in ISO 13485 terms.

Qserve's US FDA regulatory consulting team works across all three vantage points below (submission strategy, QMS design controls, and inspection readiness) for manufacturers preparing 510(k), PMA, De Novo, and HDE filings.

What is the difference between a URRA, a usability engineering file, and an HFE/UE report?

A usability engineering (UE) file is the complete internal record of a device's usability engineering process, maintained throughout its life. A use-related risk analysis (URRA) is the use-related slice of the risk management file: the systematic identification of use errors, hazardous situations, and harms. An HFE/UE report is a structured summary of the UE file formatted for an FDA marketing submission — drawn from the file, not a replacement for it.

FDA's two guidance documents, IEC 62366-1, and ISO 14971 describe overlapping subject matter in different vocabularies, and the mismatches are a persistent source of confusion for teams working across them. The table below is a reading guide, not a formal equivalence claim — it lets a practitioner move between frameworks without losing the thread.

How does ISO 14971 relate to FDA human factors guidance?

ISO 14971 is the risk management standard governing all medical device safety risk, and its scope explicitly names usability as a risk area it must cover. Human factors work is not adjacent to the ISO 14971 risk management file — it is the use-related portion of it. A properly executed ISO 14971 process therefore already discharges most of the human factors obligation as a matter of course.

ISO 14971:2019 is the umbrella process governing all safety-related risk for a medical device, written to be applied alongside IEC 62366-1, the international usability-engineering standard that parallels FDA's 2016 process guidance. The reframing carries a practical dividend: do the risk work once, at the depth ISO 14971 requires, and the bulk of the human factors obligation is met as a byproduct rather than a separate project.

The URRA is the use-related risk analysis, not a parallel document. ISO 14971 requires one risk management file with each hazard traceable through its controls to a residual-risk result; the URRA slots in as the use-related rows, and its task IDs make the file traceable. This forecloses the submission-to-design-file divergence that inspectors treat as a serious finding.

Human factors validation is verification of effectiveness — doing double duty. A validation study run to the 2016 rules is not only an FDA deliverable; it is the evidence ISO 14971 clause 7.2 already demands. This is also why “we'll fix it with more training or labeling” fails on both fronts at once: ISO ranks information for safety last precisely because it is hardest to verify, and an unverified control does not close a risk.

The control hierarchy settles the recurring argument. ISO's priority order gives an objective, standards-based reason to prefer design over labeling — not a matter of house style but of the recognized state of the art. That is a durable footing when a Category determination, a residual-risk conclusion, or a “no critical tasks” rationale must be defended to a reviewer or an investigator.

Post-production closes a loop ISO already mandates. Clause 10's requirement to actively collect and review post-market information and feed it back into the risk management file is the same loop the guidances describe — from MAUDE, complaints, and recalls into the URRA and, where warranted, into CAPA and design changes. One post-market process, run to ISO 14971, feeds the known-use-problems analysis both guidances require.

The upshot is a clean division of labor: the guidances say what human factors evidence to generate and how much of it to show each audience; ISO 14971 is the system that generates that evidence, holds it, and makes it traceable. Treat the standard as the engine and human factors as its use-related fuel and instrumentation, and the risk management system will have produced most of the human factors record the submission, the QMS, and the inspection each ask for — before any of the three comes calling.

Where does IEC 62366-1 fit as the process engine?

IEC 62366-1:2015, amended in 2020, specifies the structured process a manufacturer follows to identify use-related hazards, establish a user interface specification, run formative and summative evaluations, and maintain a usability engineering file. Each step produces an output that maps directly to a requirement in the FDA guidance, ISO 14971, or both — which is why the Category 3 report structure below mirrors the standard's own outputs.

For a manufacturer already working to IEC 62366-1, most of a Category 3 report's content exists before the submission question is even asked. The submission work is largely organizational rather than generative — the clause map later in this paper makes that correspondence explicit.

What are FDA's three human factors submission categories?

FDA's 2026 guidance sorts every marketing submission into one of three HF Submission Categories through a four-decision-point flowchart. Category 1 applies when nothing affecting human factors has changed. Category 2 applies when a change exists but no critical tasks are introduced or impacted. Category 3 requires a full HFE/UE report, including human factors validation testing, when critical tasks and validation data are both needed.

A submitter chooses one category per submission; if a modified device bundles several changes, they are evaluated collectively.

The categorization gate — four decision points

• Decision Point A — Is it a modification to an existing device? “Yes” routes the change down the modification path. A new device can still answer “Yes” if it shares the user interface of one of the manufacturer's own legally marketed devices.
• Decision Point B — Is there a change to the user interface, intended users, uses, use environment(s), training, or labeling? “No” lands in Category 1. Labeling and training are called out separately to force explicit consideration.
• Decision Point C — Based on the URRA, are there critical tasks (new devices), or are new critical tasks introduced or existing ones impacted (modified devices)? “No” lands in Category 2. For modified devices, FDA wants the URRA evaluated on the final finished device, not just the change in isolation.
• Decision Point D — Should human factors validation test data be submitted? This turns on the interface's history of use, its complexity, and the adequacy of existing risk controls. A sound “No” rationale lands in Category 2; “Yes” lands in Category 3.

The escalation is cumulative: Category 3 contains everything in Category 2, which contains everything in Category 1. As you climb, you add the URRA and hazard/risk analysis, the formative-analysis summary, critical-task identification, and the full validation study.

The URRA is the pivot

The URRA is what answers Decision Point C, and it is what a reviewer expects to see driving the critical-task list. The recommended tabular format captures, at minimum: a task ID (traceable to the risk file and validation testing), the user task, possible use errors, the hazardous situation, potential harm and severity, whether the task is critical, the risk control measure(s), and the method used to validate each control's effectiveness.

For modified devices, the guidance asks for a comparative URRA placing the modified-device analysis alongside the existing-device analysis, so a reviewer can see exactly which tasks, harms, and controls changed — with objective evidence wherever a modification claims existing controls remain effective.

When FDA can demand validation data even if you'd rather not

A rationale in lieu of validation testing (Category 2) is available, but validation is likely or specifically needed regardless of history where there is:

• A significant difference from similar legally marketed devices — a novel feature, new indication, new use environment, or new user group.
• New information such as recalls, adverse events, or complaints flagging a use-error safety signal.
• An increase in the severity of possible harm from use error.
• A complex interface — programming, monitoring, maintenance, or many connect/disconnect/select steps — or a device type with a known use-error history (infusion pumps are the recurring example).

When in doubt, the Pre-Submission (Q-Sub) program is the mechanism to confirm a rationale with FDA before committing to it.

The submitted record is the tip; the QMS record is the iceberg

Even a Category 1 conclusion is only credible because someone performed the analysis behind it. A Category 2 “no critical tasks” rationale presupposes a completed URRA. FDA is explicit that human factors information must be maintained whether or not it is submitted, and that a submitted report summarizes evaluations rather than reproducing raw data. The category determines how much you show, not how much you must have.

Anatomy of a full Category 3 HFE/UE report

The eight sections FDA expects, mapping to the 2016 guidance's Appendix A structure:

• Conclusion and high-level summary, including residual use-related risk.
• Descriptions of intended users, uses, use environments, and training (with a comparison for modifications).
• Description of the device user interface (graphical representation, written description, labeling, operational sequence).
• Summary of known use problems (previous models, predicate/similar devices, post-market-driven changes).
• Summary of preliminary HFE/UE analyses and evaluations (methods, key results, resulting design changes).
• Analysis of hazards and risks — the URRA document (comparative for modifications).
• Identification and description of critical tasks (process, list, severity categorization, use scenarios).
• Details of human factors validation testing of the final design (protocol, participants, results, root-cause analysis, design changes, benefit-risk discussion).

Where the Category 3 content comes from: the IEC 62366-1 clause map

For a manufacturer already working to IEC 62366-1, most of this content exists before the submission question is asked — the submission work is largely organizational, not generative.

What must a QMS retain and require for human factors under the QMSR?

Under the QMSR, effective February 2, 2026, human factors records live inside the ISO 13485 design and development file and the ISO 14971 risk management file. Procedures should require an HFE/UE process tied to design controls, a URRA maintained as a living document, formative evaluation before validation, FDA-compliant validation testing, and change control that triggers human factors re-assessment.

If the submission asks “what do we show?”, the QMS asks “what do we keep, and what must our procedures force us to do?” Under the QMSR, the answers live inside design controls now expressed through ISO 13485:2016 — principally Subclause 7.3 and the change-control obligations of 21 CFR 820.10(c). The record set the 2016 guidance calls the Design History File (DHF) is, under ISO 13485, the design and development file; both terms will coexist in documentation for some time.

Where human factors evidence lives

• The design and development file / DHF — the HFE/UE plan, user and use-environment characterizations, task analyses, formative evaluation reports, the validation protocol and report, and design review records.
• The risk management file (ISO 14971) — the overall risk analysis into which the URRA feeds, with task IDs making the two files traceable to each other.

What the QMS procedures should require

• An HFE/UE process integrated with risk management and design controls, characterizing users, use environments, and the full user interface — including labeling and training — at the start of design, with critical-task identification tied to severity-based risk analysis rather than probability, consistent with the 2016 guidance's position that severity, not probability, is the meaningful driver for use errors.
• The URRA as a living document: created early, revised at defined design milestones, finalized on the final finished device, and comparative whenever a marketed device is modified.
• Formative evaluation planned and completed before validation — skipping it turns validation into a de facto, expensive formative test — with labeling and training finalized beforehand.
• Validation testing conducted to FDA's rules: minimum 15 participants per distinct user population; representative, generally US-resident participants; employees excluded; the final interface design under realistic conditions; all critical tasks exercised; no “think-aloud” during validation; observational, knowledge-task, and interview data collection; and root-cause analysis of every use error and close call.
• Change control that routes any change to the user interface, users, uses, environments, training, or labeling through a human factors impact assessment — the same test as Decision Point B, done as a byproduct of routine change control.
• Post-market surveillance feeding the known-use-problems analysis, searching MAUDE, MedSun, CDRH recalls, safety communications, and complaint files, and linking findings to CAPA and design changes.

Records to retain regardless of what you submit

The HFE/UE plan; user/use-environment/user-interface characterizations; task analyses; formative evaluation protocols and reports; the full (and comparative) URRA; the validation protocol, scripts, forms, raw and analyzed data, and report; design review records; known-use-problem analyses; and the traceability connecting task IDs across the URRA, risk file, and validation study. FDA states these records must be maintained under applicable law and made available on request — the bridge to inspection.

What does an FDA inspector look for in human factors records?

An FDA investigator traces a critical task in both directions: from its URRA entry to the risk file's severity estimate, to the validation scenario that tested it, to the root-cause analysis of any use error, to the design change and design review that followed. Category 1 and 2 rationales — decisions not to do something — typically draw the closest scrutiny.

Under section 704(e) of the FD&C Act, records required under the QMSR (including, by reference, ISO 13485:2016 design and development records) must generally be made available to an investigator on request. The real question is whether the human factors evidence claimed actually exists, is internally consistent, and supports the conclusions drawn.

The traceability chain has to hold

The most common inspection failure is not a missing study — it's a broken chain. Task IDs exist in the URRA template precisely to make this traceability auditable, and manufacturers should be prepared to demonstrate it live, not describe it.

Category 1 and 2 rationales draw the most scrutiny

Counterintuitively, the submissions with the least content often invite the most attention, because they rest on judgment calls. “We concluded it wasn't necessary” is not a record; the analysis behind the conclusion is.

Validation rigor is checked against the 2016 rules

A study that trained participants differently than real users, timed non-time-critical tasks, or leaned on “we'll fix it with more training/labeling” without new supporting data is vulnerable. FDA is explicit that promising to mitigate validation failures through additional training, labeling changes, or a future device version is not acceptable absent new data showing the fix works.

Residual risk and benefit-risk must be defensible

FDA accepts residual use-related risk only where the record shows a systematic analysis of use errors and controls, a demonstration that further risk reduction isn't practicable, and a reasoned benefit-risk conclusion. A pattern of “test artifact” explanations for use errors is itself a red flag that test conditions were unrealistic.

Post-market linkage and submission-to-DHF consistency

Can field use problems and complaints be shown flowing into the URRA/risk files and, where warranted, into CAPA and design changes? A device modified specifically in response to a use-related safety signal — the duodenoscope-reprocessing pattern cited in FDA's 2026 examples — should show that lineage clearly. And does the human factors summary in the submission match the fuller design and development file? Divergence between what was told to FDA and what the file actually contains is among the more serious findings an investigator can make.

A crosswalk: one artifact, three views

Practical takeaways for RA, HF, and QA teams

Do the work once, at QMS depth, and let the submission draw from it. The category framework decides what a manufacturer shows, not what it must have. A QMS that produces a living URRA, disciplined formative evaluations, rule-compliant validation, and change-control-triggered HF re-assessment generates submission content as a byproduct — and survives inspection because the record already exists.

Treat Decision Point B as a change-control requirement. Wiring “does this change touch the interface, users, uses, environments, training, or labeling?” into change control closes the most common gap between the QMS and the submission.

Write rationales as analyses, not conclusions. The lowest-content submissions carry the highest inspection risk. A “no critical tasks” or “existing controls remain effective” statement is only as strong as the URRA, comparison, and objective evidence behind it.

Mind the transition dates. The QMSR's February 2, 2026 effective date reframes records in ISO 13485 terms, and the marketing-submission guidance's content expectations phase in around August 1, 2026. Use the Pre-Submission program whenever a category or rationale is genuinely uncertain.

Run ISO 14971 as the engine, not a parallel track. Embed the URRA as the use-related analysis in the risk management file, let human factors validation stand as verification of effectiveness under clause 7.2, and lean on the standard's control hierarchy and post-production loop — the shortest path through all three audiences.

Next step: gap-check your human factors documentation before you submit

A Category determination is only as defensible as the URRA, comparison, and design-file evidence behind it. Qserve's regulatory and human factors specialists can review your existing URRA, design and development file, and validation record against the 2026 FDA framework, ISO 14971, and IEC 62366-1 — before your next submission or notified body/FDA audit.

I Want a Human Factors Gap Analysis

Talk to a Regulatory Consultant

Related reading

Usability of Unknown Provenance (UOUP) — applying usability engineering to legacy devices under Annex C

Understanding the FDA 510(k) submission process

This paper is an interpretive summary of two FDA guidance documents — Applying Human Factors and Usability Engineering to Medical Devices (February 2016) and Content of Human Factors Information in Medical Device Marketing Submissions (May 2026). FDA guidance documents describe the Agency's current thinking and are nonbinding; they use “should” to mean recommended, not required. This paper is not legal or regulatory advice. Confirm current guidance, recognized standards, and regulatory requirements against FDA's official sources before making submission or compliance decisions.