Written and maintained by CASRAI Editorial Board
Last updated
For medical device human factors engineers, regulatory affairs specialists, and Software as a Medical Device (SaMD) developers, a Use Failure Modes and Effects Analysis (uFMEA)—submitted to the U.S. Food and Drug Administration (FDA) as a Use-Related Risk Analysis (URRA)—is the foundational engineering table linking user interface design to clinical patient safety. Governed by FDA Human Factors Guidance, IEC 62366-1:2015+AMD1:2020, and ISO 14971, the uFMEA/URRA decomposes every user workflow into Perception, Cognition, and Action (PCA) steps to identify Critical Tasks that require summative validation testing.
What Is a Use FMEA (uFMEA) or Use-Related Risk Analysis (URRA) in Medical Device Development?
While a Design FMEA (dFMEA) evaluates component-level mechanical, electrical, or software code failures (such as a pump motor stalling or a sensor drifting) and a Process FMEA (pFMEA) evaluates manufacturing assembly defects, a use fmea medical device analysis (uFMEA or urra medical device) evaluates what happens when a human user interacts with a functioning device user interface—including physical hardware controls, graphical displays, audio alarms, packaging, and Instructions for Use (IFU).
In both hardware-based devices (such as infusion pumps, auto-injectors, or digital diagnostic devices like an Eko stethoscope) and software as a medical device human factors (SaMD clinical decision support dashboards or AI radiological triage displays), the URRA serves two simultaneous regulatory mandates:
- Scoping Summative Validation Testing (FDA CDRH / CBER / CDER): Determines which user tasks are Critical Tasks and therefore must be empirically tested with representative users in a summative human factors validation study before 510(k), De Novo, PMA, or BLA submission.
- Feeding the ISO 14971 Risk Management File & IEC 62366-1 Usability Engineering File: Connects Clauses 5.2 through 5.5 of IEC 62366-1 directly to Clause 5 (Risk Analysis) and Clause 7 (Risk Control) of ISO 14971:2019, complementing broader enterprise AI risk assessment frameworks and risk registers.
How Do You Decompose User Interactions into Perception, Cognition, and Action (PCA) Steps?
In Section 5 of FDA’s 2016 final guidance Applying Human Factors and Usability Engineering to Medical Devices, FDA instructs manufacturers to model every interaction between the user and the device user interface using the Perception–Cognition–Action (PCA) cognitive processing loop. Decomposing each task step across P, C, and A prevents engineering teams from overlooking non-obvious root causes of use error:
| PCA Stage | Human Information-Processing Function | Typical Use Error Failure Modes | Hardware & SaMD Clinical Examples |
|---|---|---|---|
| Perception (P) | Detecting and receiving sensory inputs (visual text/icons, auditory alarms, tactile detents or feedback) from the device UI and use environment. | Failure to see a warning banner due to small font/low contrast; failure to hear an IEC 60601-1-8 alarm in a noisy ICU; failure to feel a mechanical click at completion of injection. | A clinician misses a decimal point on a glaring LCD infusion screen (reading 5.0 mL/hr as 50 mL/hr) or overlooks a subtle AI confidence warning badge in a SaMD viewer. |
| Cognition (C) | Comprehending perceived information, integrating it with prior clinical training or memory, and deciding on the correct course of action. | Misinterpreting an ambiguous icon or abbreviation; unit-of-measure confusion (mg/kg vs. mg, or mmol/L vs. mg/dL); automation bias or mode confusion. |
A patient sees a blinking green LED on an auto-injector and assumes the dose delivery is complete, when blinking green actually indicates “ready to inject.” |
| Action (A) | Executing the physical motor response (pressing a button, rotating a dial, inserting a test strip, or clicking a software confirmation). | Accidental activation of an adjacent touchscreen button; premature withdrawal of a needle before the hold time elapses; incomplete Luer lock connection. | A gloved emergency responder slips and presses “Cancel” instead of “Deliver Shock” or lifts an epinephrine auto-injector after 1 second instead of holding for the required delivery duration. |
Required Columns Checklist for an FDA- and IEC 62366-1–Compliant uFMEA / URRA Table
Under FDA’s 2016 guidance and 2022 draft guidance (Content of Human Factors Information in Medical Device Marketing Submissions), a submission-ready URRA / uFMEA table must trace every task from initial interaction through residual risk:
- Task Number & Use Scenario Phase: Sequential index covering pre-use preparation, setup/calibration, primary clinical operation, alarm resolution, cleaning/reprocessing, and maintenance/disposal.
- User Task Description: Concrete action required of the intended user group (e.g., “Confirm patient weight in kg on pump programming screen”).
- PCA Sub-Step & Potential Use Error (Failure Mode): Explicit description of what the user might do incorrectly or omit (perception error, cognition error, or action slip/lapse/mistake).
- Sequence of Events & Hazardous Situation: How the use error leads to exposure of the patient or user to a device hazard (e.g., “Pump delivers 2.2× intended infusion rate”).
- Potential Clinical Harm & Severity Rating: The worst-case clinical injury or compromised medical treatment resulting from the hazardous situation, rated on the manufacturer’s ISO 14971 severity scale (e.g., Negligible, Minor, Serious, Critical, Catastrophic).
- Critical Task Flag (Yes / No): Marked Yes whenever incorrect performance or omission would or could result in serious harm (including delay or absence of critical therapy).
- Risk Control Measures (By Inherent Safety Priority): Documented following the mandatory ISO 14971 / FDA hierarchy:
- Priority 1 — Inherent Safety by Design: Physical poka-yoke keyed connectors, eliminating manual calculation steps, or removing hazardous operating modes.
- Priority 2 — Protective Measures in the Device: Hard dose limits, two-step confirmation modals for high-risk actions, or automated sensor lockouts.
- Priority 3 — Information for Safety & Training: On-screen warnings, IFU callouts, quick-reference guides, and user training (the weakest control tier in FDA review).
- Verification & Summative Validation Cross-Reference: Traceability link to the formative evaluation and the specific Summative Human Factors Validation protocol task ID evaluating the effectiveness of the risk control.
How the URRA / uFMEA Connects to the IEC 62366-1 Usability Engineering File (UEF)
In international regulatory submissions (EU MDR 2017/745, Health Canada, UKCA, and FDA Recognized Consensus Standard IEC 62366-1:2015+AMD1:2020), the uFMEA / URRA forms the core backbone of the usability engineering file across five normative clauses:
- Clause 5.1 (Use Specification): Defines intended medical indication, patient population, anatomical site, user profiles, and use environments.
- Clause 5.2 (User Interface Characteristics Related to Safety and Potential Use Errors): Identifies UI features that could impact safety and begins enumerating potential use errors.
- Clause 5.3 (Identification of Known or Foreseeable Hazards and Hazardous Situations): Cross-links directly to ISO 14971:2019 Clause 5, incorporating predicates’ MAUDE adverse event reports and recall histories.
- Clause 5.4 (Identification and Description of Hazard-Related Use Scenarios): Compiles the complete PCA sequence linking use errors to hazardous situations and harms (the URRA/uFMEA table).
- Clause 5.5 (Selection of Hazard-Related Use Scenarios for Summative Evaluation): Selects all scenarios involving Critical Tasks (or severity subsets justified under IEC 62366-1) for summative validation testing under Clause 5.9.
Critical Regulatory Trap: Why You Cannot Use Probability or RPN Cutoffs to Exclude Critical Tasks
The most common deficiency cited in FDA CDRH Additional Information (AI) letters for human factors submissions is using a traditional FMEA Risk Priority Number (RPN = Severity × Occurrence × Detectability) or an occurrence probability estimate to downgrade a high-severity use error and exclude it from summative validation testing. Both FDA guidance and IEC 62366-1 emphasize that a priori probabilities of human use error cannot be reliably calculated quantitatively. Consequently, whether a task is a Critical Task depends solely on the severity of the potential harm (could it cause serious harm or compromised medical treatment?), regardless of how unlikely engineers believe the use error to be.
Frequently Asked Questions
What is a Use FMEA (uFMEA) or Use-Related Risk Analysis (URRA) in medical device development?
A Use Failure Modes and Effects Analysis (uFMEA) or Use-Related Risk Analysis (URRA) is the structured risk management artifact that breaks down every human interaction with a medical device or Software as a Medical Device (SaMD) into discrete user tasks, identifies foreseeable use errors, links each error to its resulting hazardous situation and clinical harm severity, and documents risk control measures inside the ISO 14971 Risk Management File and IEC 62366-1 Usability Engineering File.
How do you decompose user interactions into Perception, Cognition, and Action (PCA) steps to identify potential use errors?
Under FDA human factors guidance, every user task is analyzed across three sequential stages: Perception (sensing visual, auditory, or tactile interface cues), Cognition (interpreting those cues, recalling knowledge, and deciding what to do), and Action (physically executing the manipulation or input). Mapping failure modes across P, C, and A ensures that sensory, interpretive, and physical execution errors are systematically identified.
How does the URRA / uFMEA determine Critical Tasks for FDA Human Factors validation and the IEC 62366-1 Usability Engineering File?
FDA defines a Critical Task as any user task which, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user (including compromised or delayed medical treatment). Critical Tasks are flagged in the URRA/uFMEA strictly based on the severity of potential harm—never eliminated by multiplying by low probability or Risk Priority Numbers (RPNs)—and define the mandatory test scope for summative human factors validation testing.
Sources
- U.S. Food and Drug Administration (FDA CDRH) — Applying Human Factors and Usability Engineering to Medical Devices (Final Guidance, 2016)
- U.S. Food and Drug Administration (FDA CDRH) — Content of Human Factors Information in Medical Device Marketing Submissions
- International Organization for Standardization / IEC — IEC 62366-1:2015+AMD1:2020 Medical Devices — Part 1: Application of Usability Engineering to Medical Devices
