When a device is used wrongly and someone is hurt, the first explanation offered is usually the user. The standards take a different view. A use error is an outcome of the interaction between a user, a device, and an environment, and the manufacturer is required to design for all three.
This guide explains the usability engineering process, the file it produces, the evaluation the manufacturer must run before release, and how to read that file against an event that has been called user error.
Who this guide is for
- Legal counsel who must separate a use error the design made likely from one it could not have prevented.
- Manufacturers — human factors, design, and risk teams who run the process and decide what the evaluation showed.
- Hospitals — clinical educators, nursing leadership, and risk managers who train users and investigate events.
This guide is general technical information. It is not legal advice. Terms follow IEC 62366-1:2015 with Amendment 1:2020 and FDA's 2016 guidance on applying human factors and usability engineering to medical devices.
01The words the standard uses
The vocabulary decides what gets investigated. "User error" is not a term in the standard; "use error" is, and it is defined without blame.
A user action, or lack of action, while using the device that leads to a different result than the one the manufacturer intended or the user expected. It includes slips, lapses, and mistakes, and it includes actions a reasonable user would take with the interface as designed.
A conscious, intentional act, or an intentional omission, that goes against or violates normal use and is beyond reasonable means of risk control by the manufacturer. The manufacturer decides where the line is, and records it.
Every group that will use the device: clinicians, patients, carers, technicians, cleaners. Each group's training, experience, and environment is part of the use specification.
Light, noise, interruption, workload, protective equipment, the other devices in reach. A task that is easy on a bench may not be easy at the bedside at three in the morning.
FDA's term for a task in which a use error could cause serious harm. Critical tasks must be identified, tested with representative users, and shown to be performed safely before the device is cleared or approved.
A complaint closed as "user error" with no reference to the task, the interface, or the use specification has not been investigated under the standard the manufacturer certified against.
Each box is a record in the usability engineering file, with a date and a version. The summative evaluation is run on the interface as it will ship; a change after it is a reason to ask whether the evaluation still applies.
02What must be on file
The usability engineering file is the record of the process. For a device cleared or approved in the United States, the human factors report in the submission summarises it; the file itself holds the detail.
The analysis
The use specification; the list of interface characteristics related to safety; the known use problems of similar devices, from the manufacturer's own complaints and the public record; the task analysis; and the hazard-related use scenarios, each tied to a hazard in the risk file.
The evaluations
Formative evaluation reports: what was tested, with whom, what went wrong, and what changed. The summative protocol and report: participants and how they represent each user group, the training they received and when, the tasks, every use error and close call observed, and the root-cause analysis of each.
The conclusion
The residual risk statement: that the interface, as evaluated, can be used safely for its intended use by its intended users, with the reasoning for any use error observed and left unaddressed.
03Which control was chosen
Risk management ranks the ways to control a risk (guide 04). Inherent safety by design first; protective measures in the device second; information for safety last. Use-related risks are where the order is most often inverted, because the last option is the cheapest.
A connector that cannot be fitted to the wrong port. A dose that cannot be entered above a hard limit. A sequence the interface enforces. The error is prevented.
A confirmation step, a soft limit with an override, a lockout, an alarm (guide 10). The error is caught, if the user reads the message.
A warning in the manual, a label, a training module. The error is described. Whether it is prevented depends on the user, the training actually given, and the environment.
A control only if the manufacturer can show it is delivered to each user group in the field, and considered in the summative study at the interval it is delivered. Training given minutes before a test, for a user who in practice was trained a year ago, is a different control.
FDA's guidance states that modifications to labeling and training are the least effective ways to reduce use-related risk, and that it expects them to be used alongside design changes, not instead of them. A critical task controlled by a warning alone is a decision to read closely.
04What to request
From the manufacturer, in the terms of the standard, with the request form in guide 05.
The usability engineering file
In full, for the version in question, with its index. The file is required by the standard; its absence is a finding.
The analyses
Use specification, task analysis, use-related risk analysis, hazard-related use scenarios, and the review of known use problems of similar devices.
Formative evaluation reports
Each one, with the findings and the design changes that followed. The findings are the history of what the interface used to do wrong.
Summative protocol and report
Participants, groups, training, tasks, every use error and close call, the root cause given for each, and the residual risk conclusion.
The human factors report
As submitted to FDA, with the critical-task list and the comparison with the full file.
Interface changes since
Every change to displays, controls, labeling, or training after the summative study, with the assessment of whether a new evaluation was needed.
Complaints coded as use error
All complaints for the device closed as user, use, or operator error, with their investigations, and the trend analysis across them (guide 13).
Ask for the file as maintained, with its index. A usability file assembled for the request is a different document from the one the summative study was run against.
05Reading the summative study
The study is the manufacturer's proof that the interface is safe in use. It is read against the event, task by task.
Was the task in the study?
The task performed in the event, as it was performed, against the critical-task list. A task not tested was not shown to be safe.
Were the users representative?
The participants' profession, experience, and training against the people who use the device in the field, and against the user in the event.
Was the environment realistic?
Lighting, noise, interruption, time pressure, and the other devices present, against the setting of the event.
What errors were seen, and what was said about them?
Every use error and close call on the task, and the cause the report gives. "Participant inattention" and "artefact of the test" are explanations to test, not accept.
What changed afterwards?
Design changes made in response, or the decision not to make them, with its reasoning.
Is the fielded interface the one tested?
Software version, screen layouts, labeling, and training materials in the field against those in the study.
06Where the record is weak
These are the findings an engineering reviewer looks for first in a usability file.
The task was not a critical task
The event's task is absent from the list, or present without the step at which the error occurred.
Errors explained away
Use errors seen in the study attributed to the participant, with no change to the interface and no residual-risk reasoning.
A control of information only
The hazard in the event is controlled by a warning or a training slide, and the file does not say why design controls were not used.
Training that the field does not get
The study trained every participant; the manufacturer does not deliver that training to the user group in the event.
Known problems not reviewed
The same use error is in the complaint files or the public record for a predecessor, and the analysis does not mention it.
The interface changed after the study
Screens, defaults, or labeling revised without a new evaluation or a recorded reason that none was needed.
Complaints closed as user error
A series of the same use error, each closed on its own, with no trend analysis and no CAPA.
The user's conduct is a separate question. The file answers whether the design made the error likely.
✓Usability at a glance
- Usability engineering file requested in full for the version in question
- Use specification, task analysis, and use-related risk analysis obtained
- Review of known use problems of similar devices obtained
- Formative evaluation reports and the design changes they caused
- Summative protocol and report: participants, training, tasks, errors, causes
- Human factors report from the submission; critical-task list
- Interface, labeling, and training changes since the study, with assessments
- Complaints coded as use error, with investigations and trend analysis
- Event task located in the critical-task list and the study
- Users, training, and environment in the study compared with the event
- Control type for the hazard identified: design, protection, or information
- Fielded interface version compared with the version tested
§Sources and further reading
- IEC 62366-1:2015 + A1:2020 — Medical devices: application of usability engineering to medical devicesiec.ch
- FDA — Applying Human Factors and Usability Engineering to Medical Devices (February 2016)fda.gov
- ISO 14971:2019 — risk control option analysis, clause 7.1 (design, protective measures, information for safety)iso.org
A–ZTerms used in this guide
- Use error
- User action or lack of user action while using the device that leads to a different result than that intended by the manufacturer or expected by the user.
- Abnormal use
- Conscious, intentional act or intentional omission of an act that is counter to or violates normal use and is beyond any further reasonable means of user interface-related risk control by the manufacturer.
- Usability
- Characteristic of the user interface that facilitates use and thereby establishes effectiveness, efficiency, and user satisfaction in the intended use environment.
- Use specification
- Summary of the important characteristics related to the context of use: intended medical indication, patient population, body part, user profile, use environment, operating principle.
- Hazard-related use scenario
- A use scenario that could lead to a hazardous situation or harm.
- Formative evaluation
- User interface evaluation conducted during development, to explore strengths, weaknesses, and unanticipated use errors.
- Summative evaluation
- User interface evaluation conducted at the end of development, with the intended users, to obtain objective evidence that the interface can be used safely.
- Critical task
- FDA's term for a user task which, if performed incorrectly or not performed at all, would or could cause serious harm.