# Usability Engineering File: [Device name and model]

> The usability engineering file for one medical device, structured on
> IEC 62366-1:2015 with Amendment 1:2020 (*Medical devices, Part 1:
> Application of usability engineering to medical devices*, consolidated
> edition 1.1, June 2020). It records the use specification, the user
> interface characteristics related to safety, known use problems,
> hazard-related use scenarios, the user interface specification, the
> evaluation plan, formative evaluations and the summative evaluation.
> The process focuses on use errors that can lead to harm in normal use;
> it does not try to prevent deliberate abnormal use. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not regulatory or medical advice: check the
> current official texts, the expectations of your target markets and a
> qualified human factors and regulatory professional.

<!--
Guidance: How to use this template
- One file per device or device family, linked to the risk management
  file (ISO 14971). Hazard IDs, risk controls and verification records
  must use the same IDs in both files.
- Start with the use specification (section 1) and the analysis of
  known use problems (section 3) before the user interface is frozen.
  Formative evaluation is cheap early and expensive late.
- The summative evaluation tests whether the final user interface can
  be used safely. It is not a preference survey and not a training
  check: record use errors, close calls and use difficulties, then
  analyse the root cause of each.
- Clause numbers in headings point to IEC 62366-1:2015+A1:2020 for
  orientation. All wording here is original.
- The examples continue the fictional "Corvane IP-200 infusion pump"
  from the fictional maker Corvane Medical Ltd used in the risk file and
  software lifecycle templates. Delete them. HZ-04 and HZ-06 match the
  risk file examples; HZ-07 (free flow) is a new example ID to add to
  the risk file.
- Related templates: risk management file
  (`compliance/iso-14971-risk-file`), software lifecycle file
  (`compliance/medical-device-software-lifecycle`), design and
  development file (`compliance/iso-13485-design-controls`), technical
  documentation (`compliance/mdr-technical-documentation`), usability
  test plan (`design/usability-test-plan`).
-->

## Document control

<!-- Guidance: The file is a controlled QMS record. It may point to records held elsewhere, such as study reports and design files, as long as they can be retrieved on request. -->

| Field | Value |
|---|---|
| Document ID | [UEF-NNN] |
| Device | [Name, model, variants] |
| User interface version | [Hardware, software and labelling versions evaluated] |
| Linked records | [Risk management file ID, design and development file ID] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner | [@usability-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Usability engineering lead | [@name] | [Approved] | YYYY-MM-DD |
| Risk management lead | [@name] | [Approved] | YYYY-MM-DD |
| Clinical expert | [@name] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Use specification and known use problems |
| 0.6 | YYYY-MM-DD | [@name] | *Example:* Formative evaluations FE-01 to FE-03 added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Summative evaluation USAB-07 report and conclusion |

## Contents

1. Use specification (cl. 5.1)
2. User interface characteristics related to safety and potential use errors (cl. 5.2)
3. Known or foreseeable hazards and hazardous situations (cl. 5.3)
4. Hazard-related use scenarios (cl. 5.4)
5. Selection for summative evaluation (cl. 5.5)
6. User interface specification (cl. 5.6)
7. User interface evaluation plan (cl. 5.7)
8. Formative evaluations (cl. 5.8)
9. Summative evaluation (cl. 5.9)
10. Process, tailoring and user interface of unknown provenance (cl. 4, Annex C)
11. Traceability matrix
12. Glossary and references

## 1. Use specification (cl. 5.1)

<!-- Guidance: Describe who uses the device, where, for what and how. Write each user group separately, because differences in training, language, eyesight or stress level drive different use errors. A pitfall is a single user group called "healthcare professionals". -->

| Item | Value |
|---|---|
| Intended medical indication | *Example:* Continuous or intermittent intravenous infusion of fluids and medicines |
| Patient population | *Example:* Adults and children above 10 kg in hospital |
| Part of the body or tissue | *Example:* Venous access through a standard administration set |
| Operating principle | *Example:* Volumetric peristaltic pump with drug library and dose limits |
| Use environment | *Example:* Intensive care units, general wards, in-hospital transport; noise up to ward alarm levels, variable lighting, gloves worn |

| User group | Description | Training assumed | Main tasks |
|---|---|---|---|
| UG-01 *(Example)* | Intensive care nurses | Device training at induction, frequent use | Program, titrate, respond to alarms |
| UG-02 *(Example)* | General ward nurses | Device training at induction, occasional use | Program standard infusions, respond to alarms |
| UG-03 *(Example)* | Biomedical technicians | Service training | Set-up, drug library upload, preventive maintenance |

## 2. User interface characteristics related to safety and potential use errors (cl. 5.2)

<!-- Guidance: List the parts of the user interface whose misuse could lead to harm, then the use errors that could occur at each. Think of perception (cannot see), cognition (misunderstands) and action (presses wrong key). -->

| ID | User interface characteristic | Potential use error | Error type |
|---|---|---|---|
| UIC-01 *(Example)* | Numeric keypad with decimal point | Enters 10 times the intended rate | Action slip |
| UIC-02 *(Example)* | Unit selector (mL/h, mg/kg/min) | Programs in the wrong unit | Cognition, mistake |
| UIC-03 *(Example)* | Administration set loading door | Loads the set without closing the clamp, free flow | Action, omission |
| UIC-04 *(Example)* | Occlusion alarm tone and display | Alarm not noticed in a noisy ward | Perception |
| UIC-05 *(Example)* | Drug library search list | Selects a drug with a similar name | Perception, confusion |

## 3. Known or foreseeable hazards and hazardous situations (cl. 5.3)

<!-- Guidance: Use complaint data, field safety notices, literature and the user interfaces of similar devices to identify use-related hazards. Record sources so a reviewer can see the search was real. -->

| ID | Source | Known use problem | Hazard (RMF) |
|---|---|---|---|
| KUP-01 *(Example)* | Published infusion error studies | Decimal and tenfold programming errors | HZ-04 |
| KUP-02 *(Example)* | Field safety notices for similar pumps | Free flow during set loading | HZ-07 |
| KUP-03 *(Example)* | Own complaints, previous model | Occlusion alarm missed in noisy ward | HZ-06 |
| KUP-04 *(Example)* | Medication safety reports | Look-alike drug names in libraries | HZ-04 |

## 4. Hazard-related use scenarios (cl. 5.4)

<!-- Guidance: Describe each scenario as a sequence of tasks with the use error, the hazardous situation and the harm, and estimate the severity from the risk management file. These scenarios are the backbone of the evaluation plan. -->

| ID | Task sequence | Use error | Hazardous situation | Harm | Severity (RMF) |
|---|---|---|---|---|---|
| HRUS-01 *(Example)* | Select drug, enter rate, confirm, start | Rate entered 10 times too high | Over-dose delivered | Serious injury | 4 |
| HRUS-02 *(Example)* | Open door, load set, close door, open clamp | Clamp opened before the set is seated | Uncontrolled free flow | Serious injury | 4 |
| HRUS-03 *(Example)* | Hear alarm, identify occlusion, clear it, restart | Alarm not noticed for 10 min | Therapy interrupted | Serious injury for critical drugs | 4 |
| HRUS-04 *(Example)* | Search library, select drug | Look-alike drug selected | Wrong limits applied | Serious injury | 4 |
| HRUS-05 *(Example)* | Upload drug library | Outdated library file uploaded | Wrong limits applied | Serious injury | 4 |

## 5. Selection for summative evaluation (cl. 5.5)

<!-- Guidance: Decide which hazard-related use scenarios the summative evaluation must cover and record why. Scenarios with serious potential harm are usually all included; if you leave one out, give a reasoned argument, for example that a design feature makes the use error impossible. -->

| Scenario | Included? | Reason |
|---|---|---|
| HRUS-01 *(Example)* | Yes | Serious harm, primary programming task |
| HRUS-02 *(Example)* | Yes | Serious harm, known field problem |
| HRUS-03 *(Example)* | Yes | Serious harm, own complaint history |
| HRUS-04 *(Example)* | Yes | Serious harm |
| HRUS-05 *(Example)* | No | Library upload software checks version and signature (SRS-075); error verified impossible by test ST-260, argued in the risk file |

## 6. User interface specification (cl. 5.6)

<!-- Guidance: Write testable requirements for the user interface, including the requirements that come from risk controls and from the accompanying documentation and training. Link each to the scenario it addresses. -->

| ID | Requirement | Addresses | Verification |
|---|---|---|---|
| UIS-01 *(Example)* | Rates above the soft limit need a second confirmation screen showing the value in large digits | HRUS-01 | USAB-07 task 3, ST-230 |
| UIS-02 *(Example)* | The pump door cannot close unless the anti-free-flow clip is engaged | HRUS-02 | Design verification VER-140, USAB-07 task 1 |
| UIS-03 *(Example)* | High-priority alarm volume adjustable but never below a set minimum, with flashing light visible from 4 m | HRUS-03 | Alarm test, USAB-07 task 5 |
| UIS-04 *(Example)* | Drug names in the library shown with tall-man lettering for look-alike pairs | HRUS-04 | USAB-07 task 2 |
| UIS-05 *(Example)* | Quick reference card covers loading and alarm response | HRUS-02, HRUS-03 | Labelling review |

## 7. User interface evaluation plan (cl. 5.7)

<!-- Guidance: Plan the formative evaluations (what you want to learn, when, with whom) and the summative evaluation (scenarios, participants, environment, training, data collected, success criteria). Fix the summative method before you see any results. -->

### 7.1 Formative evaluation plan

| ID | Purpose | Method | Stage | Participants |
|---|---|---|---|---|
| FE-01 *(Example)* | Explore programming flows | Cognitive walkthrough with paper prototypes | Concept | 6 nurses |
| FE-02 *(Example)* | Compare two confirmation screen designs | Simulated use on a prototype | Detailed design | 8 nurses |
| FE-03 *(Example)* | Check alarm perception in ward noise | Simulated ward, recorded background noise | Pre-verification | 10 nurses |

### 7.2 Summative evaluation plan

| Item | Plan |
|---|---|
| Study ID | USAB-07 *(Example)* |
| Scenarios | HRUS-01 to HRUS-04 |
| Participants | *Example:* 15 per user group: UG-01 15, UG-02 15, UG-03 15, total 45 (UG-03 performs set-up and HRUS-02 tasks only) |
| Training | *Example:* Same training as real users receive, with a gap of at least 1 day before the session to allow for training decay |
| Environment | *Example:* Simulated ward with background noise and realistic lighting |
| Device | Production-equivalent units, released software and final labelling |
| Data collected | Observed use errors, close calls, use difficulties, task completion, participant comments in an interview after the tasks |
| Analysis | Root cause analysis of every use error and close call; assessment of residual risk in the risk management file |
| Acceptance | No use error on a selected scenario whose residual risk is judged not acceptable after root cause analysis |

Participant numbers: check the expectations of each target market. The
US FDA guidance *Applying Human Factors and Usability Engineering to
Medical Devices* (issued 3 August 2026) recommends, in general, at least
15 participants from each distinct user population for human factors
validation testing, possibly more for some device types; check the
current text before planning.

## 8. Formative evaluations (cl. 5.8)

<!-- Guidance: Record each round: what was tested, what was found, what changed. Formative findings that led to design changes are strong evidence that the process worked. -->

| ID | Date | Key findings | Design change | Linked requirement |
|---|---|---|---|---|
| FE-01 *(Example)* | YYYY-MM-DD | 4 of 6 nurses looked for the unit selector after typing the rate | Unit chosen before rate entry | UIS-01 |
| FE-02 *(Example)* | YYYY-MM-DD | Design B caught 7 of 8 simulated tenfold entries, design A caught 3 of 8 | Design B adopted | UIS-01 |
| FE-03 *(Example)* | YYYY-MM-DD | 3 of 10 nurses did not notice the alarm within 2 min at minimum volume | Minimum volume raised, light added | UIS-03 |

## 9. Summative evaluation (cl. 5.9)

<!-- Guidance: Report results per scenario and per user group, then the root cause analysis and the conclusion. A pass rate alone is not enough: explain every use error and close call, and state whether it leads to a design change, a labelling change or an argument that the residual risk is acceptable. -->

### 9.1 Results by scenario

| Scenario | Participants | Use errors | Close calls | Use difficulties |
|---|---|---|---|---|
| HRUS-01 *(Example)* | 30 (UG-01, UG-02) | 1 | 2 | 3 |
| HRUS-02 *(Example)* | 45 (all groups) | 0 | 1 | 4 |
| HRUS-03 *(Example)* | 30 (UG-01, UG-02) | 0 | 0 | 2 |
| HRUS-04 *(Example)* | 30 (UG-01, UG-02) | 1 | 1 | 1 |

### 9.2 Root cause analysis

| Observation | Scenario | Participant | Root cause | Consequence for risk | Action |
|---|---|---|---|---|---|
| OBS-01 *(Example)*: tenfold rate confirmed on the confirmation screen | HRUS-01 | P-12 (UG-02) | Participant read the drug name, not the rate, on the confirmation screen | The rate was above the hard limit, so the pump refused it (SRS-052); for a drug with wider limits the error could reach the patient, residual risk reviewed in RMF HZ-04 | Rate moved to top of screen, retested in USAB-07b with 15 UG-02 participants: 0 use errors |
| OBS-02 *(Example)*: look-alike drug selected | HRUS-04 | P-27 (UG-01) | Search list sorted by recent use placed the wrong drug first | Limits of the wrong drug were in a similar range; harm judged possible | Recent-use sorting removed, retested in USAB-07b: 0 use errors |
| OBS-03 *(Example)*: close call, clamp almost opened early | HRUS-02 | P-38 (UG-03) | Habit from previous pump model | Anti-free-flow clip prevented flow | No change; covered by UIS-02 design control |

### 9.3 Conclusion

[State whether the user interface can be used safely for the intended
use, which residual use-related risks remain, and where they are
disclosed.] *Example:* After the changes verified in USAB-07b, no use
error remained on any selected scenario; residual use-related risks are
documented in the risk management file and disclosed in the
instructions for use.

## 10. Process, tailoring and user interface of unknown provenance (cl. 4, Annex C)

<!-- Guidance: Record how the process was applied and scaled to the device, and whether any part of the user interface was developed before the process was in place. For such legacy user interfaces, Annex C of the standard describes a separate route based on post-production data. -->

| Item | Value |
|---|---|
| Process procedure | [QMS procedure ID] |
| Tailoring of effort (cl. 4.3) | *Example:* Full process for the new pump user interface; reduced process for the unchanged administration set labelling, justified by 5 years of complaint data |
| Information for safety | *Example:* Warnings on free flow and alarm volume in the instructions for use, with their effectiveness evaluated in USAB-07 |
| User interface of unknown provenance (Annex C) | [None / which parts, and the evidence reviewed] |
| Accompanying documentation and training evaluated | [Yes / No, study IDs] |

## 11. Traceability matrix

<!-- Guidance: One row per selected scenario, so a reviewer can follow it from use error to evidence without opening every table. -->

| Scenario | Hazard (RMF) | UI characteristic | Requirement | Formative | Summative | Residual risk |
|---|---|---|---|---|---|---|
| HRUS-01 *(Example)* | HZ-04 | UIC-01, UIC-02 | UIS-01 | FE-01, FE-02 | USAB-07, USAB-07b | Acceptable |
| HRUS-02 *(Example)* | HZ-07 | UIC-03 | UIS-02, UIS-05 | FE-02 | USAB-07 | Acceptable |
| HRUS-03 *(Example)* | HZ-06 | UIC-04 | UIS-03, UIS-05 | FE-03 | USAB-07 | Acceptable |
| HRUS-04 *(Example)* | HZ-04 | UIC-05 | UIS-04 | FE-01 | USAB-07, USAB-07b | Acceptable |

```mermaid
flowchart LR
  US["1 Use specification"] --> UIC["2 UI characteristics"]
  UIC --> KUP["3 Known use problems"]
  KUP --> HRUS["4 Hazard-related use scenarios"]
  HRUS --> SEL["5 Selection"]
  SEL --> UIS["6 UI specification"]
  UIS --> PLAN["7 Evaluation plan"]
  PLAN --> FE["8 Formative evaluation"]
  FE -->|"Design change"| UIS
  FE --> SUM["9 Summative evaluation"]
  SUM -->|"Use error not acceptable"| UIS
  SUM --> RMF["Risk management file"]
```

## 12. Glossary and references

<!-- Guidance: Give plain working meanings and refer to the standard for the normative definitions; do not copy them. Record the regulatory guidance you followed for each market. -->

| Term | Working meaning in this file |
|---|---|
| Use error | An action or lack of action by the user that leads to a result different from what the manufacturer intended or the user expected |
| Close call | A use error that almost happened, or was caught and corrected before it caused a result |
| Use difficulty | A task the user completed with noticeable effort, hesitation or help |
| Hazard-related use scenario | A sequence of tasks in which a use error could lead to a hazardous situation |
| Formative and summative evaluation | Evaluation during design to find problems, versus evaluation of the final user interface to show it can be used safely |

| Reference | Edition or date | Use |
|---|---|---|
| IEC 62366-1, *Medical devices, Part 1: Application of usability engineering to medical devices* | 2015 + A1:2020 (consolidated edition 1.1, 2020-06-17) | Process structure and clause numbers |
| IEC TR 62366-2, guidance on usability engineering for medical devices | 2016 | Methods guidance |
| ISO 14971 | 2019 | Risk management link |
| EU example: Regulation (EU) 2017/745, Annex I (sections 5 and 22 on use error and lay users) | Check the consolidated text | General safety and performance requirements |
| US example: FDA, *Applying Human Factors and Usability Engineering to Medical Devices* | Final, issued 3 August 2026 (first issued 3 February 2016) | https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices |
| US example: FDA, *Content of Human Factors Information in Medical Device Marketing Submissions* | Final, May 2026 | https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-human-factors-information-medical-device-marketing-submissions |
| UK example: MHRA guidance on human factors and usability engineering for medical devices in Great Britain | Check the current MHRA page | Great Britain expectations |

## Standard and licence note

Structure aligned with IEC 62366-1:2015+AMD1:2020 (consolidated edition
1.1, published 2020-06-17; stability date 2028 on the IEC webstore,
checked October 2026). Clause numbers are given for orientation only.
All wording, tables, IDs and examples are original; no text, table or
definition is reproduced from the standard. The device, participants
and results are fictional examples. This template is not regulatory or
medical advice: check the current official texts, the expectations of
your target markets and a qualified human factors and regulatory
professional.

Official text: IEC, purchase or licensed access:
https://webstore.iec.ch/en/publication/67220 (also available from
national standards bodies).

Template licence: MIT.