A usability engineering file under EN 62366-1:2015+A1:2020 is a controlled, living record that contains the use specification, the user interface specification, the use-related risk analysis, the evaluation plan, the formative and summative evaluation results, and the summative report. It is not a static submission package assembled at the end of a project. It grows with the device, updates with post-market feedback, and is the single record a notified body audits for MDR Annex I GSPR §5 and §22.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The usability engineering file is a record required by EN 62366-1:2015+A1:2020 that collects every output of the usability engineering process in one place.
  • Its contents are the use specification, the user interface specification, the use-related risk analysis, the evaluation plan, the formative and summative evaluation results, and the summative evaluation report.
  • Under MDR it supports Annex I GSPR §5 on ergonomic design and GSPR §22 on lay user suitability.
  • The file is a living document. It is updated through design changes, through post-market feedback, and through every new version of the device.
  • A notified body expects one coherent file, not a folder of loosely related artefacts from different phases of the project.
  • The most common audit finding is not missing contents. It is inconsistency between contents, typically between the use specification and the summative evaluation.

Why the file matters (Hook)

In Tibor's audit practice the usability engineering file is the fastest way to judge whether a team treats usability as engineering or as compliance theatre. A credible file reads like a continuous story. The use specification describes real users in real environments. The use-related risk analysis connects those users and environments to specific hazards. The user interface specification shows how the design addresses those hazards. The formative evaluations record the iterations. The summative evaluation validates the final design against the same scenarios that were selected for testing at the start. A reviewer can follow the logic in under an hour.

The non-credible version is what Tibor sees more often. A folder on a shared drive contains a use specification written by a consultant in month three, a user interface specification written by an engineer in month ten with no reference to the first document, three formative "tests" that are really internal demos, and a summative report pulled together in the two weeks before the technical file submission. Each document is fine in isolation. Together they contradict each other. The use specification names lay users; the summative evaluation tested only clinicians. The risk analysis names ten use-related hazards; the summative protocol tests two. The user interface specification describes an interface that no longer matches the device that was tested.

The audit finding in the second case is not that a file is missing. The finding is that the file does not demonstrate the process. And process is what EN 62366-1 and MDR Annex I actually require.

What MDR actually says (Surface)

MDR treats usability as a performance obligation under Annex I and as technical documentation content under Annex II. Neither of those locations prescribes a file structure. The structure comes from EN 62366-1.

MDR Annex I GSPR §5 requires the manufacturer to reduce risks related to the ergonomic features of the device and the intended environment of use, taking into account the technical knowledge, experience, education, training, and the medical and physical conditions of intended users. Closing out this clause requires documented evidence of a human factors process. That evidence is the usability engineering file.

MDR Annex I GSPR §22 applies when a device is intended for use by lay persons. It requires the device to be designed and manufactured to perform appropriately for the skills and means available to such users and to minimise the risk of incorrect handling. Closing out GSPR §22 requires that lay users be explicitly addressed in the usability file.

MDR Annex II lists the content of the technical documentation. It does not name a usability engineering file. It requires that the manufacturer demonstrate conformity with the GSPRs. In practice, a notified body expects the usability engineering file to be part of the technical documentation, or referenced from it, so that the GSPR §5 and §22 claims can be traced to evidence.

EN 62366-1:2015+A1:2020 names the file explicitly. The standard requires the manufacturer to establish, implement, document, and maintain a usability engineering file that contains the records produced by the usability engineering process. Every clause from 5.1 through 5.9 produces an output, and every output belongs in the file.

A worked example (Test)

Consider the same handheld measurement device introduced in the related posts on the use specification and the usability engineering process. The device is intended for clinical and home use. Here is what its usability engineering file contains, section by section, with the approximate weight of each section in a typical notified body review.

Section 1. Use specification. Seven procedures, each with user profile, environment, and operating principle. Lay users are explicitly included. Roughly 8 pages. This is the anchor the rest of the file references.

Section 2. User interface characteristics related to safety. The display, buttons, indicator lights, alarm, charger, and app pairing flow, each analysed for safety-relevant features. Around 4 pages. Drawn from clauses 5.2 and 5.3 of EN 62366-1.

Section 3. Use-related risk analysis. A table that lists every use-related hazard, references the corresponding entry in the risk management file under EN ISO 14971:2019+A11:2021, and identifies the mitigations. Around 10 pages. This is the section Tibor inspects first, because inconsistency here predicts inconsistency everywhere.

Section 4. Hazard-related use scenarios and selection for summative. For each significant use-related hazard, a concrete scenario. The subset selected for summative evaluation is identified and justified per clause 5.5. Around 6 pages.

Section 5. User interface specification. The controlled description of the final interface, including display layout, button logic, alarm behaviour, IFU, and app screens. Around 12 pages with diagrams. This is the contract between the design team and the validation.

Section 6. Evaluation plan. The plan for formative and summative evaluation. Recruitment criteria, environment, protocol, acceptance criteria. Around 8 pages.

Section 7. Formative evaluation results. A short report per formative round with findings, design changes, and rationale. Three rounds totalling around 10 pages.

Section 8. Summative evaluation report. The final validation record. Protocol, actual recruitment, environment description, raw observations, analysis of use errors and close calls, conclusions, and residual risk statement. Around 20 pages plus annexes.

Section 9. Traceability matrix. A single table that links each hazard-related use scenario to the corresponding user interface specification element, formative rounds, and summative result. Around 4 pages.

Section 10. Living-document log. Versioning record, links to change controls and post-market feedback that triggered updates. Around 2 pages initially, growing over the product's life.

A usability engineering file for a first device comes out somewhere between 70 and 100 pages plus annexes. That is the size Tibor expects for a real device that actually ran the process. Substantially smaller usually means something was skipped. Substantially larger usually means the team confused quantity with rigour.

The Subtract to Ship playbook (Ship)

A lean team writing its first usability engineering file can follow four rules that eliminate most of the rework Tibor sees in audit.

Rule 1. Structure the file to match EN 62366-1, not to match your internal project plan. The notified body reviewer knows the standard. A file whose section headings mirror clauses 5.1 through 5.9 is readable in minutes. A file organised around internal sprints is slower to audit and produces more findings simply because the reviewer cannot find what they need. Use the standard as the template.

Rule 2. Write the file as a living document from day one. Open the file on the day the use specification draft begins. Add to it at every step of the process. Version every section. When the design changes, update the affected sections and record the update in the living-document log. Do not wait for submission to assemble it. Tibor's rule of thumb: if the whole file has the same creation date, it was written for the auditor, not for the device.

Rule 3. Enforce internal consistency with a traceability matrix. The single most useful document in the file is the traceability matrix that links use specification procedures to hazards to interface specification elements to summative test scenarios. When a change happens anywhere in that chain, the matrix forces every other link to be updated. Without the matrix, inconsistency is inevitable.

Rule 4. Integrate post-market feedback. Once the device is on the market, post-market surveillance under MDR Articles 83 to 86 will generate use-related feedback: complaints, close calls, training issues, IFU ambiguity. Every substantive piece of feedback belongs in the usability file, because it is evidence that the use specification and risk analysis must be updated. A usability file that does not change after launch is not being maintained.

Reality Check

Answer each question about the current usability engineering file.

  1. Is there one file, or a folder of documents that no one has reconciled?
  2. Does the file structure match EN 62366-1 clauses 5.1 through 5.9, or match an internal project plan?
  3. Does the use specification decompose use into distinct procedures, not into a single line that says "normal use"?
  4. Is the use-related risk analysis cross-referenced to the risk management file under EN ISO 14971:2019+A11:2021?
  5. Does the user interface specification match the device that was tested in summative evaluation?
  6. Are the hazard-related use scenarios selected for summative traceable back to the use specification?
  7. Is there a traceability matrix that links every scenario to every evaluation result?
  8. Has the file been updated since the device was cleared for market, or is it frozen at submission?
  9. If a notified body auditor opened the file tomorrow, could a team member walk through it end to end in under an hour?

Frequently Asked Questions

Is the usability engineering file a standalone document or part of the technical file? It is a standalone record required by EN 62366-1, but it is referenced from the MDR technical documentation under Annex II. A notified body expects to find the file either inside the technical documentation or clearly linked from it. The relationship matters because the GSPR §5 and §22 claims in the technical file must trace to the evidence in the usability engineering file.

Can the usability engineering file be combined with the risk management file? Not in practice. They are separate records that must stay tightly synchronised. Clause 5.3 of EN 62366-1 requires cooperation with risk management under EN ISO 14971:2019+A11:2021, but each standard has its own file requirement. The right approach is two files with explicit cross-references and a shared hazard register.

How often should the usability engineering file be updated? Whenever something changes that affects it. Design changes, updated intended purpose, new use environments, new user groups, and post-market surveillance findings all trigger updates. At minimum, the file should be reviewed as part of the annual management review under EN ISO 13485, even if nothing changes.

Does a small software-only device need the same file structure? Yes. EN 62366-1 applies equally to software as a medical device. A software-only usability engineering file is typically shorter in absolute page count because there is no hardware or cleaning procedure, but it still contains the same sections. Skipping sections because "it is just an app" is the finding Tibor writes most often on connected device audits.

Who owns the usability engineering file inside a startup? Ideally a single named owner who is also involved in risk management. In Tibor's experience, the combination of usability and risk management ownership in one person is the best predictor of internal consistency. Splitting ownership between a regulatory affairs lead and an external human factors consultant tends to produce inconsistent files.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I GSPR §5, Annex I GSPR §22, Annex II.
  2. EN 62366-1:2015+A1:2020, Medical devices, Part 1: Application of usability engineering to medical devices. Clauses 5.1 through 5.9.
  3. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.