developing & verifying user interface … · 13485) when developing a medical device and must...

Farm Design, Inc. MassMEDIC Webinar 05.31.2017 of 47

Tara Feuerstein | Human Factors Engineer

Kelly GordonVaughn | Program Manager / Principal Human Factors Engineer

DEVELOPING & VERIFYING USER INTERFACE REQUIREMENTS


Tara Feuerstein | Human Factors Engineer

- Research and Engineering professional with 5+ years experience

- Responsible for executing all phases of research studies

(generative, formative, summative)

- Author and contribute to documentation, requirements, and risk processes

- MS in Industrial Engineering/Human Factors, a BS in Biomedical Engineering, and a BA in Cognitive Science with a concentration in neuroscience, all from the State University of New York at Buffalo

Kelly GordonVaughn | Program Manager / Principal Human Factors Engineer

- Research and strategy professional with 20+ years of experience

- Responsible for managing and executing all phases of research studies

(generative, formative, summative)

- Author and contribute to documentation and risk processes

- MA in Psychology from Boston University, with a concentration in brain, behavior, and cognition, and a BA in psychology and English literature from the University of South Carolina


Exclusively healthcare

45+ years of experience

ISO 13485 certified

Locations in:

- Hollis, NH

- Flex Boston Innovation Center

50+ employees

Expertise:

- Human Factors Engineering

- Industrial Design

- User Interface Design

- Concept Development

- Advanced Development

- Engineering

FARM IS A HIGHLY CREATIVE DEVELOPMENT GROUP THAT IS PASSIONATE & DEDICATED TO IMPROVING PEOPLE’S LIVES.


INTRODUCTION


OUTLINE

1. Introduction

2. Background

- Requirements & Regulatory History

3. User Interface Requirements (UIRs)

- What Are UIRs

- Who Should Be Involved

- Writing UIRS

- UIR Examples

- Tracing/Mapping UIRs

- Verifying UIRs

4. Conclusion

5. Questions & Comments


THE PURPOSE OF THIS WEBINAR IS TO DISCUSS HOW USER INTERFACE REQUIREMENTS ARE A SUBSET OF

DESIGN REQUIREMENTS AND THUS, SHOULD BE TREATED THE SAME WAY.


USABILITY REQUIREMENTS IN TERMS OF “THE USER SHALL BE ABLE TO” IS NOT THE BEST APPROACH.


USER INTERFACE REQUIREMENTS SHOULD BE VERIFIED THE SAME WAYS AS DESIGN REQUIREMENTS

(NOT USABILITY TESTING).


BACKGROUND


Requirements are mandated by US regulations (21 CFR part 820.30) as well as international regulations (ISO 13485) when developing a medical device and must be part of the Design History File (DHF).

Requirements (design inputs) provide:

- A way to develop the intended device via design constraints, and

- Criteria to test the design against (design verification) to ensure the design output meets the design input.

WHAT ARE REQUIREMENTS?REQUIREMENTS ARE CRITERIA FROM WHICH A DEVICE IS DEVELOPED


REGULATORY HISTORY OF HUMAN FACTORS

2011

FDA (CDRH) issued the Applying Human Factors andUsability Engineering to Medical Devices discussing design and testing medical devices applying human factors best practices.

2016

Human Factors Draft Guidance was finalized.

2015

IEC 62366-1:2015 Medical devices –Part 1: Application of usability engineering medical devices.

IEC/TR 62366-2:2016, BSI Standards Publication, Medical devices; Part 2: Guidance on the application of usability engineering to medical devices.

2007

IEC 62366:2007 Medical devices –Application of usability engineering to medical devices.


USER INTERFACE REQUIREMENTS (UIRS)


UIRs ensure the user interface meets usability engineering principles (accommodating human capabilities and constraints, user workflows, and preferences) while mitigating potential risk.

UIRs may be developed for:

- Software

- Hardware

- Labeling

UIRs can be used to mitigate or decrease high-risk situations by following human factors best practices.

- UIRs can not eliminate risk but may reduce the probability of occurrence (e.g., making an alarm volume louder than ambient noise).

WHAT ARE UIRS?IEC 62336-1: USER INTERFACE REQUIREMENT: TESTABLE TECHNICAL DESIGN REQUIREMENT FOR A USER INTERFACE CHARACTERISTIC.


WHAT ARE UIRS?

IEC 62366-1 states: The USER INTERFACE SPECIFICATION, in particular, includes design requirements for those elements of the USER INTERFACE that are related to safe use including those that are RISK CONTROLS.

IEC 62366-2 states: USER INTERFACE REQUIREMENTS are a principal means to ensure that a USER INTERFACE design ascribes to good USABILITY ENGINEERING principles as well as meets specific needs identified during earlier USER research activities and preferences expressed by the intended USERS.


WHAT ARE UIRS?

Our interpretation of the standard is that it takes a “design with HF in mind first” approach.

- The design should have best practice principles built in and verified to confirm.

- For example: When developing hardware that has to meet certain temperature or chemical requirements, engineers select materials based on their properties, which can likely meet the requirements. They then verify that the materials were able to withstand a certain temperature/chemical.

- Design based on human capabilities and constraints is the same thing.


HUMAN CAPABILITY AND CONSTRAINTS EXAMPLES: GRIP STRENGTH, VIEWING ANGLE, SHORT-TERM MEMORY

Preferred Viewing area

Extended Viewing area


EARLY USER RESEARCH CAN UNCOVER USER PREFERENCES RELATED TO IMPORTANT USER INTERFACE ELEMENTS AND

THESE CAN BE DEVELOPED INTO UIRS.


These UIRs may relate to:

- Most efficient/effective workflow (and design attributes that provide affordances for workflow).

- Preferred size/shape/form factor.

- Environmental attributes (lighting, ambient volume, etc.).

EARLY USER RESEARCH CAN UNCOVER FINDINGS RELATED TO IMPORTANT USER INTERFACE ELEMENTS AND THESE CAN BE DEVELOPED INTO UIRS.


At a minimum, we recommend including team members from the following functional areas:

- Human Factors

- Design

- Marketing

- Engineering

WHO SHOULD DEVELOP UIRS? UIR DEVELOPMENT IS AN INTERDISCIPLINARY ACTIVITY INVOLVING MULTIPLE TEAM MEMBERS AND IS AN ITERATIVE PROCESS.


WRITING UIRS


UIRS SHOULD BE WRITTEN IN A WAY THAT TAKES INTO ACCOUNT THE EXPRESSED USER NEED AND DESCRIBES

HOW IT CAN BE MET BASED ON HUMAN CAPABILITY CONSTRAINTS.


Sources to generate user interface requirements and help you understand human capabilities and constraints:

- HE75, Human Factors Textbooks, Anthropometric Standards.

Manufacturers might develop just a few or many user interface requirements, depending on the extent to which users interact with the given medical device. – IEC 62366-2

- The right number of requirements depends on the important preferences, safety concerns, and usability issues (e.g. infusion pump vs syringe).

Recommendation that manufacturers create a library of requirements to draw from.

- Font size at certain distances, brightness level, reading level, actuation force.

UIRS SHOULD BE WRITTEN IN A WAY THAT TAKES INTO ACCOUNT THE EXPRESSED USER NEED AND DESCRIBES HOW IT CAN BE MET BASED ON HUMAN CAPABILITY CONSTRAINTS.


UIRs written in “the user shall be able to“ language can lead to:

- UIRs that are difficult to verify as they are only able to be verified by usability testing.

- Findings that are difficult to report out and can result in more rounds of revision possibly requiring additional testing.

We propose that UIRs written in terms of device attributes that take into consideration human capabilities and constraints will lead to:

- UIRs that are straight-forward to verify.

- More usable and safe products.

- Fewer design changes in the development cycle and potentially less testing (no promises!).



UIR EXAMPLES


Source: IEC 62366-2, Annex I

User Interface Element Expressed User Need User Interface Requirement

Control Panel Buttons “Buttons should be large enough so that you do not hit the wrong one accidentally.”

Control panel buttons should be at least 1.5 cm tall and wide. Control panel buttons should be spaced at least 2 cm apart (measured center-to-center).

Display “I would like the most important parameters to stand out so I can read them from a distance.”

Primary treatment parameter shall be legible from a distance of 6 m (i.e. across the room).

Handle “I would like the surgical instrument’s handle to fit my small hand.”

The handle shall accommodate users with various size hands (ranging from the first-percentile female to the ninety-ninth-percentile male in terms of hand length and breadth).

Menu Options “It would be good if the currently selected menu item was highlighted in some way or another to be distinct.”

Highlight the currently selected option in a list of options.

On-screen Information “I want to be able to tell the difference right away between information that I am just supposed to read versus do something with.”

Differentiate read-only displays from those that allow users to edit data.

On-screen Information “I would like to look at the screen and see how much more time is left in the treatment.”

The treatment time remaining shall be displayed continuously on the main monitoring screen (the resting screen that appears while the equipment is running independently).

UIR EXAMPLES


USER INTERFACE REQUIREMENT:Control panel buttons should be at least 1.5 cm tall and wide. Control panel buttons should be spaced at least 2 cm apart (measured center-to-center).

“BUTTONS SHOULD BE LARGE ENOUGH SO THAT YOU DO NOT HIT THE WRONG ONE ACCIDENTALLY.”


USER INTERFACE REQUIREMENT:Primary treatment parameter shall be legible from a distance of 6 m (i.e. across the room).

“I WOULD LIKE THE MOST IMPORTANT PARAMETERS TO STAND OUT SO I CAN READ THEM FROM A DISTANCE.”


USER INTERFACE REQUIREMENT:The handle shall accommodate users with various size hands (ranging from the first-percentile female to the ninety-ninth-percentile male in terms of hand length and breadth).

“I WOULD LIKE THE SURGICAL INSTRUMENT’S HANDLE TO FIT MY SMALL HAND.”


UIR EXAMPLES

You can see from the examples that the requirements are written in terms of device attributes rather than tasks the user shall be able to accomplish.

- IEC 62366-2 does not write the requirements in a uniform manner of [device attribute] shall but instead uses a mixture of phrasing.

- Farm believes they do not want to dictate how to write a good requirement, but just that the requirement should take into account the human capability aspect of the expressed user need to create a requirement that is verifiable outside of a usability test.


TRACING/MAPPING UIRS


TRACING / MAPPING UIRS

Requirement Upstream Tracing Downstream Tracing Is this an UIR? Source

An inactivity alarm shall alarm at least 45 dB at 2 minutes of inactivity (no button presses) and escalate to 65 dB within 4 minutes

The user needs to be alerted to alarm situations.

Software Specification Yes IEC 60601-1-8

Button resistance shall be kept below 8.9 N (2 pounds).

The user needs to be able to program an infusion.

Hardware Specification Yes HE 75

The font size (character height) shall bebased on reading distance and guidance of HE75. Character height (inches) = Distance (minutes of arc)/(57.3 x 60)


Graphical User Interface Specification

Yes HE 75


TRACING / MAPPING UIRS

Requirement Upstream Tracing Downstream Tracing Is this an UIR? Source

An inactivity alarm shall alarm at least 45 dB at 2 minutes of inactivity (no button presses) and escalate to 65 dB within 4 minutes

The user needs to be able to respond to alarm situations.

Software Specification Yes IEC 60601-1-8

Button resistance shall be kept below 8.9 N (2 pounds).


Hardware Specification Yes HE 75

The font size (character height) shall bebased on reading distance and guidance of HE75. Character height (inches) = Distance (minutes of arc)/(57.3 x 60)


Graphical User Interface Specification

Yes HE 75


VERIFYING UIRS


VERIFYING UIRS

According to 62366-2:

- Design verification of the USER INTERFACE involves confirming that USER INTERFACE REQUIREMENTS—for example, overall MEDICAL DEVICE dimensions, display parameters such as font size or luminance, control parameters such a button resistance and computer-interface parameters such as response time—are met.

- It is restricted to those verifiable parameters that do not require USABILITY TESTS to determine that they are met, which, in practice, means that they do not entail behavioral specifications, such as the time required to learn a PROCEDURE. By definition, verification relies on ensuring design parameters are met, not that tasks can be accomplished.

UIRs should be verified outside of a usability test (but this does not mean do not run usability tests!).


VERIFICATION METHODOLOGIES

There are four types of recommended verification methodologies for any requirement:

- Inspection

- Demonstration

- Test (Bench/Lab)

- Analysis

These tests can be conducted by:

- Engineering (software, hardware, system)

- Technicians

- Human Factors (reading level assessment)

Source: http://www.ics.uci.edu/~taylor/classes/113/VandV.pdf


INSPECTION IS THE NONDESTRUCTIVE EXAMINATION OF A PRODUCT OR SYSTEM USING ONE OR MORE OF THE FIVE SENSES (VISUAL, AUDITORY, OLFACTORY, TACTILE, TASTE).

Requirement Source Test Acceptance Criteria

The power button shall have an ISO 15223 approved symbol.

ISO 15223 Visually inspect power button specification and compare to ISO 15223 approved symbol list.

Inspect power button symbol and compare to ISO 15223 approved symbol.


DEMONSTRATION IS THE MANIPULATION OF THE PRODUCT OR SYSTEM AS IT IS INTENDED TO BE USED TO VERIFY THAT THE RESULTS ARE AS PLANNED OR EXPECTED.


The display shall highlight the currently selected option on a list of options.

HE75 For all options in the GUI, select options on a screen and ensure the option is highlighted.

All options on the screen are highlighted when selected.


TEST IS THE VERIFICATION OF A PRODUCT OR SYSTEM USING A CONTROLLED AND PREDEFINED SERIES OF INPUTS, DATA OR STIMULI TO ENSURE THAT THE PRODUCT OR SYSTEM WILL PRODUCE A VERY SPECIFIC AND PREDEFINED OUTPUT AS SPECIFIED BY THE REQUIREMENTS.


An inactivity alarm shall alarm at least 45 dB at 2 minutes of inactivity (no button presses) and escalate to 65 dB within 4 minutes.

IEC 60601-1-8

In a sound chamber, test alarm volume (amplitude) at a distance of 1M and record the sound (amplitude) at 0, 2, and 4 minutes.

The sound level (amplitude) is at 45 dB at 2 minutes and 65 dB at 4 minutes.


ANALYSIS IS THE VERIFICATION OF A PRODUCT OR SYSTEM USING MODELS, CALCULATIONS, AND TESTING EQUIPMENT.


The Operator’s Manual shall be at a 6th grade reading level or below.

HE 75 Analyze random sentences in the Operator’s Manual using the Flesch-Kincaid readability test.

The reading level calculation results in a 6th grade reading level or below.

Analysis allows someone to make predictive statements about the typical performance of a product or system based on the confirmed test results of a sample set or by combining the outcome of individual tests to conclude something new about the product or system.


CONCLUSION


USER INTERFACE REQUIREMENTS ARE A SUBSET OF DESIGN REQUIREMENTS AND THUS, SHOULD BE TREATED

THE SAME WAY.


USER INTERFACE REQUIREMENTS SHOULD BE VERIFIED THE SAME WAYS AS DESIGN REQUIREMENTS

(NOT USABILITY TESTING).


REFERENCES

1. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.808&rep=rep1&type=pdf

2. https://www.meddeviceonline.com/doc/tips-for-developing-medical-device-user-needs-intended-uses-and-design-inputs-0001

3. https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM484097.pdf

4. http://medicaldeviceacademy.com/design-input-requirements/

5. IEC 62366-1 :2015, Part-1: Application of usability engineering to medical devices

6. IEC/TR 62366-2:2016, Part 2: Guidance on the application of usability engineering to medical devices

7. Applying Human Factors and Usability Engineering to Medical Devices Guidance for Industry and Food and Drug Administration Staff

8. AAMI/ANSI HE 75 Design Principles

9. IEC 60601-1-8:2006 Medical electrical equipment -- Part 1-8: General requirements for basic safety and essential performance -- Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.808&rep=rep1&type=pdf

https://www.meddeviceonline.com/doc/tips-for-developing-medical-device-user-needs-intended-uses-and-design-inputs-0001

https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM484097.pdf

http://medicaldeviceacademy.com/design-input-requirements/


QUESTIONS & COMMENTSFor additional questions or comments feel free to email us at:

[email protected] and [email protected]

mailto:[email protected]

mailto:[email protected]


THANK YOU.Business Center12 Silver Lake RoadP.O. Box 1260Hollis, NH 03049

www.farmpd.com

Phone: 603.402.5500

Development Center27 Proctor Hill Road

P.O. Box 1260Hollis, NH 03049