The European MDR and Human Factors Engineering: Designing User-friendly Software User Interfaces

Emergo by UL’s Human Factors Research and Design team has extensive experience developing software user interfaces and instructional materials for various medical devices. In the fourth blog post in our series on the European Medical Devices Regulation (MDR) and human factors engineering, we reference various MDR General Safety and Performance Requirements (GSPRs) laid out in Annex I associated with the design of user-friendly software user interfaces and informational resources. Moreover, we provide our recommendations for meeting these specific requirements. In particular, the MDR reflects a greater focus on designing user-friendly software user interfaces and informational resources compared to its predecessor, the Medical Device Directive (MDD).

(Previous blog posts in our series on the MDR and human factors engineering cover use-related risks; intended purpose and exact-use function; and general usability engineering requirements.)

What are software user interfaces and informational resources? 

• Software user interfaces, also known as Graphical User Interfaces (GUI), can be embedded as applications in a medical device, used in a companion component (e.g., a remote control unit), or are part of software as a medical device (SaMD) such as a smartphone app. Users typically interact with the software interface via a screen and human input device (e.g., soft key buttons, mouse and keyboard) or, increasingly more common, a touchscreen.
• Informational resources are materials supporting proper use of a medical device. These materials can span across different touchpoints and media, such as training materials, instructional materials (e.g., Instructions for Use [IFUs], Quick Reference Guides [QRGs]), device labels, packaging, or the help function in a software user interface.

In this blog, we selected key phrases from specific GSPR paragraphs (e.g., §14.6) related to software user interfaces and informational resources, and included some recommendations for how to meet these requirements.

Design of user-friendly software user interfaces

Selected GSPRs:

Here are a few ways you can respond to these requirements in your design process:

• Design software user interfaces while taking into account the “intended purpose, users and the environmental condition” (§14.6) (including users’ experience with [similar] devices/technology). For example, consider which tasks users should perform with the medical device, the impairments/limitations with which they might need to cope, and the characteristics of the use environment (e.g., light, sound, space). This will help to ensure that users can use the medical device in a safe and effective manner for its intended purpose and the intended environment.
• Incorporate “ergonomic principles” (§14.6) that enhance the ease of use of software user interfaces. For example, given that more and more displays are becoming touch displays, ensure that interactive touch targets (on-screen elements that someone can interact with) have an appropriate size, can be controlled by users wearing gloves (if you expect your intended users to wear gloves), and are recognizable as interactive features. 
• Make sure the software user interface is intuitive to use and guides users through “all stages of the procedure” (§22.2), which includes both setup and performing primary functions. For example, when a specific order or sequence is needed, explore ways to use clear numbering and conspicuous on-screen cues, or perhaps a guided animation, to move users through a task successfully. Moreover, make sure that the software user interface has a clear navigational structure (e.g., clear header, secondary page, and navigation buttons), which enables users to easily navigate to functions that might be needed infrequently.
• Reduce the risk of error “in the interpretation of the results” (§22.2) (and on-screen data generally) as much as possible. Make sure to present information in an unambiguous way (e.g., decimal point numbers) that aligns with users’ knowledge level.
• Reduce the risk of user or patient injuries “in the handling of the device” (§22.2) by implementing protective mitigations in the software user interfaces (i.e., supplementing the physical hardware design) based on the use-related risk analysis. Examples might include on-screen safety alerts or prompts, such as a warning to prevent overdosing, or an animated guide to avoid connecting the wrong tube.
• Confirm that the software can be “used safely and accurately” (§22.2), and that the design of the device follows “principles of … risk management, …and validation” (§17.2). Among other things, this means you must evaluate software user interfaces with intended users for readability, comprehension, and usability throughout the development cycle. Specifically, conduct various formative evaluations, and validate the software use interface during a summative (i.e., validation) evaluation to generate evidence that users can use the (software) user interface safely.
• Reference applicable standards such as IEC 62366-2 Section 15.3 ‘Design software user interfaces’ and ANSI/AAMI HE75 Section 21 ‘Software-user interfaces’, in addition to the points above, to help guide the software user interface design.

Design of user-friendly informational resources

Selected GSPRs:

 Here are a few ways you can respond these requirements in your design process:

• Develop a clear layout for information that guides users through the process of operating the device when a “device bears instructions required for its operation” (§21.3). For example, you might use a step sequence with large numbered steps, headers and sub-headers that stand out to inform users not only where they are in the process but enable users to immediately comprehend the overall goal or task.
• Make sure the device is “accompanied by the information needed” (§23.1) to use the device safely and that the “medium, format, content, legibility, and location of the label and instructions for use” (§23.1) are easily accessible. For example, you can accompany the device with multiple forms of informational resources such as training materials (as needed), device labelling, instructions for use, and/or a help feature to ensure users have (easy) access to sufficient information at any point.

• Design informational resources “in terms readily understood by the intended user” (§23.1). If the provided information is too technical/complex, users will likely have difficulty understanding what to do and how to interpret information.
• Make sure the information “can be reasonably anticipated in the lay person's technique and environment” (§22.1) which requires considering the users’ skills, experience with (similar) devices, and technical knowledge.
• Include “safety and performance information” (§23.1) such as warnings and precautions on the device label, and/or IFU that clearly explains to users what the risks are related to using the device, and which actions they should take to avoid any harm.
• Make instructional materials that are easy to “understand and apply” (§22.1), “understood by the intended user” (§23.1), and “understandable to the user and, as appropriate, the patient” (§21.3). Among other things, this means you must to confirm that your designs are understood and applied safely and effectively. Specifically, conduct various formative evaluations to evaluate the informational resources’ readability, comprehension, and usability and validate the design during a summative (i.e., validation) evaluation to generate evidence that users can use and interpret the informational resources safely.
• Reference applicable standards such as IEC 62366-2 Section 6.5.3 ‘Information for safety’ and Section 15.5 ‘Design materials necessary for training and training’ and ANSI/AAMI HE75 Section 10 ‘Signs, symbols and markings,’ Section 11 ‘User documentation,’ and Section 12 ‘Packaging design,’ in addition to the points above, to help guide the informational resources design.

Conclusion

While developing software user interfaces and informational resources, reference the MDR’s GSPRs for full details, applicable standards, and validate your design choices through usability testing to support claims that your product is safe, effective, and easy to use for its intended purpose, by its users, and in its intended use environments.

Kimmy Ansems and Linda Giesselink are Senior User Interface Designer and Managing Human Factors Specialist, respectively, at Emergo by UL’s Human Factors Research & Design division.

Learn more about EU MDR compliance and related HFE requirements:

• HFE user research for medical devices and IVDs
• Medical device usability training and consulting
• EU MDR compliance preparation and resource center
• Webinar: Europe’s MDR and human factors