Human Factors Standards and the Hard Human Factor Problems:
Observations on Medical Usability Standards
Lorenzo Strigini
a
and Marwa Gadala
b
Centre for Software Reliability, City, University of London, Northampton Square, London, U.K.
Keywords: Usability, Medical Devices, Usability of Standards, Automation Bias.
Abstract: With increasing variety and sophistication of computer-based medical devices, and more diverse users and
use environments, usability is essential, especially to ensure safety. Usability standards and guidelines play
an important role. We reviewed several, focusing on the IEC 62366 and 60601 sets. It is plausible that these
standards have reduced risks for patients, but we raise concerns regarding: (1) complex design trade-offs that
are not addressed, (2) a focus on user interface design (e.g., making alarms audible) to the detriment of other
human factors (e.g., ensuring users actually act upon alarms they hear), and (3) some definitions and scope
restrictions that may create “blind spots”. We highlight potential related risks, e.g. that clear directives on
“easier to understand” risks, though useful, may preclude mitigating other, more “difficult” ones; but ask to
what extent these negative effects can be avoided by standard writers, given objective constraints. Our critique
is motivated by current research and incident reports, and considers standards from other domains and
countries. It is meant to highlight problems, relevant to designers, standards committees, and human factors
researchers, and to trigger discussion about the potential and limits of standards.
1 INTRODUCTION
Glucose meters, infusion pumps, and radiation
therapy systems are a few of the many computer-
based medical devices becoming increasingly
essential in medical practice. These devices are
evolving from simple, one-function designs to
sophisticated, multi-function abilities; their range of
users is expanding to less skilled users (including
patients); and smaller, more portable devices are
introducing a variety of new use environments.
In the Aggregated Quality Assurance for Systems
(AQUAS) project, which addresses engineering
challenges arising from the inter-dependence
between system safety, security and performance, one
use case concerns extensions to a blood pressure and
neuromuscular transmission monitoring device to
provide closed-loop control of these physiological
parameters via an infusion pump. We were tasked to
explore some human factor issues in the switch from
human to automated control. Of specific interest
were exceptions situations involving extra user
interventions: for instance, scenarios in which a
device fails to perform as specified, or reverts to a
a
https://orcid.org/0000-0002-4246-2866
b
https://orcid.org/0000-0002-9148-6522
fallback mode of operation in response to detecting
failures, and/or an alarm requires intervention by a
clinician, and/or a clinician overrides a device
(rightly: e.g. due to a failure, or wrongly: e.g., a user
that mistrusts a device overrides some of its correct
decisions). This focus was linked to our own previous
research, about effects of warnings and so-called
“automation bias” (Alberdi, 2009; Povyakalo, 2013);
many of our examples will be in these areas, but some
observations are of more general relevance.
Our example in the abstract, that for an alarm to
be effective the designer has a responsibility not only
to ensure that it is audible, but that the overall device
design does not make it likely to be ignored, is but
one of a class of problems arising from the complex
interactions between the user, the device and the use
environment. These issues are known, to extents that
vary from references in the popular press to e.g. “cry-
wolf” events (users failing to intervene when they
should, because a high rate of false alarms “trained”
them to ignore alarms), to scientific literature about
“automation bias” (certain human errors becoming
more likely, or new errors being created, by use of
automated devices), “situation awareness”,
766
Strigini, L. and Gadala, M.
Human Factors Standards and the Hard Human Factor Problems: Observations on Medical Usability Standards.
DOI: 10.5220/0009179707660773
In Proceedings of the 13th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2020) - Volume 5: HEALTHINF, pages 766-773
ISBN: 978-989-758-398-8; ISSN: 2184-4305
Copyright
c
2022 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
“complacency” (user inaction when they should
intervene, attributed to users delegating to the
automated alarms their responsibility to monitor for
dangers), etc. A review of medical devices,
considering a subset of such phenomena, suggested
they affected as much as 6-11% of user decisions
(Goddard, 2014). These problems are due not only to
user interface design, but also to factors such as
accuracy of algorithms, user adaptation to the device,
etc. They are also not limited to alarm-emitting
devices but to a range of decision-support devices
providing prompts, warnings, advice, etc.; e.g., in
interpreting ECGs (Tsai, 2003) and screening
mammograms (Povyakalo, 2013).
Our work in AQUAS started with studying how
“exceptions” and security/safety/performance
interactions are covered in a set of human factors
standards that govern medical devices in the
European market: IEC 62366-1:2015 (Application of
Usability Engineering to Medical Devices) and
guidance on its application: IEC 62366-2:2016; IEC
60601-1-6:2010 (General Requirements for Basic
Safety and Essential Performance - Collateral
Standard: Usability), and IEC 60601-1-8:2007
(Collateral Standard: General requirements, tests and
guidance for alarm systems in medical electrical
equipment and medical electrical systems). For
brevity, we refer to these as European medical
usability standards” or EMUSs.
Usability standards have important roles. They
expose designers to concerns and design principles
produced by the specialist human factors (HF)
community, particularly important for safety. It
seems plausible that these standards have reduced risk
for patients. However, our reading raised concerns,
broader than our initial focus implied, about whether
EMUSs may fail to deliver some benefits. The
following three sections detail concerns about:
complex design trade-offs arising within usability and
between usability and other system attributes; a focus
on user interface design risking relative neglect of
other causes of use errors; and some definitions of
terms and of the scope of the EMUSs that may create
“blind spots”. Last, we discuss challenges in dealing
with these concerns.
2 THE ISSUE OF TRADE-OFFS
The writers of EMUSs appear concerned with the
need to ‘sell’ usability to designers, by explaining its
many advantages (e.g. Section 5.2 of IEC 62366-2).
This is in line with frequent concerns in human
factors circles that technically trained designers may
regard usability as not needing special attention. But
this presentation may end up depicting usability as a
unidimensional quality, with compliance to
prescriptions being a win-win option, without
concern for possible needs for trade-offs. For
example, an important concern about exceptions is
the rate of false positive alarms, which can lead to
inappropriate user action. IEC 60601-1-8 states
“algorithms that determine alarm conditions should
be carefully optimized to provide, on balance, an
overall benefit to patient care” and “should be
designed to minimize the number of false negative
and false positive alarm conditions.” This latter
statement seems to mask: the necessary trade-offs
between rates of false positive and false negative
errors; experience that designers can make alarms
more sensitive, only to find user decisions become
less sensitive; and evidence that the best
sensitivity/specificity combination may vary between
users, suggesting that user-adjustable thresholds may
be advantageous, within constraints. We note that
elsewhere (Section 15.2.5 of the American HE75
standard) false alarms are addressed with a more
balanced approach, which discusses such trade-offs.
It seems dangerous that standards may be read as
reducing usability engineering to a set of design
precautions that will improve design from all
viewpoints. For instance, about different aspects of
usability itself, sometimes improving usability for
certain operations may only be achieved by reducing
it for others; e.g., putting obstacles in the way of
access to functions that change the settings of a device
may be required, for safety, so that more frequently
used features can be used quickly without
accidentally changing the settings.
The EMUSs do highlight some design trade-offs
in the interaction between usability and other system
attributes, such as safety or performance. A good
example (Section 5.1 of IEC 62366-2) is how design
for high performance in user tasks might make a
device safer, as it speeds up urgent therapy, but also
introduce hazards, if critical confirmation steps are
omitted. On the other hand, slow task performance
could “lead a well-meaning user to pass over steps in
a procedure to increase speed of the procedure. This
can result in a higher probability of use error linked
to a potentially unacceptable risk” (IEC 62366-2).
Emphasizing such relationships is important
because usability standards may be intended “to
provide a single easy-to-use source of human factors
design criteria” (Ahlstrom, 2008), separate from other
standards on, for example, safety or security;
however, considering each attribute in isolation can
lead, among other issues, to unidentified hazards.
Human Factors Standards and the Hard Human Factor Problems: Observations on Medical Usability Standards
767
The role of usability towards device safety,
mentioned for example in Section 5.1 of IEC 62366-
2, seems especially important to stress since “the
majority of medical device incident reports can
primarily be attributed to use error” (van der Peijl,
2012) but some designers may consider usability as a
secondary, almost cosmetic attribute: e.g. “keeping
users happy with a user interface”, much less critical
than e.g. “ensuring a pump delivers the correct dose”.
However, as an example, displaying dose limits on a
user interface not only “reduce[s] the burden on
users’ memory and increase[s] their confidence when
programming the pump”, but can also prevent a
harmful dose (IEC 62366-2).
EMUSs do not yet address the relationship
between usability and security, which presents a good
example of necessary trade-offs. Security has
attracted attention because the trend towards greater
integration and connectivity between medical devices
and networks brings benefits, but also security
challenges about patient safety and confidentiality. A
recent report (Francis, 2017) documents medical
devices being targeted by cybercriminals, and that
these attacks are rising. For example, blood gas
analyzers and radiology equipment were found to
offer backdoors into hospital networks allowing
attackers to send patient records to unknown locations
abroad.
HF issues with a need for trade-offs arise in user
authentication. Authentication may be needed to
prevent malicious use of a medical device (FDA,
2018). But requiring user authentication may be a
nuisance for users, especially if required often; may
delay necessary work, and, in emergencies, inhibit a
user’s ability to respond in a timely manner, thus
posing a safety hazard. User authentication in a
medical device is a good example of a many-way
trade-off that cannot be solved by focusing on a single
system attribute; a designer must consider the
interaction between safety, security, performance,
and usability.
Even for the purpose of security alone, trade-offs
arise in that stringent security policies can be self-
defeating if they reduce usability: they encourage
users to circumvent them. For example, users
required to memorise many complex passwords often
respond by sharing passwords, posting them on paper
notes, etc. (Zhang-Kennedy, 2016). These reactions
have prompted the U.S. National Institute of
Standards and Technology to reverse parts of their
previous advice on password policies (Grassi, 2017).
In conclusion, we suggest that usability be
presented as a multi-dimensional attribute, requiring
a balanced understanding of the various trade-offs
between effects of a design decision on multiple
aspects, both within usability and between usability
and other attributes including security.
3 CAUSES OF USE ERRORS AND
RISK OF TUNNEL VISION
An important, recurring term in the EMUSs is use
error, defined as “user action or lack of user action
while using the medical device that leads to a
different result than that intended by the manufacturer
or expected by the user” (IEC 62366-1). The term use
error is chosen over user error or human error to
educate designers to accept responsibility for
usability rather than blaming users: “although human
beings are imperfect, it is inappropriate to blame the
user when problems occur” (IEC 62366-2).
Removing any “blame the user” attitudes seems
indeed important for good design. But current
explanations seem to shift the blame from users to
user interface (UI) designers: this too may cause blind
spots in designers’ vision. UI design is mentioned
frequently both as cause of use errors – “much more
commonly, use errors are the direct result of poor user
interface design” (IEC 62366-1), “user interface
design shortcomings can lead to use errors” (IEC
62366-2) – and as the solution: “usability engineering
is a principle means to reduce [...] risk and improve
patient care by reducing the potential for harmful use
error through enlightened user interface design” (IEC
62366-2). Usability itself is defined as a
“characteristic of the user interface(IEC 62366-1).
We are concerned that focusing readers attention on
user interfaces may come at the cost of neglecting
other, often harder to mitigate and/or more dangerous,
problems in human factors, which we discuss next.
3.1 Beyond User Interface Design
Research and incident reports indicate that thorough
identification of use errors must consider: (1) the
users (e.g. experience, functional state, biases
towards automation), (2) the use environment (e.g.
policies, time constraints, noise), (3) the device
design (e.g., user interface, device reliability, level of
automation) and (4) the complex interactions between
these three components (e.g. automation bias, user
adaptation, complacency). User interface design is
but one player in a web of potential causes of use
error. The EMUSs do mention some non-user
interface related causes of use errors (e.g., Section
6.5.1 and Annex H in IEC 62366-2), but our concern
HEALTHINF 2020 - 13th International Conference on Health Informatics
768
is that the focus on user interface as both a cause of,
and remedy for, use errors, and the relative ease of
prescriptive solutions about it (e.g., display colours,
pitch of auditory alarms) may divert designers’
attention from warnings about non-user interface
related causes, generally not accompanied by
prescriptions. We discuss examples related to
exceptions, close to our own expertise, without any
claim to exhausting the range of problems of interest.
As an illustration of the complex interaction of
various factors to trigger a use error, consider a
scenario where a patient parameter, monitored by a
medical device, reaches a dangerously low level that
warrants immediate user action. To start with, user
action is likely influenced by whether the device
algorithm is designed to detect this danger with high
enough probability. If the device does detect this
danger, the alarm signal needs to be effectively
communicated. However, to prevent a hazardous
situation, it also matters whether, in practice, the
alarm leads to correct user action, with high enough
probability. This may depend on environmental
factors such as whether the user is busy dealing with
other, simultaneous tasks. It is also influenced by
user-related factors such as users’ mental models of
how the device works (IEC 60601-1-10). In turn,
mental models are based on users’ knowledge and
thus depend not only on training but also on users’
previous experience of interaction with the device.
There may well be a need for standards to
emphasise the role of sound user interface design, to
ensure that designers take certain precautions. But
Table 1: Various causes of specific use errors beyond shortcomings in user interface design. All quoted text is from Section
16.3 in IEC 62366-2.
Use Error
User Interface (UI)
Design Shortcomings
Other Possible Causes Not
Related to UI Design
Potential Mitigations Addressing the
Other Possible Causes
“Users fail to
detect a dangerous
increase in heart
rate because alarm
limit is set too high
and users do not
look at medical
device display
because they are
over-reliant on the
alarm system
“User-adjusted high
and low alarm limits
on a heart-rate monitor
are not continuously
displayed”
(implicit solution:
continuously display
alarm limits)
User chose inappropriate
alarm limits either due to
inexperience or in an
effort to reduce the device
alarm rate which they find
distracting
- Consider how the alarm threshold
(sensitivity/specificity combination) is set
– not just choosing a more/less sensitive
threshold, but also considering default
settings, degrees of freedom by users, and
customization according to certain
attributes such as user ability.
“User ignored a
warning label
telling the user to
disconnect the
patient tube before
turning the medical
device off”
“The medical device
did not require the user
to confirm patient
disconnection before
powering-off”
(implicit solution: add
a verification step to
confirm patient
disconnection before
powering off is
allowed)
User, at the end of a long
medical procedure, is
fatigued and overlooks the
importance of this step.
Or other devices, to which
the user is accustomed,
dictate that equipment
must be turned off before
disconnecting from the
patient.
- Add a verification step to confirm
patient disconnection before powering off
is allowed.
- Redesign the device so that the order of
these operations does not matter.
“User disregarded
a warning symbol
and allowed a
portable medical
device to run out of
battery power”
“The warning symbol
was not sufficiently
attention-getting”
(implicit solution:
make the warning
symbol more
visible/audible to
attract the user’s
attention)
Lack of reaction to an
alarm due to factors such
as “cry wolf”. In other
words, it may not be that a
user did not see/hear the
warning, but that their
experience with the device
has led them to ignore it.
- Ensure that the time between when an
alarm is emitted and when the actual
danger occurs is so chosen as not to cause
users to ignore alarms/delay action, yet
gives them enough time to react.
- During user training, raise awareness
against behaviours such as “cry wolf”.
- Consider potential unwanted interactions
between different alarms, and how to
group/prioritise alarms to reduce them.
Human Factors Standards and the Hard Human Factor Problems: Observations on Medical Usability Standards
769
designers who focus solely on the role of user
interface are likely to overlook other causes of
hazards, and thus fail to address them properly.
Table 1 helps illustrate the danger of such tunnel
vision. The first two columns describe specific use
errors and user interface design shortcomings that
may cause them. They are taken from IEC 62366-2,
with our comments added in italics. We add the third
column to illustrate other plausible, non-user
interface causes of those errors, and the fourth column
for possible remedies against these latter causes.
Table 1 is not meant to deny the role of effective user
interface design, but to help shift the focus, using
concrete examples, emphasizing that:
some use errors can result from non-UI causes,
although some of these other causes can be
remedied by the same design mitigations that
address interface design shortcomings (e.g., Row
2), some require different remedies (e.g., Rows 1
and 3). In fact, in Row 3, making the warning
symbol more attention-getting not only does not
address the “cry wolf” phenomena, but may even
exacerbate it.
mitigation strategies may extend beyond changes
to the user interface and instead address the user
or environment (e.g., Rows 1 and 3).
3.2 Potential Mitigation Strategies
It is useful for standards to mention difficult human
factors issues, but equally important is discussing
how they may be mitigated. Such mitigations may
address: (1) user characteristics (e.g., via effective
training), (2) device properties (e.g., manipulating the
level of automation, adjusting alarms to focus on
hazards that are difficult for unaided users to detect –
i.e., increasing diversity between the device and the
user), and (3) environmental factors (e.g., more
effective policies on device use such as detailing how
best to integrate a device into a user’s workflow)
.
Importantly, when considering mitigation
strategies, designers will need to consider the effect
of human adaptation to automation a critical issue
that seems to be left implicit in these standards. The
presence of automation makes people adapt their
working procedures and cognitive processes
(consciously or not) in ways that may, at times,
negatively affect their performance. For instance, a
very reliable alarm system may cause users to adapt
to completely rely on it to detect dangers, which could
result in users failing to react to dangers not alerted
by the device even dangers that they would have
tackled properly without the alarm system
(Povyakalo, 2013). We note that many adaptations,
even when unintentional, can be defended as
“rational” in that they improve some aspect of
performance, e.g. time or resources. Yet, they may
also increase the risk from use error, even compared
to the unaided user, at least for some category of
situations (the device, while possibly reducing overall
risk, could transfer risks between kinds of situations,
and possibly kinds of patients) (Povyakalo, 2013).
Testing that only incorporates a single, often first-
time, use is unlikely to reveal dangerous effects such
as complacency, overreliance, automation bias, etc.;
instead, these may only become apparent in post-
production testing and evaluation of device logs. We
suggest that it would be advantageous to encourage
such focused post-production evaluation/testing.
To illustrate the significance of human adaptation
on user decisions, consider a clinician’s mental model
of a computer-aided detection (CAD) device for
cancer. Understanding mental models is important in
addressing use errors (e.g., dealing with false prompts
based on a user’s mental model may cause a user to
miss a true prompt in an area habitually known to
have false prompts (Alberdi, 2014). The user may
start with a sceptical view of the CAD device’s
capabilities, but after interacting with the device, find
that it highlights difficult to find masses. This
interaction shapes the user’s understanding of the
device’s capabilities and is also likely to increase the
user’s trust in the device. However, even a single
error may then reverse this trust (Parasuraman, 2010),
which can be difficult to regain (Wiegmann 2002).
The EMUSs state that, “Ideally, an operator’s
mental model can be easily created through
interaction with the [device] or it can be acquired
through explanation from training or the
accompanying documents” (IEC 60601-1-10). But
non-ideal situations may exist in which a correct
mental model is hard to create and maintain. E.g.,
users may easily learn about deterministic functions
of a device from trial use of it, but be unable to
conceptualise how likely some very infrequent error
modes are. The dynamic nature of mental models also
matters: they may change over time and depend on
factors such as number and type of error committed
by the device; it may be useful to alert designers to
possible discrepancies between users’ mental models
and the true abilities of devices. E.g., a study found
that users’ explanations of how a CAD device
behaved were based on false notions of its capability
to detect breast asymmetries (Hartswood, 1997).
Such complexities may prompt designers to
choose a “simple” solution: to give users more
information regarding a device’s capabilities and
algorithms. The difficult question is: exactly how
HEALTHINF 2020 - 13th International Conference on Health Informatics
770
much information? The standards suggest, in a
similar manner to win-win examples presented in
Section 2, that “reporting the false positive and false
negative alarm condition accuracy in a standardized
format allows operators and responsible
organizations to understand the performance of
equipment” (IEC 60601-1-8). But, by the same token,
informing users of these rates can paradoxically lead
to probability matching (users agreeing with the
device at a rate equal to the device’s reliability),
which can result in decreased overall performance
(Wiegmann, 2002). Furthermore, good explanations
of device behaviour can make inaccurate device
advice more convincing and thus increase the chance
of automation bias. Providing too much information
can also lead to unnecessary complexity and
jeopardize users’ acceptance of device advice
(Alberdi, 2014). In conclusion, dealing with users’
mental models by giving users more information is
one example of the difficult trade-off decisions
inherent in the application of most mitigation
strategies for difficult human factors issues.
In concluding Section 3, we note that some of
these difficult HF issues are highlighted in the
aviation domain. The HF standard approved for use
by the Federal Aviation Administration states that
“complacency is a major concern with automation”
(HF-STD-001B). This standard also has relevant
references alerting designers to design decisions that
may promote “complacency and may cause users to
monitor automation with less vigilance”; although
focus is mostly on training users “to recognize
inappropriate uses of an automated device including
automation bias”, instead of improving by adapting
the device.
We note that in a recently proposed amendment to
IEC 60601-1-8 (not yet to be regarded as a standard,
but released for public feedback until January 2019),
new terms, such as “alarm fatigue”, “alarm flood”,
and “nuisance alarm signal”, have been added to
address some of these difficult concepts. We
welcome these recent additions, but reason that to
help designers appreciate the true danger of these
issues, the definitions need to be accompanied with
examples, explanations and potential mitigations.
4 DEFINITIONS, SCOPE AND
RISK OF BLIND SPOTS
Standards try to define precisely concepts they use
and the scope of each rule. But precise definitions
may do harm if they are inappropriate or inconsistent.
We found examples of definitions that, while they
may cause no confusion for an experienced designer
in a safety-aware company, are otherwise liable to
cause similar dangers to those discussed earlier:
missed or mis-prioritized hazards.
4.1 Conceptual Gaps from Definitions
Alarm condition is defined as: “state of the alarm
system when it has determined that a potential or
actual hazardous situation exists for which operator
awareness or response is required” (IEC 60601-1-8).
As noted directly after the definition, this suggests
that an alarm condition can be invalid (a false
positive). However, another note states that an alarm
condition may also be missed (a false negative). But
the definition implies that if the alarm system has not
detected the hazardous situation then the situation is
not an alarm condition. There is a logical
inconsistency. One could think that false negatives
can at least be attributed to an alarm signal; but this
is defined as “type of signal generated by the alarm
system to indicate the presence (or occurrence) of an
alarm condition”, thus excluding false negatives,
when an alarm signal is absent despite there being a
hazard. This could reduce attention to problems like
mode confusion due to lack of a clear alert that a
device entered fallback mode (IEC 60601-1-10); an
error type known to cause accidents.
To be sure, alarm system is defined as “parts of
[..] a medical electrical system that detect alarm
conditions and, as appropriate, generate alarm
signals”: the intended meaning must be that alarm
conditions exist in a device’s environment, rather
than inside it as in the definition of alarm condition.
We note that this inconsistency remains in the current
draft amendment to IEC 60601-1-8.
4.2 Scope: What Is “Abnormal”?
EMUSs are written to assess and mitigate risks
caused by normal use, and to help identify but not
asses or mitigate risks associated with abnormal use
(IEC 60601-1-6); “abnormal use” is defined as
“conscious, intentional act or intentional omission
[...] that is counter to or violates normal use and is
also beyond any further reasonable means of user
interface-related risk control by the manufacturer”
followed by a note that “an intended but erroneous
action that is not abnormal use is considered a type of
use error”. The standards suggest that abnormal use
can be distinguished from normal use through a post-
test interview which establishes whether “the user
understood appropriate use and made a conscious
Human Factors Standards and the Hard Human Factor Problems: Observations on Medical Usability Standards
771
decision to act (or not act) in opposition” (IEC 62366-
1). But this criterion may exclude scenarios that we
(and perhaps the authors of the standard, depending
on how one reads the complex definition) think
should be covered by risk mitigation rules.
For example, consider a device that allows users
to adjust an alarm threshold for some patient
parameters. A user that finds the device’s alarms
dangerously distracting could consciously set wider
alarm thresholds than ideal for a given patient, to
reduce the distraction from spurious alarms (IEC
60601-1-8). Such a conscious (perhaps safety-
motivated) decision is likely a result of design
choices: perhaps too high a false alarm rate (to
achieve high sensitivity), or alarms displayed in a
distracting manner. The user’s conscious,
inappropriate choice of threshold may cause a
hazardous situation where a patient whose parameters
reach a dangerous level goes unnoticed. To
complicate the scenario, such user behaviour is likely
to change over time depending on experience with the
device and factors such as trust in the device. We
think that controlling such risks should be considered
in the usability engineering process. Despite the
conscious decision to act [...] in opposition”, this
behaviour is not necessarily “beyond any additional
means of risk control by the manufacturers”; careful
consideration of the device’s alarm rate is one way
manufacturers can address this risk.
5 DISCUSSION
In our review of some medical usability standards for
difficult human factor issues (including issues such as
automation bias, complacency, human adaptation,
triggered/unmotivated user interventions, etc.), we
identified a broader set of concerns than our initial
focus implied, regarding: the complex design trade-
offs inherent in usability decisions, a focus on UI
design to the possible detriment of difficult HF issues,
and finally definitions and scope. We highlighted
potential risks but wish here to discuss the possible
challenges in addressing them.
Easy to understand and articulate use-related
hazards are not necessarily the greatest risks, and
dealing with them should not preclude mitigating
other, more obscure use-related hazards (HE75).
Many of our observations above are in the form “this
‘hard’ topic is not fully addressed” followed by “in
fairness, these standards refer to the problem in
various passages, but lack focus or do not give a
coherent warning or approach”. The “obvious”
remedy, “give as much concrete advice about these
issues as about the simpler topics may however be
difficult because:
Writing and following prescriptions about known
solutions to well-understood problems is easier
than prescribing a valid approach to complex
problems; and there is a lack of consensus
between researchers about how to address many
of these difficult HF issues.
Providing practical solutions is not trivial (such as
the dilemma whether to provide users with more
information regarding device capabilities).
Testing for these issues is difficult; it needs to
incorporate the effect of time on user behaviour,
often requiring post-production analysis, which
may be infeasible and/or expensive.
Standards need to be simple - many of these
standards are already over 100 pages, contributing
to the “usability paradox of usability standards”
(Ahlstrom, 2008) - but this is difficult to achieve
without neglecting key concepts or masking the
true complexity of issues, as we exemplified in
our discussions.
We nonetheless offer some ideas of possible
improvements for discussion. Regarding how “hard”
issues may be de-emphasised by being only raised in
terms of somewhat vague warnings, a possible
improvement could be to have sections individually
dedicated to them and to proposed solutions, so as to
add emphasis and make it easier for designers to
follow a coherent approach to these problems.
We especially noted some concerns about effects
of time and human adaptation. Possible
improvements could be:
adding to existing lists of questions that designers
should ask themselves others like: “Does the
device design encourage unnecessary
interventions that may reduce the overall benefit
of the device and/or increase the probability of
hazards?”; “Does the device help users in
situations where help is indeed useful/most
needed (i.e., is there adequate diversity between
the device and the user)?”.
highlighting the need for post-production analysis
that focuses on identifying risks introduced by
evolving user behaviour and adaptation to
devices.
The easiest problem to solve seems that of
inconsistent definitions or vague restricting
exemptions, although the latter may also be related to
contentious issues of limits to the responsibility and
liability of manufacturers.
As frequent in standards, the scientific
bibliography is rather old, and not necessarily
HEALTHINF 2020 - 13th International Conference on Health Informatics
772
because limited to authoritative or seminal papers.
This highlights the problem of separation between the
standard writing process and large sectors of the
research community that could provide scrutiny of the
scientific basis of prescriptions, if appropriate reward
mechanisms could be organised.
Certainly important to understand is how
standards shape designers’ decisions, focus their
attention, and shift their priorities. Sociological
research seems necessary. This paper is one step
towards addressing challenging human factors
concepts in medical standards.
ACKNOWLEDGEMENTS
We thank Dr. Sebastian Hunt for his insightful advice
to this work. The AQUAS project is funded by
ECSEL JU under grant agreement No 737475. This
paper is derived from an oral presentation at the
Human Factors and Ergonomics European Meeting
held in Nantes, France in October 2019, and we are
grateful for comments received from that audience.
REFERENCES
Alberdi, E., Strigini, L., Povyakalo, A. A., & Ayton, P.
(2009, September). Why are people’s decisions
sometimes worse with computer support?.
In International Conference on Computer Safety,
Reliability, and Security (pp. 18-31). Springer, Berlin,
Heidelberg.
Alberdi, E. P. A., Strigini, L., & Ayton, P. (2014). CAD:
risks and benefits for radiologists’ decision. In Samei,
E., & Krupinski, E. A. (Eds.), The handbook of medical
image perception and techniques (pp 326-330).
Cambridge University Press.
Ahlstrom, V. (2008, September). The usability paradox of
the Human Factors Standard. In Proceedings of the
Human Factors and Ergonomics Society Annual
Meeting (Vol. 52, No. 24, pp. 1994-1998). Sage CA:
Los Angeles, CA: SAGE Publications.
ANSI/AAMI. (2009). Human Factors Engineering –
Design of Medical Devices. (HE75)
FAA. (2016). U.S. Department of Transportation Federal
Aviation Administration. Human Factors Design
Standard. (HF-STD-001B).
FDA. (2018). Content of Premarket Submissions for
Management of Cybersecurity in Medical Devices.
Francis, R. (2017). Hospital devices left vulnerable, leave
patients at risk. Retrieved on June 30, 2019 from
https://www.csoonline.com/article/ 3167911/hospital-
devices-left-vulnerable-leave-patients-vulnerable.html.
Goddard, K., Roudsari, A., & Wyatt, J. C. (2014).
Automation bias: empirical results assessing
influencing factors. International journal of medical
informatics, 83(5), 368-375.
Grassi, P. A., Perlner, R. A., Newton, E. M., Regenscheid,
A. R., Burr, W. E., Richer, J. P., ... & Theofanos, M. F.
(2017). Digital Identity Guidelines: Authentication and
Lifecycle Management [including updates as of 12-01-
2017] (No. Special Publication (NIST SP)-800-63B).
Hartswood, M., Procter, R., Williams, L., Prescott, R., &
Dixon, P. (1997). Drawing the line between perception
and interpretation in computer-aided mammography.
In Proceedings of the First International Conference on
Allocation of Functions (pp. 275-291).
IEC. (2007). The International Electrotechnical
Commission. 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. (IEC 60601-1-8).
IEC. (2008). The International Electrotechnical
Commission. General Requirements for Basic Safety
and Essential Performance - Collateral Standard:
Requirements for the development of physiologic
closed-loop controllers. (IEC 60601-1-10).
IEC. (2010). The International Electrotechnical
Commission. General Requirements for Basic Safety
and Essential Performance - Collateral Standard:
Usability. (IEC 60601-1-6).
IEC. (2015). The International Electrotechnical
Commission. Application of Usability Engineering to
Medical Devices. (IEC 62366-1).
IEC. (2016). The International Electrotechnical
Commission. Guidance on the Application of Usability
Engineering to Medical Devices. (IEC 62366-2).
Parasuraman, R., & Manzey, D. H. (2010). Complacency
and bias in human use of automation: An attentional
integration. Human factors, 52(3), 381-410.
Povyakalo, A. A., Alberdi, E., Strigini, L., & Ayton, P.
(2013). How to discriminate between computer-aided
and computer-hindered decisions: a case study in
mammography. Medical Decision Making, 33(1), 98-
107.
Tsai, T. L., Fridsma, D. B., & Gatti, G. (2003). Computer
decision support as a source of interpretation error: the
case of electrocardiograms. Journal of the American
Medical Informatics Association, 10(5), 478-483.
van der Peijl, J., Klein, J., Grass, C., & Freudenthal, A.
(2012). Design for risk control: the role of usability
engineering in the management of use-related
risks. Journal of biomedical informatics, 45(4), 795-
812.
Wiegmann, D. A. (2002). Agreeing with automated
diagnostic aids: A study of users' concurrence
strategies. Human Factors, 44(1), 44-50.
Zhang-Kennedy, L., Chiasson, S., & van Oorschot, P.
(2016, June). Revisiting password rules: facilitating
human management of passwords. In 2016 APWG
symposium on electronic crime research (eCrime) (pp.
1-10). IEEE.
Human Factors Standards and the Hard Human Factor Problems: Observations on Medical Usability Standards
773