The application of usability engineering to the design of medical devices is defined by IEC-62366-1. The FDA recognizes this standard but has also published a guidance document describing the process as they see it. Fortunately there are no fundamental conflicts between the two and the guidance is, for me, an easier read.

Both are primarily concerned with identifying potential hazards related to usability and incorporating these into the risk management process. How they get to the point of identifying them can be the confusing part.

The general requirements for; what is the device to be used for, who is going to use it and in what environment the device will be used must be defined as part of the design process. Whereas this used to be included in a high level requirements document, this now must be part of a use specification.

Human factors engineering usually follows with an analysis phase where anthropometric data is used to guide the ergonomic design of the device. At the same time similar devices are considered and end users consulted to further guide the design. The study of existing devices is the first source of potential hazards which are fed into the risk analysis process.

A first attempt at a use case is created, and from this the interactions between the operator, patient and device are defined. More potential hazards are defined at this point as failures to perform the steps in the use case correctly or incorrect information exchanged between the operator, patient and device are considered.

IEC vs. FDA

The guidance document gives a good description of the analysis phase where the standard is much less clear. Looking at this from a generic design control perspective, the analysis phase is the design inputs definition. At this point a first iteration of the user interface is required which means designing the UI and making something testable. The standard confusingly only talks about design at the end of the process, but really this is all design work.

Iteration is the next part of the process and the use of renderings, mock-ups and low fidelity models to start getting feedback from users is critical to getting to a final design. The standard seems to make this more complicated than it really is. A methodical approach and careful consideration of how to test these early prototypes is essential but often the results are obvious and the feedback immediate. A key part of this is to continually update the use case and to develop a detailed specification of the user interface based on what is learned from the prototypes. At the same time the potential hazards associated with the UI are fed into the risk management process and any required mitigations incorporated into the design. All of this is the formative testing which exercises portions of the UI in order to finalise the design.

At some point a final design evolves and summative testing of the device as a whole can start. Again lessons learned are fed back into the process and the design evolves. The final summative testing is intended to validate the UI as part of a safe and effective device.

This is a very brief description of what can be a lengthy process but none of it is difficult. Like all design work it requires a lot of hard work, a little bit of inspiration to distill things down to a final design. In the end we want a user interface that is as simple as possible to minimise the risk of error while giving the operator all of the required information and control.