IEC 62366-1:2015+AMD1:2020 usability validation for medical software

What does IEC 62366-1 require?

A process, and the records that process leaves behind. The standard has five numbered clauses and nothing after them: 1 Scope, 2 Normative references, 3 Terms and definitions, 4 Principles, 5 Usability engineering process. Clause 4 holds the general requirements, the usability engineering file at clause 4.2 and the tailoring of effort at clause 4.3. Clause 5 is the work, in ten subclauses numbered 5.1 to 5.10.

clause 4.1.1 requires you to establish, document, implement and maintain that process, and to address user interactions across transport, storage, installation, operation, maintenance and repair, and disposal. The list is explicitly open-ended. The same subclause requires the activities to be planned, carried out and documented by personnel competent on the basis of appropriate education, training, skills or experience, and requires an existing product realization process, such as the one in clause 7 of ISO 13485, to incorporate or reference the usability engineering process. Amendment 1 moved that cross reference from ISO 13485:2003 to ISO 13485:2016.

Nine of the ten subclauses read as a sequence.

The tenth, clause 5.10, User interface of unknown provenance, is the separate route for an interface you did not develop. clause 4.1.1 says the clause 5 activities "are described in a logical order", and Amendment 1 rewrote the rest of that sentence so that they may be carried out iteratively or in a flexible order as appropriate.

What is outside the scope?

Two things, and both of them decide what a usability report can be used for.

Usability is covered only as it relates to safety. The Introduction states that the document "strictly focuses on applying the usability engineering process to optimize medical device usability as it relates to safety", and hands task accuracy, completeness, efficiency and user satisfaction to the companion technical report. That report, IEC TR 62366-2:2016, says of itself that it "is not intended to be used for regulatory purposes" and "contains no requirements". Nothing in it can be presented as an obligation of Part 1.

Abnormal use is the second exclusion. The amended scope covers risks associated with normal use, which it splits into correct use and use error, and adds that the process "can be used to identify but does not assess or mitigate risks associated with abnormal use". Note 1 to the scope, as amended, keeps the safety concept wide: unacceptable risk from a use error "can lead to exposure to hazards including loss or degradation of clinical performance", where the 2015 wording had spoken of direct physical hazards and clinical functionality.

What compliance actually buys is written into the scope clause: "If the usability engineering process detailed in this International Standard has been complied with, then the usability of a medical device as it relates to safety is presumed to be acceptable, unless there is objective evidence to the contrary." Note 3 names where contrary evidence comes from: post-production surveillance. The presumption is rebuttable by your own field data.

Which document are you buying?

Edition 1.1, dated 2020-06-17, and it consolidates three publications rather than two. Its Foreword states the composition: "IEC 62366-1 edition 1.1 contains the first edition (2015-02) [documents 62A/977/FDIS and 62A/988/RVD] and its corrigendum (2016-07), and its amendment 1 (2020-06)." Corrigendum 1 was published 2016-07-14 and Amendment 1 on 2020-06-17.

The publisher's own names for the document differ slightly and all of them are correct. The webstore product is "IEC 62366-1:2015+AMD1:2020 CSV". The printed cover reference line is "IEC 62366-1:2015-02+AMD1:2020-06 CSV(en-fr)". The running header on every page of the text is "IEC 62366-1:2015+AMD1:2020 CSV". One file carries both a redline version, where a vertical margin line marks the amended content, and a final version with all changes accepted, which is why the IEC webstore gives 246 pages for the consolidated edition against 110 for the 2015 one.

Amendment 1 renumbered and retitled nothing. Clause 1 through 5.10 and Annex A through Annex E are identical in the two contents listings, so a procedure written against a 2015 clause number still addresses the same clause. What changed is content: the Introduction to Amendment 1 records that twenty-two issues were identified by experts working in the field and put to the national committees of IEC/SC 62A and the member bodies of ISO/TC 210, and that the amendment addresses them "while making no fundamental changes to the usability engineering process as originally conceived in IEC 62366-1:2015".

A large share of that work re-points the standard at the current risk management edition. Clause 2 contains exactly one normative reference, and Amendment 1 replaced "ISO 14971:2007" with "ISO 14971:2019". The reference is dated, so that edition specifically is what binds. Clause 3 then adopts the terms and definitions of ISO 14971:2019, which is why harm, hazard, hazardous situation, risk control and residual risk run through IEC 62366-1 while being defined in ISO 14971. The subclause pointers moved with the year: the risk control priority list at clause 4.1.2 now cites ISO 14971:2019, 7.1, and clause 5.3 requires hazard identification to be conducted as part of a risk analysis performed according to ISO 14971:2019, 5.4.

The Foreword also explains the typography of the document: requirements and definitions in roman type, means to assess compliance in italic, informative material in smaller type, and terms defined in clause 3 in small capitals. Quotations on this page are set in ordinary case.

Does FDA recognise this standard?

It recognises the consolidated edition and only that. The recognition record gives FR Recognition Number 5-129, Recognition List Number 054, date of entry 07/06/2020, for "IEC 62366-1 Edition 1.1 2020-06 CONSOLIDATED VERSION", with the identical adoption ANSI/AAMI/IEC 62366-1:2015+AMD1:2020 (Consolidated Text) and an extent of recognition of "Complete standard". A search of the recognised consensus standards database on the designation 62366 returns one result.

The same record lists FDA's guidance "Applying Human Factors and Usability Engineering to Medical Devices", issued 3 February 2016, as a supportive publication, alongside AAMI TIR50:2014 on post-market surveillance of use error management. A US submission is therefore read against two documents that are not identical to each other: the recognised standard, and FDA's own human factors expectations.

Is IEC 62366-1 harmonised under the EU MDR?

It is not listed, and that cuts against a good deal of secondary commentary. The Annex of Commission Implementing Decision (EU) 2021/1182, the harmonised standards list for EU MDR, carries 51 numbered entries in its consolidation of 7 April 2026, and no 62366 reference appears among them. The IVDR list, Decision (EU) 2021/1195 as consolidated on 30 January 2026, contains none either. Rechecking on 2 September 2026 found the same. The Commission's own harmonised standards page gives Decision (EU) 2026/1231 of 11 June 2026 (MDR) and Decision (EU) 2026/1313 of 15 June 2026 (IVDR) as the latest decisions of each kind, neither of which adds a software standard, and it names no 62366 entry.

The confusion has a source. Under the superseded Directive 93/42/EEC there was a harmonised usability standard, listed by Commission Implementing Decision (EU) 2020/437 at entry 259: "EN 62366:2008, Medical devices - Application of usability engineering to medical devices (IEC 62366:2007)". That is the European adoption of the withdrawn predecessor, which IEC 62366-1:2015 and IEC 62366-2 cancelled and replaced. Entry 258 in the same list was EN 62304:2006.

Absence from the list does not make usability optional in the EU. The general safety and performance requirements of Annex I to Regulation (EU) 2017/745 apply whatever standards you use, and conformity with them may be demonstrated by any adequate means. What harmonisation supplies, and only harmonisation, is the presumption of conformity under Article 8(1). A usability engineering file built to IEC 62366-1 remains admissible evidence for Annex I; it carries the argument without carrying the presumption.

What of this can testing actually produce?

Evidence, in two forms that the standard keeps carefully apart. User interface evaluation, defined at 3.27, is the parent activity: "process by which the manufacturer explores or assesses the user interactions with the user interface." Its note names the permitted techniques, and a usability test is one of them, alongside expert reviews, heuristic analyses, design audits and cognitive walk throughs.

Formative evaluation, at 3.7, is conducted "with the intent to explore user interface design strengths, weaknesses, and unanticipated use errors", iteratively through design and before summative evaluation. Summative evaluation, at 3.13, is conducted at the end of user interface development "with the intent to obtain objective evidence that the user interface can be used safely", and its note ties it to validation: summative evaluation "relates to validating the safe use of the user interface". Only the summative half is part of design validation. A programme that runs sessions all the way through development and never plans a terminal one has produced no validation evidence at all.

Two constraints sit inside the definition of a usability test at 3.19, which calls it a "method for exploring or evaluating a user interface with intended users within a specified intended use environment". Participants have to be intended users. The setting has to be a specified intended use environment, and Amendment 1 widened what that means: the note at 3.20 now adds that social attributes such as team versus individual, chaotic versus calm, stress level and length of shift can play a role. A session run with clinicians against live records also puts PHI in front of observers and recording equipment, and the clearance for that is arranged before the session rather than during it.

Amended clause 5.7.3 lists what a summative plan has to state for a usability test: how participant characteristics are representative of the intended user profiles, a justification of how participants are grouped into distinct user groups for determining the number of participants, the test environment and conditions of use with a rationale for their representativeness, the definition of correct use for each hazard-related use scenario, and the method of collecting data for the later analysis of use errors and use difficulties.

Amended clause 5.9 then governs the report: "The manufacturer shall analyse the data of the summative evaluation and shall identify all use errors and use difficulties that occurred. If a use error or use difficulty can lead to a hazardous situation, the root cause of any such use error or use difficulty shall be determined." Its new note explains the added concept: a use difficulty where a user almost commits a use error but recovers in time is "sometimes called a 'close call'". Amendment 1 also replaced item i) of that subclause with an obligation to document why improvement is not necessary or not practicable, so a session that ends without a design change still ends with a written reason.

Classification of what the observers saw is bounded by the definition of use error at 3.21. An unexpected physiological response of the patient is not by itself a use error. A malfunction of the device that causes an unexpected result is not a use error. Both exclusions have to hold in the report, or the analysis will be arguing about the wrong events.

clause 4.1.3 is the clause that makes labelling testable. When information for safety is used as a risk control measure, the manufacturer has to subject that information to the usability engineering process to determine that it "is perceivable by", "is understandable to", and "supports correct use of the medical device by" users of the intended user profiles in the context of the intended use environment.

That reaches further than a screen. Note 1 to entry at 3.26 states that accompanying documentation is considered part of the medical device and its user interface, and that the interface includes the physical aspects of the device as well as visual, auditory and tactile displays. Instructions for use relied on as a risk control sit inside the thing being evaluated.

Which records does an auditor open first?

The usability engineering file, defined at 3.18 as the "set of records and other documents that are produced by the usability engineering process". Two subclauses state the check in the same words: "Compliance is checked by inspection of the usability engineering file", at clause 4.1.2 and at the amended clause 5.5. Each row below is a record the standard names, beside the clause that names it.

IEC 62366-1 usability engineering file contents, with each record the standard names beside the clause that names it.

Clause	What goes in the file
4.2	The usability engineering file itself
5.1	Use specification, whose typical elements per definition 3.23 are the medical indication, patient population, part of the body interacted with, user profile, use environment and operating principle
5.2	Results of the identification of safety-related interface characteristics and potential use errors
5.5	Summary of the selection scheme for summative evaluation, the rationale for using it, and the results of applying it
5.6	User interface specification, which describes the interface "comprehensively and prospectively"
5.7	User interface evaluation plan, with formative planning at 5.7.2 and summative planning at 5.7.3
5.9	Summative evaluation data analysis: all use errors and use difficulties, with root causes for those that can lead to a hazardous situation

The 5.5 row is the one that decides how large the summative test gets. Amended clause 5.5 permits three selection strategies: all hazard-related use scenarios, a subset chosen on the severity of the potential harm, or a subset chosen on severity together with other circumstances specific to the device and the manufacturer. Whichever is chosen, "a summary of any selection scheme, the rationale for its use and the results of applying it shall be stored in the usability engineering file". The scope of the test and the defence of that scope are one deliverable.

What happens to an interface you did not develop?

It becomes a user interface of unknown provenance. Definition 3.15 sets the test by records rather than by age or origin: a UOUP is an interface, or part of one, of a device previously developed "for which adequate records of the usability engineering process of this standard are not available". The same logic governs third party code in IEC 62304, where the trigger is also the absence of the file rather than the source of the component.

clause 5.10 routes those interfaces to Annex C, which is the only normative annex of the five. Annexes A, B, D and E are informative. Annex C runs an abbreviated process in place of the full clause 5: use specification at C.2.1, review of post-production information at C.2.2, hazards and hazardous situations related to usability at C.2.3, risk control at C.2.4, and residual risk evaluation at C.2.5. Post-production information is doing real work here, since it is the one input a legacy interface has that a new design does not.

Where does a usability engineering file fail?

• The use specification names an indication and a user population and stops there, although amended clause 5.1 lists the intended use environment among the items it has to carry, and every later user group argument leans on it.
• Sessions record use errors and discard the near misses, although amended clause 5.9 extends the analysis obligation to use difficulties and names the close call in its own note.
• Scenarios reach the summative test by team judgement with nothing written down, and amended clause 5.5 asks for the scheme, the rationale and the results of applying it.
• Instructions for use are filed as documentation rather than treated as part of the user interface, so warnings relied on as risk controls never meet the clause 4.1.3 criteria.
• Participants are recruited for availability, and clause 5.7.3 asks how their characteristics are representative of the intended user profiles.
• The file still cites ISO 14971:2007 subclause numbers throughout, although Amendment 1 re-pointed the standard's single normative reference at ISO 14971:2019 in 2020.
• The summative report closes an observed difficulty with no design change and no sentence explaining why improvement is not necessary or not practicable, which amended clause 5.9 item i) asks for by name.

What do we run against IEC 62366-1?

Work starts at the use specification, because every later argument leans on it: who the users are, which use environment was claimed, and which scenarios can turn hazardous inside that environment. The hazard-related use scenarios then come out of the risk analysis, the evaluation plan is written so the summative sessions carry the five items amended clause 5.7.3 asks for, and the sessions are recorded so the analysis under amended clause 5.9 can put a root cause against each use error and use difficulty that could lead to a hazardous situation.

The usability engineering file stays with the manufacturer, and so does the conformity claim resting on it. What an outside team puts into that file is the evaluation evidence and the reasoning behind each choice of scenario, participant and environment. Medical device software testing covers the session work itself, and validation documentation covers how the resulting records are structured for review.

Clause numbers, clause titles, the edition and the recognition number on this page were checked on 2 September 2026 against the IEC catalogue entry for IEC 62366-1:2015+AMD1:2020 CSV, the publisher's previews of the 2015 edition and of Amendment 1, and the FDA recognised consensus standards database. The EU harmonised standards position was checked on the same date against the consolidated texts of the two Commission Implementing Decisions and the European Commission's harmonised standards page.