ISO 14971 defines risk as the combination of the probability of occurrence of harm and the severity of that harm. It is the sentence every risk procedure is built on. Then you reach use error — and FDA tells you, in its own guidance, that probability is very difficult to determine for use errors and that severity is the more meaningful quantity. That is not a footnote. It is the point where the standard model stops carrying you, and most use-related risk analyses never acknowledge it.
Key takeaways
- Probability does not work for use error. FDA says so explicitly, and builds its expectations around severity instead. A URRA scored on probability is scoring something nobody can know.
- The deliberate term is use error, not user error. The guidance uses it roughly ninety times and never once says "user error" — because the design, not the person, is what you can change.
- Critical tasks are the output that matters, and FDA's definition includes compromised medical care, not just injury.
- Human factors validation with 15 participants and zero use errors bounds the true rate below about 18%. It is a discovery method, not a rate estimate — which is exactly why severity governs.
- Labeling and training are the weakest controls available, and FDA notes that knowledge gained through training decays over time.
Two standards, two files, one obligation
Use-related risk sits at the junction of two documents that were written separately and must end up traceable to each other.
IEC 62366-1 — recognized by FDA in the 2015 edition with its 2020 amendment — governs the usability engineering process and produces the usability engineering file. ISO 14971 governs risk management and produces the risk management file. Neither one contains the other. The use-related hazards you identify under 62366 are hazards under 14971, and they have to appear in both places with the reasoning intact.
Sitting over both is FDA's own guidance, Applying Human Factors and Usability Engineering to Medical Devices, which was revised in August 2026 — its first substantive update since 2016. It is a final guidance containing non-binding recommendations, and it is where the practical expectations actually live.
Use error is not user error
The vocabulary here is deliberate, and it is worth being precise about because it changes what your analysis is for.
FDA's guidance uses the term use error throughout — roughly ninety times. It uses "user error" exactly zero times. That is not an accident of style. "User error" locates the fault in the person and implies the fix is to tell them to try harder. "Use error" locates it in the interaction between the design, the user and the use environment — and only one of those three is something you control.
The practical consequence shows up in validation debriefs. "The participant did not read the instructions" is not a root cause. It is an observation about a design that depended on someone reading the instructions. The question the file has to answer is why the interface permitted the error, not why the person made it.
The standards also carve out abnormal use — a conscious, deliberate act counter to normal use and beyond reasonable means of user-interface risk control. That category exists so that genuinely unreasonable behavior does not have to be designed against. It is also the category teams reach for too quickly when a use error is inconvenient to fix.
Where the 14971 model stops working
Here is the sentence that should reshape how your URRA is built. FDA, having cited ISO 14971's definition of risk as probability combined with severity, says:
"However, because probability is very difficult to determine for use errors, and in fact many use errors cannot be anticipated until device use is simulated and observed, the severity of the potential harm is more meaningful for determining the need to eliminate (design out) or reduce resulting harm."
Read that against a typical risk matrix. Most organizations run one scoring scheme across the whole risk file: assign a probability band, assign a severity band, look up the cell, compare to an acceptability threshold. Applied to use error, the probability axis is being populated with numbers that have no basis — because the failure mode has not occurred yet, cannot be derived from component reliability, and in many cases will not even be known until someone is observed using the device.
What follows is not that risk analysis is impossible. It is that use-related risk is governed by severity, and the decision you are making is whether a use error that could cause serious harm has been designed out, guarded against, or merely written about.
Critical tasks are the output that matters
The term that carries the most weight in the whole process is critical task, which FDA defines as:
"A user task which, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user, where harm is defined to include compromised medical care."
Two parts of that deserve attention. "Would or could" sets a low bar for inclusion — plausibility, not likelihood, which is consistent with abandoning probability. And harm includes compromised medical care, which reaches well past physical injury. A missed dose, a delayed dose, an unrecognized partial delivery: none of those need injure anyone directly to qualify.
Critical tasks are what validation has to cover, and the analysis that identifies them is the analysis that determines whether your validation tested the right things. Get the critical task list wrong and a clean validation report proves nothing — you demonstrated competence at the tasks that did not matter.
What fifteen participants can and cannot tell you
FDA's guidance sets the expectation plainly: manufacturers should determine the necessary number of test participants themselves, but in general the minimum should be 15, with at least that many from each distinct user population, and potentially more for particular device types. The guidance devotes an appendix to sample size considerations and another to analyzing results.
Fifteen is a sensible minimum for the purpose. It is worth being clear-eyed about what that purpose is.
Suppose validation runs clean — fifteen participants, no use errors on any critical task. Apply the same zero-failure arithmetic that governs any sample size justification, and the 95% upper bound on the true use-error rate is:
| Participants, zero use errors | True use-error rate could still be as high as |
|---|---|
| 15 | 18.1% |
| 20 | 13.9% |
| 30 | 9.5% |
| 59 | 5.0% |
A clean run of fifteen is entirely compatible with roughly one user in six making that error in the field. To bound the rate below 5% you would need 59 participants per user group; below 1%, closer to 300. Neither is a realistic human factors study, and neither is what human factors validation is for.
Which is the point. Human factors validation is a method for discovering use errors, not for estimating their frequency. Its value lies in putting the real interface in front of real users in a realistic environment and finding the problems nobody predicted — not in producing a rate. And that is precisely why FDA tells you severity is the more meaningful quantity: the design cannot give you a reliable probability, so the analysis has to turn on how bad it would be rather than how often.
Stating that explicitly in your human factors report is a strength, not a weakness. An assessor who sees "no use errors observed in 15 participants, therefore the residual risk is low" has found an unsupported inference. One who sees the claim framed as discovery, with severity driving the acceptability argument, has found someone who understands their own method.
Labeling and training sit at the bottom for a reason
The risk control hierarchy in ISO 14971 puts information for safety last, and human factors is where that ordering gets tested hardest — because labeling and training are the cheapest controls to add and the easiest to claim credit for.
FDA is direct about their limits, noting that knowledge gained through training can decay over time. It still expects labeling and training to be updated when a design change cannot completely remove the possibility of a use error, on the principle that users should at least have enough information to understand and avoid the hazard. But that is a floor, not a solution — and the guidance adds that whatever strategy you use must be tested to confirm the hazard was actually addressed and no new hazard was introduced.
There is also a sequencing trap worth naming. Labeling and training materials should be finalized before human factors validation, because they are part of the user interface being validated. Teams that treat the IFU as a document to be tidied after testing have validated something other than the product they will ship.
Where use-related risk analysis goes wrong
- Probability scored anyway. A full probability column for use-related hazards, populated with numbers that have no derivation.
- Human factors run as a validation activity. Treated as a test at the end rather than an input that shapes the design, which leaves findings arriving when nothing can be changed cheaply.
- Critical tasks identified after the fact. Derived from what was tested rather than determining what should have been.
- "Compromised medical care" ignored. A critical task list that only considers physical injury misses missed, delayed and partial doses.
- Use errors not fed into the risk file. Findings live in the human factors report and never become hazards with controls and traceability.
- Root cause recorded as the participant. "Did not follow the IFU" closed out as user behavior rather than a design finding.
- A clean validation read as a low rate. Fifteen participants treated as statistical evidence of frequency.
- Labeling finalized after validation. The interface tested is not the interface shipped.
- Use-related residual risk left out of the overall evaluation. ISO 14971 requires an overall residual risk evaluation, and use-related risk belongs in it.
What to document
A use-related risk analysis that survives review records: the use specification, user profiles and use environments it was built against; the task analysis it derives from; which tasks are critical and why, against a definition that includes compromised medical care; the known use problems considered, including those from predicate and prior-generation devices; the basis on which use-related risk is evaluated — explicitly severity-driven, with the reasoning stated rather than implied; the risk controls applied in hierarchy order, with evidence of why anything resolved by labeling or training could not be designed out; formative evaluation findings and what changed as a result; the validation protocol tied to the critical task list, with participant numbers per distinct user population justified; and the traceability from every use-related hazard into the risk management file and the overall residual risk evaluation.
The through-line is the same one that runs through every other file an assessor opens. Nobody expects you to have predicted every use error. They expect you to show that you looked, that you looked at the right things, and that what you found changed something.
This article is general information, not regulatory or legal advice. FDA's human factors guidance contains non-binding recommendations; confirm the current version and text before relying on it. Clause and standard references are provided for navigation only — consult IEC 62366-1 and ISO 14971 directly, which are copyrighted and available from their publishers.
David Plescia
Get the next one by email
New Insights articles, sent when they are published. Same depth as the one you just read. Roughly one email a month. No sales pitches, and you can unsubscribe from any of them.