The Winding Paper Trail of Human Factors Engineering

What human factors documents do regulators seek in the design

history file?
By -Michael Wiklund , Wiklund Research & Design
Originally Published MD&DI August 2009.

By and large, manufacturers developing medical devices for the United States, European
Union (EU), and some Asian markets are now heavily invested in human factors engineering
(HFE), rather than just coming up to speed. It took about 10 years to get there after FDA
updated its quality system regulation in 1996, which calls for manufacturers to validate that
new devices meet users’ needs. Standards released by AAMI and IEC helped grease the skids
by describing the kind of human factors programs that could help ensure safe and effective
user interactions with devices.1,2 But, Medical Device Use-Safety: Incorporating Human
Factors Engineering into Risk Management, a guidance published by FDA on June 18, 2000,
has been the real force behind the movement. In short, manufacturers have been driven to
invest in HFE to help ensure that their medical devices receive FDA approval.

However, because FDA’s guidance and the aforementioned standards encourage

manufacturers to conduct human factors programs scaled appropriately to the associated
device’s complexity, manufacturers are left to judge: How much human factors engineering
is enough? Most human factors specialists, many of whom have to justify funds spent on
HFE, will tell you there are core HFE activities and some elective ones.

Seems sensible enough, does it not? Companies are encouraged to perform a prudent amount
of HFE sufficient to meet their need. However, the idea of picking and choosing among
optional HFE activities causes some folks heartburn—particularly those involved in
regulatory affairs who want each design history file (DHF, also called usability engineering
file) and application for market approval (e.g., 510(k)) to be complete. They are averse to
FDA letters requesting more information about the user interface design process, and such
complications can result in product launch delays and added expense. Ideally, companies
would like to put checkmarks on a standard checklist of required HFE products. But there is
no official checklist (see the sidebar “Behind the DHF”). So, let us examine the emerging
standard for HFE and associated products that compose the DHF and support a 510(k)
application. The following passages take a U.S.-centric view, but much of what follows
applies in other regions as well.

Emerging Practice

The emerging practice reflects the case studies offered in AAMI HE74:2001. The following
sections present the core HFE activities: plan the HFE program, conduct user research,
develop user requirements, and design and model the user interface. Then the interface must
be tested (in its preliminary form), the use-related risks identified, and the final user interface
verified and validated.

Plan the HFE Program. AAMI HE74:2001 and FDA’s guidance provide extensive details
on HFE program planning. The basic idea is to take a strategic, rather than ad hoc, approach
to HFE. HFE plans tend to read like proposals and are certainly subject to revision over time.
But they help guide user interface design efforts and give regulators a roadmap to follow
while reviewing a manufacturer’s response to HFE-related regulations.

Conduct User Research. User research methods include observing similar medical devices
in use, interviewing a sample of people who are likely to use the new device, and conducting
benchmark (i.e., comparative) usability tests of competing and predecessor devices. These
activities are typically documented in research plans and reports.

Develop User Requirements. This step involves converting accumulated knowledge about
users, use environments, and use scenarios (including worst cases) into requirements for the
future product—this is what FDA terms design inputs. User requirements may also be
derived from human factors design principles found in standards and textbooks. Although
user requirements may be combined with other engineering requirements, many companies
consolidate them into a stand-alone document, or at least into a single section within a
broader set of product requirements. Here are some sample user requirements:

• Users shall be able to read the critical parameter values (heart rate, respiration rate, oxygen
saturation, etc.) at a distance of 10 m.
• Center-to-center distance between buttons shall be at least 2 cm to guard against accidental
actuation.

Design the User Interface. The design is a highly varied process.

Design products will take very different forms depending on the type of
device being designed. For example, a new infusion set and a
cardiopulmonary bypass machine likely have different design products.
Still, most user interface design efforts involve an orderly progression
A usability test from design concepts to one or more preliminary designs, then to a
participant interacts single, refined design, and to a final design. Finished HFE products,
with an early which FDA terms design outputs, include conceptual model diagrams,
prototype of a task flow diagrams, control panel layouts, software hierarchy diagrams,
and software screens.
hospital
bed’s
software user Model the User Interface. If a company is developing a hardware
interface. (Image product such as a plastic disposable, for example, it might build multiple
courtesy of HILL- nonworking and working models. If a company is developing a software
ROM INC. product (e.g., a diabetes management application that enables users to
analyze blood glucose–level trends), it will probably start with basic
(Batesville, IN))
representations, such as slide shows or screen flows. It may then move
on to interactive simulations, such as high-fidelity prototypes built in Adobe Flash, and,
ultimately, working software. A company developing a hybrid product with both hardware
and software user interfaces will likely produce all of the models described above. From an
HFE standpoint, such models enable important design assessment activities, such as usability
tests.

Test the Evolving User Interface. Conducting so-called formative usability tests of an
evolving user interface design is the cornerstone of good research-based design. It is the time
when representative users perform representative tasks with the best user interface models
available at the given stage of design. Tests intended to identify opportunities for design
refinement are termed formative usability tests and are documented in test plans and reports.
Identify Use-Related Risks. Manufacturers are typically tasked with determining whether a
device could fail in dangerous ways related to electrical, mechanical, and thermal hazards,
for example. But they must also identify use-related hazards, assess the risk of a hazardous
event, and mitigate the risk to a feasible and practicable extent. In other words,
manufacturers must view device use as another source of risk. As explained in FDA’s
guidance, the process results in a residual risk of a hazardous event.

Driven in large part by the guidance, manufacturers are conducting increasingly detailed
analyses of use-related risks. Some are even going beyond what they consider reasonable
risks to address highly unusual circumstances associated with unintended uses and even
unintended users. The product of such analysis might be included in an overall risk analysis
report, or stand alone as a human factors risk analysis report. Sample use-related risks
include:

• User connects the gas line to the fluid line port.

• User fails to calibrate the gas sensor before use.
• User with high-frequency hearing loss doesn’t hear the auditory alarm.

The testing activity described above might identify new risks that warrant follow-up analysis,
or at least help to characterize the nature of previously recognized residual risks.

Verify the User Interface. As with other forms of engineering verification, this step calls for
the manufacturer to confirm that the final design products (outputs) correspond with the
design requirements (inputs). As such, verification does not require usability testing with
representative users. Rather, it requires someone to sit at a desk and play the match game,
documenting the findings in lengthy tables, for example.

Validate the User Interface. The subject of usability testing comes up again after the design
is virtually complete. At this point, the design is available as a working prototype that might
be indistinguishable from the marketable device. Such testing focuses on user tasks that
could lead to dangerous use errors. It produces what is arguably the most important HFE
product: the validation usability test report. Logically, every validation test report claims that
a device meets users’ needs. The report’s primary purpose is to assure regulators that the
tested device is appropriately free of user interface shortcomings that could lead to personal
injury or death.

In practice, if the validation usability test (also called a summative usability test) reveals
problems, it reverts to a formative usability test. In such instances, the failing user interface
design must be corrected, and a fresh validation test must be conducted. That said, there are
nuances in the art of validation usability testing. Manufacturers might choose to quickly fix
user interface design flaws on the fly (i.e., during the early stages of testing) and then
continue with testing, perhaps adding more sessions and including additional participants to
ensure a sufficient sample size. A validation test might identify a user interface problem that
subsequent risk analyses prove to be acceptable, negating the need for a fix and retesting.

Reviewing the DHF

At this point, let us examine our growing DHF. It contains the following:

• Human factors program plan.

• User research plans and reports.
• User requirements.
• User interface design documents.
• Risk analysis report(s).
• Usability test plans and reports.

The DHF contents leave something to be desired. Drawing an analogy to automobiles, we

have a base model stripped of useful options. It will get you where you are going. In the final
analysis, a validated user interface is the goal. But, just as some automotive options benefit
drivers, additional HFE activities benefit manufacturers and should not be viewed as
luxuries. In fact, spending more on HFE can produce a substantial return on investment.3

Optional HFE Activities

Let’s begin with a caveat: One person’s optional HFE activity is another person’s mandatory
activity. Consensus on such matters is growing but incomplete. So readers may regard the
following activities as mandatory if they wish, and expect to reap a nice payoff from the
extra effort. Metaphorically speaking, these are the upgraded seats with good lumbar support,
power windows, antilock brakes, and xenon headlights.

Develop Personas. HFE professionals create profiles or personas that document user
characteristics pertinent to the ensuing user interface design effort. Such personas may be
one- to two-page write-ups or tables that describe an archetypical user’s age, physical
characteristics, education, occupation, learning style, technical proficiencies, and product-
related needs. It is typical to develop six to eight personas for most medical devices (see an
example persona in the blue box to the right). You do not have to describe every possible
type of user—just those that provide a good reference point for defining user requirements
and making design trade-off decisions.

Define the Use Environment. Some user requirements are derived from the expected use
environment. For example, if paramedics might use a device during rescues, it helps to
characterize possible rescue settings, such as stairwells in apartment buildings and rain-
soaked roadsides, in a report.

Define Use Scenarios. Writing use scenarios is one more path toward defining user
requirements. A use scenario is a situation involving the use of the device. For example, one
scenario could be an anesthesiologist switching a patient from one mode of ventilation to
another near the end of a surgical case, when it is time for the patient to start waking up.
Complex devices might warrant several dozen use scenarios, one or more paragraphs in
length.

HFE Report. An HFE report is an executive summary of sorts that provides regulators with
a succinct summary of the HFE program and its results. One might expect such a report to be
required, but the same information contained in the report may be distributed across other
DHF products.

International Perspective

Recall the earlier point that human factors professionals could wage an energetic debate
regarding which HFE activities are core versus optional. Let’s assume that there is not a
single correct answer because the true answer is case-specific. It could depend on the nature
of the device and the residual risks associated with its use. It could depend on a company’s
prior experience and current working relationship with the regulatory agencies such as the
United States’ FDA; the UK’s Medicines and Healthcare Products Regulatory Agency
(known as MHRA); or Japan’s Ministry of Health, Labour, and Welfare. It could also depend
on a company’s relationship with a notified body, such as TÜV in the EU. Other factors
include a manufacturer’s level of commitment to a comprehensive HFE program and
acceptance that its applications for device approval might encounter HFE-related obstacles
resulting in delays.

That said, IEC 60601-1-6, “Medical Electrical Equipment Part 1–6: General Requirements
for Basic Safety and Essential Performance—Collateral Standard: Usability,” is rather
specific about the scope of a usability engineering process and its associated products. 4 For
example, the document calls for manufacturers to produce the following:

• Usability engineering process plan.

• Usability validation plan.
• Operator profiles (i.e., personas).
• Use scenarios.
• Description of operator actions associated with device functions (i.e., a task analysis).
• Hazards related to equipment use.
• Risk mitigations such as warnings, labels, and training materials.

IEC 62366:2007, “Medical Devices—Application of Usability Engineering to Medical

Devices,” presents the same kind of guidance found in IEC 60601-1-6. This standard may
soon supersede IEC 60601-1-6, and it calls for manufacturers to generate the same kinds of
HFE products.

Conclusion

Medical device developers better purchase some fresh printer cartridges, because there is a
lot of paperwork to accompany the aforementioned HFE activities. A complete HFE DHF is
going to be chock full of plans and reports. However, rather than signaling more bureaucracy
and wasting paper and electronic storage capacity, these documents will reflect intensive
scrutiny on how people interact with medical devices and the development of final designs
that are safe and usable.

By -Michael Wiklund , Wiklund Research & Design

Originally Published MD&DI August 2009.
Source: http://www.devicelink.com/mddi/archive/09/08/006.html

http://www.wiklundrd.com/
Wiklund Research & Design specializes in human factors - the art and science of developing
user-compatible products, systems, and services. We welcome you to review our expertise
and experience. Please contact us if we can be of assistance.