1. Separate usability engineering from "getting a few people to try it"
Companies meeting IEC 62366 for the first time often read it as: before registration, get a few clinical staff to run the device once, film it, write a report. Files prepared on that understanding usually come back with a request for supplementation. The reason is that reviewers are not asking whether testing was done; they are asking how user-interface-related safety was systematically identified, designed for, and then verified.
A note on how standards are referred to here. Below, IEC 62366 stands for the usability engineering standard framework as a whole. When you actually fill in a registration file, what complete designation belongs in the "basis cited" field, and whether an accompanying guidance document has to be cited alongside it, are governed by the current valid version of the standard text and the current published requirements of the receiving authority. Do not copy the style used in this or any other second-hand article. How a designation is written looks like a triviality, but it is exactly the field a reviewer's eye lands on first.
IEC 62366 describes a process. It starts by defining intended users, intended use environment and intended use; it identifies hazards and hazardous situations related to the user interface; it distils the safety-related parts into a user interface specification; and it then, through evaluation activities, confirms that those parts do not provoke unacceptable use errors under real operating conditions. Testing is only the last link in that chain. If links earlier in the chain are missing, no amount of care at the end will make up for it.
That directly defines the laboratory's role in a project. A laboratory can take on compliance review of user-interface-related material, execution and record-keeping in support of summative evaluation, and the portion of verification that intersects with the safety requirements of the IEC 60601-1 and GB 9706.1 framework. But the use specification and the safety-related user interface specification can only be produced by the manufacturer. They are design inputs, not test conclusions; having a laboratory write them is neither appropriate nor traceable afterwards.
2. Work out which preparation route your product takes
Products of different types put the weight of the user interface in very different places, and preparation should not follow a single template. The table below sets out the dimensions we use for an initial sort when taking on a project, so that development and regulatory colleagues can place themselves before starting.
| Product characteristic | Main form of the user interface | Preparation focus | Frameworks usually run in parallel |
|---|---|---|---|
| Non-active, no display or controls | IFU, labelling, packaging prompts, the physical form of the device itself | Comprehensibility of accompanying documents; error-proofing of assembly, donning or opening steps | ISO 14971 |
| Active medical electrical equipment | Physical controls, displays, alarms, connection interfaces | Identification of controls and protection against inadvertent operation; perceptibility and comprehensibility of alarm information | IEC 60601-1, GB 9706.1, ISO 14971 |
| Embedded or standalone software | Graphical interface, parameter entry, status feedback | Boundary error-proofing on parameter entry; ambiguous interface states; consistency of software identification with interface version | IEC 62304, ISO 14971 |
| Intended for lay users in the home environment | A combination of the above | Representativeness of the user group; whether tasks can be completed unaided without training | ISO 14971, with risk re-assessed for user group differences |
The table lists only the parallel frameworks directly related to usability. How the test report is then hooked onto design inputs, design change records and quality system documents is a quality management system topic, which we cover separately rather than here.
After sorting comes another judgement: which parts of the user interface are safety related. The criterion is not whether an operation is complicated, but whether a use error at that point can lead, by some path, to a hazardous situation. Take an engineering example, and this is mechanistic reasoning rather than a statistical conclusion. On a therapy device with a heating element, setting the treatment duration looks like ordinary parameter entry, but if an incorrect duration directly causes tissue heating beyond what was intended, that step has to go into the safety-related user interface specification. Switching the interface language, by contrast, involves more steps yet does not constitute a path to a hazardous situation, and need not become a mandatory task in the summative evaluation. Drawing that line clearly cuts the downstream evaluation workload noticeably.
3. The document pack to assemble before testing
When usability material is sent back, it is usually not because the testing was poor but because the document pack has gaps or does not line up internally. The table below is what we check item by item before scheduling.
| Document | Produced by | Role at the testing stage | Common reason for rejection |
|---|---|---|---|
| Use specification (intended users, use environment, intended use, operating principle) | Manufacturer, development and clinical | Defines the object and scenario boundaries of the evaluation | User groups described vaguely; professional and lay users not distinguished; training assumptions not stated |
| List of user-interface-related hazards and hazardous situations | Manufacturer, jointly with risk management | Derives the use scenarios that need verifying | Only device failure modes listed, no use errors |
| Safety-related user interface specification | Manufacturer | Determines which operating tasks must be verified | Does not line up with risk control measures; the two cannot be cross-referenced |
| User interface evaluation plan | Manufacturer, laboratory may assist | Defines evaluation methods, task set and acceptance approach | Formative and summative evaluation treated as the same thing |
| Formative evaluation records | Manufacturer | Shows that the design went through iteration and improvement | Only conclusions retained; no process record and no closed improvement loop |
| Final IFU, labelling, packaging and training material | Manufacturer | Participate in the evaluation as part of the user interface | Still in draft at test time, inconsistent with markings on the actual unit |
| Statement of unit configuration (including software identification and configuration items) | Manufacturer | Confirms that the object evaluated is in its finalised state | Unit differs from the intended production state without a declaration |
| List of cited bases (standard designations and version status actually cited in this submission) | Manufacturer, regulatory | Matches the document pack to the submission route | Template copied from elsewhere; designations do not match the intended route |
| Relevant content from the risk management file | Manufacturer | Supports traceability from use error to risk control | The two sets of documents written independently, with no cross-references |
The last item is the one most often underrated. If usability material and risk management material are written by two separate groups, the two easily contradict each other: risk management says control is achieved "through a warning in the IFU", while the usability evaluation contains no task at all verifying whether that warning is actually read and understood. That kind of gap is obvious on inspection.
The second-to-last item has been added to this list deliberately. Plenty of companies have perfectly decent usability documents but come unstuck on the cited-basis field: the template came from somewhere else and carries the overseas designation while the actual submission follows the domestic route, or the other way round. Get that field wrong and everything in front of it loses credibility.
4. Domestic and overseas routes: the differences are in citations and file naming
At method level the two routes follow the same logic: a use specification first, then user-interface-related hazards and hazardous situations, from which the safety-related user interface specification is distilled, then formative evaluation to drive design iteration and summative evaluation to close out. The differences that actually trip people up are not in the method but in how the documents are written, named and indexed.
| Dimension | Domestic registration route | Overseas technical file route | Practical advice |
|---|---|---|---|
| How the basis is cited | Usually cites the transposed domestic standard; designation and current valid version to be confirmed against the standard text and the authority's requirements | Usually cites the international designation directly, again against the current valid version | Fix this field before drafting rather than changing it as you go |
| How documents are organised | More often mapped item by item into the file structure given by the receiving authority | More often gathered into a single usability engineering technical file | Do the content once, generate two indexes from it |
| How traceability is indexed | Relies more on cross-references between file sections | Relies more on a traceability matrix inside the file | Build the traceability matrix first and derive both indexes from it |
| Link with safety standards | Connects with the relevant requirements of domestic safety standards such as GB 9706.1 | Connects with the relevant requirements of international safety standards such as IEC 60601-1 | Keep the unit and software state identical between the safety and usability activities |
It has to be stressed that the table describes forms commonly seen in practice; it is not a restatement of regulatory text. Which designation to cite, which edition applies, and how the file is to be organised are governed by the current valid version of the standard text and the current published requirements of the receiving authority in the target market. Classification decisions for the same product can differ between markets, and the depth of documentation that follows differs with them, so each product has to be confirmed individually rather than inferred from experience with similar products.
For companies pursuing both routes, our advice is to keep one content layer only. Build the use specification, hazard list, user interface specification, evaluation plan and evaluation records as modules that stand alone yet assemble cleanly. Then, at the submission layer, generate the citation list and index separately for each route. The benefit is that any design change is edited in one place in the content layer, both submissions update together, and the two never end up telling different stories.
5. Traceability: from use error to risk control, end to end
We suggest drawing the traceability matrix yourself before testing. Horizontally it has to link at least these segments: intended users and use scenarios, then possible use errors, then the hazardous situations and potential harms they lead into, then the risk control measures taken, then the evaluation tasks that verify those measures are effective. This section discusses only that chain. How records are controlled and how reports are folded into system documentation is a separate topic and is not opened up here.
Following the logic of ISO 14971, risk control measures have an order of priority, and controls that land on the user interface usually fall into the "information for safety" category, whose effectiveness depends on the user perceiving and understanding it. So wherever a control measure rests on a marking, a warning or an interface prompt, there has to be a corresponding verification task in the evaluation; a sentence in the risk file is not enough on its own. Conversely, where a use error has been judged in the risk analysis to need no control, there has to be a reviewable rationale, rather than the item simply disappearing from the list.
Once the matrix is drawn, run a reverse check: take each task in the evaluation plan and work backwards to see whether it has a source. A task with no source means either the list has a gap or the task has been set too broadly. This step does not take long, and it heads off a fair amount of rework later.
6. Fixing the unit, the users and the scenario for summative evaluation
The state of the unit under evaluation is where most projects stumble. Summative evaluation requires the object to be in its finalised state, which means external markings, control feel, interface wording, accompanying IFU and packaging form should all match the product as intended for market. A printed label stuck on an engineering unit, or a debug menu still present in the interface, will, once noticed, cast direct doubt on the applicability of the evaluation conclusion. Software products additionally need the software identification to correspond to the evaluation records, otherwise any later interface change invites an argument about whether the evaluation has to be repeated.
Representativeness of the user group is the other frequent issue. Participants should come from the intended user group defined in the use specification, and the distribution of their experience, training history, sensory and manual capability should cover the real user population, rather than the company's own development or marketing staff standing in. For products intended for lay users, differences in vision, grip strength and cognitive load also have to be considered. If the product will be accompanied by training in real use, the training content and format given during the evaluation should match what is actually provided, and this should be stated in the report.
How faithfully the use scenario is reproduced matters just as much. The evaluation environment does not have to be an exact copy of the clinical setting, but the elements that affect operating performance should be retained: lighting conditions, the effect of ambient noise on alarm perceptibility, whether the operator wears gloves, whether there is multitasking interference, whether the task is performed by one person or two. Simplifying away any one of these can push the result away from real use. Quantitative requirements on environmental conditions and acceptance approach are governed by the current valid version of the standard text.
One more point often overlooked is the moderator's manner of prompting. If a task instruction inadvertently hints at the correct path, the use error is masked. We suggest a dry run with internal staff before the real sessions, specifically to check that the wording of instructions is neutral.
7. Instructions for use and labelling are part of the user interface
Many companies treat the IFU as an attachment to the registration file rather than as part of the product. Within the usability framework, accompanying documents carry the same job as the device itself in guiding correct operation, and are therefore also subject to evaluation. Things to check include: whether key safety information appears where users will actually look for it; whether the order of warnings and steps matches the real operating sequence; whether figures correspond one to one with the physical product; and whether wording aimed at lay users avoids a pile-up of technical terms.
A common problem is that the IFU is written independently by the technical documentation function and drifts away from the design intent: key names on the device do not match what the IFU calls them, or the operating sequence described in the IFU differs from the actual firmware logic. Inconsistencies of this kind surface easily when a laboratory runs an interface comparison. Checking the physical unit, the interface wording and the IFU against each other before testing costs very little and pays back directly.
If the product is going to both domestic and overseas markets, accompanying documents carry one more easily overlooked task: consistency between language versions. If warning wording, figure numbering or step order in a translated version does not line up with the master, the evaluation conclusion covers only the version that was evaluated. The safe approach is to state the relationship between the finalised master, the finalised translation and the version used in the evaluation in the statement of unit configuration.
8. Products containing software: the two document sets must point at each other
For devices containing software, a visible link has to exist between the IEC 62366 and IEC 62304 documents. Any requirement in the software lifecycle documentation that concerns interface presentation, parameter entry, status feedback, alarm triggering or prompts should have a counterpart in the user interface specification. Conversely, interface problems found during usability evaluation should be closed out through the software requirements and verification process, rather than patched with an ad hoc interface change.
Configuration management is the other practical point. The software identification, parameter configuration and optional feature switch states used during evaluation all have to be recorded. Where the product has multiple configuration combinations, the evaluation plan has to state which combinations were selected and why, so as to avoid the situation of evaluating one configuration and claiming coverage of all of them.
9. When to bring the laboratory in
Based on the projects we take on, waiting until the registration file is nearly ready before contacting a laboratory usually means the low-cost window for involvement has already closed. A smoother rhythm looks like this. Once design inputs are broadly frozen and the interface concept has taken shape, hold a first discussion to confirm whether the granularity of the use specification and user interface specification is sufficient. Formative evaluation can be organised in house, but aligning the method and record format up front saves rewriting records later. Summative evaluation is worth scheduling early, because participant recruitment, scenario set-up and unit availability usually take longer than the sessions themselves.
If the product also needs electrical safety and electromagnetic compatibility work, the usability preparation can be scheduled alongside those submissions. Once the number of units, the software version freeze date and the IFU finalisation date drift apart, you easily end up with the safety work done on one revision of the unit and the usability work on another. For general requirements on samples and documentation, start from the submission requirements and the testing process and build your internal schedule around them.
What we can offer
SUNGO Lab has laboratories in Shanghai and Hefei and is accredited by CNAS, CMA and IAS (USA). We can take on electrical safety, electromagnetic compatibility, biocompatibility, sterilisation and packaging testing for medical electrical equipment, and can provide support and technical discussion on the preparation of IEC 62366 usability engineering material, alignment of the user interface evaluation plan, and consistency checks between the IFU and the interface. It should be stated that accreditation marks only demonstrate that the laboratory holds the corresponding technical competence within its accredited scope; they are not a commitment as to market access outcomes in any target market, where the assessment opinion of the receiving authority governs.
Fuller capability and project scope are set out under testing services, and standard interpretation and practical articles under the knowledge centre. For project enquiries and scheduling call +86 132 4819 8029 or request a quote, and we will put together a submission checklist and timeline based on your product type and target market.