NIST GCR 15-996

Technical Basis for User Interface 

Design of Health IT 

Michael E. Wiklund

Jonathan Kendler

Limor Hochberg

UL, LLC

Matthew B. Weinger

Vanderbilt University

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.GCR.15-996
NIST GCR 15-996

Technical Basis for User Interface 

Design of Health IT

Prepared for

U.S. Department of Commerce

Information Technology Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899

By

Michael E. Wiklund

Jonathan Kendler

Limor Hochberg

UL LLC

Matthew B. Weinger

Vanderbilt University Medical Center

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.GCR.15-996

September 2015

U.S. Department of Commerce 

Penny Pritzker, Secretary

National Institute of Standards and Technology 

Willie May, Under Secretary of Commerce for Standards and Technology and Director
This publication was produced as part of contract SB1341-11-CN-0011 with the National 

Institute of Standards and Technology. The contents of this publication do not necessarily 

reflect the views or policies of the National Institute of Standards and Technology or the 

US Government. 
Technical Basis for User Interface Design of Health IT

iii

Table of Contents

1 Introduction............................................................................................................................... 1

1.1 Project details .................................................................................................................. 1

1.1.1 Goal ............................................................................................................................. 1

1.1.2 About this document.................................................................................................... 1

1.1.3 Research team ............................................................................................................ 1

1.1.4 Research and analysis activities ................................................................................. 2

1.1.5 Development activities................................................................................................. 3

1.2 EHRs, EHR users, and EHR tasks.................................................................................. 3

1.2.1 Types of EHRs............................................................................................................. 3

1.2.2 EHR users ................................................................................................................... 4

1.2.3 EHR tasks.................................................................................................................... 5

1.3 Optimizing the user experience ....................................................................................... 7

1.3.1 Ensuring use-safety..................................................................................................... 7

1.3.2 Facilitating task effectiveness...................................................................................... 7

1.3.3 Optimizing usability...................................................................................................... 8

2 User Centered Design and Evaluation Methods .................................................................... 11

2.1 Conducting user research ............................................................................................. 13

2.1.1 Determine user needs ............................................................................................... 13

2.1.2 Identify work environment characteristics.................................................................. 16

2.1.3 Define preferred workflows........................................................................................ 17

2.1.4 Determine and evaluate common workflows............................................................. 17

2.1.5 Define use scenarios ................................................................................................. 17

2.1.6 Develop user interface requirements......................................................................... 18

2.1.7 Write usability goals................................................................................................... 19

2.2 Managing use-related risk ............................................................................................. 20

2.3 Designing the user interface.......................................................................................... 28

2.3.1 Fulfill user interface design requirements.................................................................. 28

2.3.2 Re-analyze tasks and perform additional risk management ..................................... 29

2.4 Evaluating the user interface ......................................................................................... 29

2.4.1 Evaluate initial concept(s).......................................................................................... 29

2.4.2 Evaluate the preliminary user interface ..................................................................... 33

2.4.3 Verify the user interface............................................................................................. 35

2.4.4 Validate the user interface......................................................................................... 36

2.4.5 Additional details about usability testing.................................................................... 44

3 EHR User Interface Design Principles ................................................................................... 49
Technical Basis for User Interface Design of Health IT

iv

3.1 Introduction .................................................................................................................... 49

3.2 Good Design Principles ................................................................................................. 51

Accessibility ......................................................................................................................... 51

Affordances........................................................................................................................... 51

Alerts ..................................................................................................................................... 51

Buttons.................................................................................................................................. 53

Clinical decision support..................................................................................................... 53

Conceptual Model ................................................................................................................ 55

Content Organization........................................................................................................... 56

Controls................................................................................................................................. 59

Customizability..................................................................................................................... 60

Data Entry.............................................................................................................................. 62

Efficiency............................................................................................................................... 69

Error Prevention, Detection, and Recovery....................................................................... 71

Feedback............................................................................................................................... 74

External Consistency........................................................................................................... 75

Information Density.............................................................................................................. 77

Internal Consistency ............................................................................................................ 77

Language............................................................................................................................... 78

Metaphor ............................................................................................................................... 79

Miscellaneous....................................................................................................................... 79

Navigation ............................................................................................................................. 79

Patient Identification............................................................................................................ 81

Search.................................................................................................................................... 82

Security ................................................................................................................................. 83

Status Indication .................................................................................................................. 83

User Support......................................................................................................................... 83

Visual Design - Color ........................................................................................................... 85

Visual Design - General ....................................................................................................... 86

Visual Design - Graphics (i.e., icons, symbols, charts) ................................................... 88

Visual Design - Typography................................................................................................ 91

Workflow ............................................................................................................................... 92

4 Appendix A: Additional details about project activities........................................................... 95

4.1 Usability testing of EHRs ............................................................................................... 95

4.2 EHR usability scoring system ........................................................................................ 96

4.2.1 EHRUS usability scoring system development ......................................................... 98

4.3 Qualitative analysis methods....................................................................................... 101

4.4 Usability finding categories.......................................................................................... 103

4.4.1 Expert review categories ......................................................................................... 103
Technical Basis for User Interface Design of Health IT

v

4.4.2 Complete list of categories ...................................................................................... 105

5 Appendix B: EHR development best practices .................................................................... 107

5.1 Promote usability at the leadership level..................................................................... 107

5.2 Establish and maintain a diverse user base................................................................ 107

5.3 Conduct a variety of user-centered design activities................................................... 108

5.4 Conduct formative usability tests early and often........................................................ 108

5.5 Invest in professional usability expertise and encourage frequent interaction between 

usability experts and development teams................................................................................ 109

5.6 Integrate user-centered design into the development process ................................... 109

5.7 Infuse design and evaluation with clinical expertise.................................................... 109

5.8 Develop a use-related risk management process ....................................................... 110

6 Appendix C: Sample documents.......................................................................................... 111

6.1 Usability testing tasks .................................................................................................. 111

6.2 Sample cognitive task analysis.................................................................................... 113

6.2.1 Introduction .............................................................................................................. 113

6.2.2 Prescribe medication ............................................................................................... 117

6.2.3 Order procedure ...................................................................................................... 119

6.2.4 Manage problem list ................................................................................................ 121

6.2.5 Enter vital signs ....................................................................................................... 123

6.2.6 Schedule appointment............................................................................................. 125

6.3 Sample expert review findings..................................................................................... 127

Shortcoming: Placement of referral function........................................................................ 127

Shortcoming: Use of ellipses................................................................................................ 127

Strength: Allergy Alerts......................................................................................................... 128

7 Appendix D: User Profiles of 10 EHR Users ........................................................................ 129

7.1 Medical Assistant......................................................................................................... 130

7.1.1 Occupational description ......................................................................................... 130

7.1.2 Demographics (USA)............................................................................................... 131

7.1.3 Education................................................................................................................. 131

7.1.4 Electronic Health Record (EHR) Use environment(s) ............................................. 132

7.1.5 Experience using computers ................................................................................... 132

7.1.6 Sample EHR tasks................................................................................................... 133

7.1.7 Performance-shaping factors .................................................................................. 133

7.2 Medical Record and Health Information Technicians.................................................. 134

7.2.1 Occupational description ......................................................................................... 134

7.2.2 Demographics (USA)............................................................................................... 134

7.2.3 Education................................................................................................................. 135

7.2.4 Electronic Health Record (EHR) Use environment(s) ............................................. 135

7.2.5 Experience using computers ................................................................................... 136
Technical Basis for User Interface Design of Health IT

vi

7.2.6 Sample EHR tasks................................................................................................... 136

7.2.7 Performance-shaping factors .................................................................................. 137

7.3 Technologists and Technicians ................................................................................... 137

7.3.1 Occupational description ......................................................................................... 137

7.3.2 Demographics (USA)............................................................................................... 138

7.3.3 Education................................................................................................................. 138

7.3.4 Technologists........................................................................................................... 138

7.3.5 Technicians.............................................................................................................. 138

7.3.6 Licensure, certifications, and registrations .............................................................. 139

7.3.7 Electronic Records (EHR) Use environment(s)....................................................... 139

7.3.8 Experience using computers ................................................................................... 139

7.3.9 Sample EHR tasks................................................................................................... 140

7.3.10 Performance-shaping factors .............................................................................. 140

7.4 Nurse ........................................................................................................................... 141

7.4.1 Occupational description ......................................................................................... 141

7.4.2 Demographics (USA)............................................................................................... 142

7.4.3 Education................................................................................................................. 143

7.4.4 Electronic Health Record (EHR) Use Environment(s)............................................. 144

7.4.5 LPNs and LVNs ....................................................................................................... 145

7.4.6 Registered Nurses ................................................................................................... 145

7.4.7 Experience using computers ................................................................................... 146

7.4.8 Sample EHR tasks by nurses.................................................................................. 147

7.4.9 Performance-shaping factors .................................................................................. 148

7.5 Advanced Practice Registered Nurse.......................................................................... 149

7.5.1 Occupational description ......................................................................................... 149

7.5.2 Demographics (USA)............................................................................................... 150

7.5.3 Education................................................................................................................. 150

7.5.4 Electronic Health Record (EHR) Use environment(s) ............................................. 150

7.5.5 Experience using computers ................................................................................... 151

7.5.6 Representative EHR tasks....................................................................................... 151

7.5.7 Performance-shaping factors .................................................................................. 152

7.6 Physician Assistant...................................................................................................... 153

7.6.1 Occupational description ......................................................................................... 153

7.6.2 Demographics (USA)............................................................................................... 154

7.6.3 Education................................................................................................................. 154

7.6.4 Electronic Health Record (EHR) Use environment(s) ............................................. 155

7.6.5 Experience using computers ................................................................................... 155

7.6.6 Sample EHR tasks................................................................................................... 156

7.6.7 Performance-shaping factors .................................................................................. 157
Technical Basis for User Interface Design of Health IT

vii

7.7 Anesthesia Care Providers.......................................................................................... 158

7.7.1 Occupational description ......................................................................................... 158

7.7.2 Demographics (USA)............................................................................................... 158

7.7.3 Education................................................................................................................. 159

7.7.4 Electronic Health Record (EHR) Use environment(s) ............................................. 159

7.7.5 Experience using computers ................................................................................... 160

7.7.6 Sample EHR tasks................................................................................................... 160

7.7.7 Performance-shaping factors .................................................................................. 161

7.8 Physician ..................................................................................................................... 162

7.8.1 Occupational description ......................................................................................... 162

7.8.2 Demographics (USA)............................................................................................... 163

7.8.3 Education................................................................................................................. 163

7.8.4 Electronic Health Record (EHR) Use environment(s) ............................................. 164

7.8.5 Experience using computers ................................................................................... 166

7.8.6 Representative EHR tasks....................................................................................... 166

7.8.7 Performance-shaping factors .................................................................................. 167

7.9 Surgeon ....................................................................................................................... 168

7.9.1 Occupational description ......................................................................................... 168

7.9.2 Demographics (USA)............................................................................................... 169

7.9.3 Education................................................................................................................. 169

7.9.4 Practice Attributes.................................................................................................... 169

7.9.5 Electronic Health Record (EHR) Use environment(s) ............................................. 169

7.9.6 Experience using computers ................................................................................... 170

7.9.7 Representative EHR tasks....................................................................................... 171

7.9.8 Performance-shaping factors .................................................................................. 171

7.10 Pharmacist................................................................................................................... 173

7.10.1 Occupational description ..................................................................................... 173

7.10.2 Demographics (USA)........................................................................................... 173

7.10.3 Education............................................................................................................. 173

7.10.4 Electronic Health Record (EHR) Use environment(s) ......................................... 173

7.10.5 Sample EHR tasks............................................................................................... 174

7.10.6 Performance-shaping factors .............................................................................. 176

8 References ........................................................................................................................... 178
Technical Basis for User Interface Design of Health IT

viii

List of Tables

Table 1-1: User interface characteristics that can lead to user satisfaction or dissatisfaction........ 8

Table 2-1: Sample objective and subjective usability goals. ......................................................... 20

Table 2-2: Sample possible harms and use errors, which may be derived from a fault tree or 

similar analysis. ............................................................................................................................. 21

Table 2-3: Levels of probability and severity associated with use errors and their potential harms 

(adapted from ISO 14971:2007 Medical devices -- Application of risk management to medical 

devices). ........................................................................................................................................ 24

Table 2-4: Sample guidelines and their intended use-safety benefit. ........................................... 26

Table 4-1 Results of EHR usability scoring exercise..................................................................... 98

Table 4-2: Number of findings generated from each data source............................................... 102

Table 6-1: Medical assistant tasks. ............................................................................................. 111

Table 6-2: Nurse tasks. ............................................................................................................... 111

Table 6-3: Provider tasks............................................................................................................. 112

Table 6-4: Cognitive task analysis insights and resulting design solutions................................. 114

List of Figures

Figure 2-1: An illustration of a sample implementation of a user-centered design process.......... 12

Figure 2-2: Use error probability and severity matrix. ................................................................... 25

Figure 2-3: An illustration of the risk analysis and mitigation process........................................... 39

Figure 3-1: A prominent alert......................................................................................................... 52

Figure 3-2: An example of alert hierarchy. .................................................................................... 52

Figure 3-3: An example of a dose calculator................................................................................. 55

Figure 3-4: A sample patient summary that presents five groupings of related patient information.

....................................................................................................................................................... 57

Figure 3-5: Clicking on a table header sorts the table's data according to selected column. ....... 57

Figure 3-6: Samples of scrolling controls for tabular data............................................................. 58

Figure 3-7: Examples of panel and pop-up window labels............................................................ 58

Figure 3-8: Today's current parameters are highlighted with a green header and thick black 

outline. ........................................................................................................................................... 59

Figure 3-9: An example of "Reset" controls that cause the EHR to revert to its default settings.. 60

Figure 3-10: The "View more" buttons provide access to additional details; an example of 

progressive disclosure................................................................................................................... 62

Figure 3-11: An example of items presented in a vertical list (left) and in a paragraph format 

(right). ............................................................................................................................................ 62

Figure 3-12: An example of a data input validation error. ............................................................. 63

Figure 3-13: Examples of annotation. ........................................................................................... 64

Figure 3-14: Examples of selection controls (left) and text entry fields (right). ............................. 64

Figure 3-15: An example of a conventional QWERT keyboard layout (top) and a less common 

Dvorak layout (bottom). ................................................................................................................. 65

Figure 3-16: Slider controls used to toggle the alarm status and adjust its volume...................... 65
Technical Basis for User Interface Design of Health IT

ix

Figure 3-17: Examples of a well aligned field layout (left) and a haphazardly arranged layout 

(right). ............................................................................................................................................ 66

Figure 3-18: An example of well-sized fields (left) and fields that are too small to contain the 

expected information (right)........................................................................................................... 66

Figure 3-19: Sample controls for adjusting weight, height, and temperature units. ...................... 67

Figure 3-20: A sample format suggestion appearing below the Birth Date field. .......................... 67

Figure 3-21: An example of a workflow that utilizes the entered postal code to automatically fill the 

city field.......................................................................................................................................... 68

Figure 3-22: An example of type-ahead functionality that presents drug names including the 

entered characters......................................................................................................................... 69

Figure 3-23: An example of a data import progress indicator. ...................................................... 74

Figure 3-24: A sample patient overview layout. ............................................................................ 81

Figure 3-25: An example of procedural steps that give the user an indication of their progress 

through the application. ................................................................................................................. 93

Figure 6-1: Referral function located under Demographics. ....................................................... 127

Figure 6-2: Indication of allergies is subtle. ................................................................................. 128

Figure 6-3: Clicking on “...” leads to list of allergies or none....................................................... 128

Figure 6-4: Clinical reminders...................................................................................................... 128
Technical Basis for User Interface Design of Health IT

1

1 Introduction

1.1 Project details

This document presents the technical guidance from a NIST-sponsored research project titled 

“Developing a Usability Framework for Healthcare Information Technology”.

The project began in September 2010. It was funded under the American Recovery and 

Reinvestment Act of 2009. The project ended in September 2015. 

1.1.1 Goal

The project goal was to develop methods for evaluating the usability of healthcare information 

technology (HIT) and particularly electronic health records systems (EHRs). The project evolved 

to focus most intensively on EHR use-safety and the effectiveness of such applications from a 

user interaction standpoint.

1.1.2 About this document

This document’s contents are intended to help EHR developers plan and implement a usercentered design and evaluation process that ultimately leads to a safe and effective application. 

Specifically, it provides:

• Methods describing research, analysis, design, and evaluation practices intended to 

optimize EHR use-safety, effectiveness, and usability (see section 2 - User Centered

Design and Evaluation Methods).

• User interface design principles describing design strategies and practices that are likely 

to prevent common EHR design flaws and establish a basic level of interaction design 

quality in an EHR (see section 3 - EHR User Interface Design Principles).

• Descriptions of the research and evaluation activities that led to the development of this 

document (see Appendix A).

• Summaries of EHR development best practices as described by EHR developers (see 

Appendix B).

• Sample versions of EHR-related usability engineering documents, including usability test 

tasks, cognitive task analyses, expert review findings, and user profiles (see Appendix 

C).

1.1.3 Research team

UL-Wiklund’s Michael Wiklund served as the Project Director. The research team included the 

following members:
Technical Basis for User Interface Design of Health IT

2

• UL-Wiklund – Michael Wiklund, Jonathan Kendler, Limor Hochberg, Danielle Heinle, 

Kayley Wolf, Maureen Mulcare, Timothy McEwen, Robert Stephens, Celine Berger, 

Victor Versteeg, and Luis Herrera Suazo

• Vanderbilt University – Matthew B. Weinger, Jason Slagle, Carrie Reale, Shilo Anders, 

Anne Miller, and Rich Holden

• Design Science – Stephen Wilcox, Robin Littlejohn, Logan McCullar, Katie Hansbro, 

Neil Mejia, Matthew Cavanagh, Angouh Morfaw, and Dana Long

• The Ohio State University – Emily Patterson and Austin Mount-Campbell

The following individuals also contributed to the research efforts:

• Additional staff members working at UL-Wiklund, Vanderbilt University, and Design 

Science.

• Daniel Hannon, Tufts University, Director – Human Factors Engineering Program

• David Brick, Village Pediatric Cardiology, affiliated with NYU Langone Medical Center

• Bentzi Karsh, Pascale Carayon, and Tosha Wetterneck, University of Wisconsin 

• Sandra Prettyman, University of Akron

• Christine Buchanan, Tony Threat, Kevin Johnson, Joshua Peterson, Vanderbilt University

The research team is indebted to many more individuals, including EHR developers and EHR 

users, who supported the project in the following ways:

• Provided access to sample EHRs and associated training services.

• Provided access to clinical settings where EHRs were currently in use.

• Participated in surveys, observations, interviews, and usability tests.

These individuals’ names are withheld in accordance with IRB-approved research protocols and 

other terms and conditions pertaining to their participation in the research project.

1.1.4 Research and analysis activities

Each of the primary research activities focused on determining user interface design features that 

contribute to or detract from an EHR’s use-safety and effectiveness, included the following (in 

chronological order of performance):

• Survey – Conducted a Web-based survey of 559 individuals who routinely use EHRs 

installed in multiple clinical environments within a large healthcare system. 
Technical Basis for User Interface Design of Health IT

3

• Observations and interviews – Visited multiple healthcare facilities operated by two 

large, multi-hospital healthcare systems to observe and interview a total of 86 clinical, 

non-clinical and administrative staff that routinely used EHRs.

• Supporting analyses – Analyzed EHR tasks in terms of the associated cognitive 

demands and potential for harmful use errors as well as use errors that could pose a 

barrier to successful task completion (i.e., effectiveness); reviewed literature and 

conducted interviews pertaining to best practices among EHR vendors regarding usercentered approaches to application development to ensure an EHR's use-safety and 

effectiveness; and collected over 900 user interface design principles published in 

multiple sources, including national and international standards, textbooks, and websites.

• Usability tests – Conducted formative usability tests of five EHRs with 63 representative 

users, all of whom were clinicians working in patient care.

• Expert reviews – Engaged six human factors engineering experts (members of the 

research team) to review the same five EHRs evaluated in the usability tests and identify 

the applications’ user interface strengths and weaknesses (i.e., opportunities for 

improvement).

1.1.5 Development activities

The primary development activities, all focused on providing government and industry with better 

knowledge and tools for ensuring an EHR's use-safety and effectiveness, included the following:

• User profiles – Developed user profiles describing 10 common types of EHR users.

• Vendor best practices – Documented vendor best practices for implementing a usercentered approach to designing and evaluating an EHR user interface.

• Usability scoring system – Developed a prototype EHR usability scoring system for 

experimental use as an adjunct to the aforementioned usability tests of five EHRs.

• User interface principles – Wrote 343 EHR-specific user interface design principles.

• User interface design process technical document – Wrote an EHR user interface 

design process methods, based on vendor best practices, insights gained from the 

project’s research activities, and research team members’ judgment and applied design 

experience.

1.2 EHRs, EHR users, and EHR tasks

1.2.1 Types of EHRs

There are many different types of EHRs. As a result, EHR user interface design varies widely.

The variability results from many factors, including:
Technical Basis for User Interface Design of Health IT

4

• User organization type. EHRs may be developed for a variety of clinical organizations, 

including national or regional healthcare networks, individual hospitals or hospital 

systems, and private practices of varying size (e.g., large, medium, small, sole 

practitioner), thereby leading to variation in the applications’ functional capabilities. 

• Practice setting. EHRs may be designed to support outpatient, inpatient, and/or 

ambulatory settings.

• Clinical focus. Some EHRs are designed to support particular clinical specialties, such 

as dentistry, optometry, allied health professions (i.e., physical therapy), oncology, and 

anesthesiology.

• Functional focus. Whereas some EHRs provide a wide range of functions that are 

applicable to diverse uses, some EHRs focus on particular functions or features, for 

example, patient portals.

• Software platform. EHRs may be web-based (i.e., the EHR is accessible using a 

standard web browser on an internet enabled computer) or client-based (i.e., the EHR is 

accessible only on the computers on which it is installed). Increasingly, EHR developers 

are also creating EHRs that are intended for use on mobile devices (i.e., smartphones 

and tablet computers) in addition to conventional personal computers. 

• Development approach. EHRs may be developed as commercial products (i.e., 

purchased from an EHR vendor), custom-built applications (i.e., developed by an 

institution’s information technology department), or open-source applications based on 

publically available software code that is widely available for free use. 

1.2.2 EHR users

EHR users represent a wide variety of professions, clinical specialties, and demographic 

characteristics, such as the following: 

• Providers – hereafter used to refer to clinicians who most commonly prescribe 

medications, such as physicians, nurse practitioners, and physician assistants 

• Nurses – registered nurses (RNs) and licensed practical nurses (LPNs)

• Technicians – including health information technicians (i.e., data analysts) and 

laboratory technicians

• Pharmacists and supporting staff – pharmacists and pharmacy technicians

• Physicians are further subcategorized as:

o General practitioners – including internists, pediatricians, family doctors, 

gynecologists, and others who predominantly provide primary care to patients

o Surgeons – including general surgeons, trauma surgeons, neurosurgeons, and 

cardiothoracic surgeons
Technical Basis for User Interface Design of Health IT

5

o Medical specialists – including internal medical subspecialists (nephrology, 

gastroenterology), neurologists, radiologists, and anesthesiologists

o Others – including podiatrists and chiropractors

• Dentists and dental assistants

• Optometrists and ophthalmologists

• Clinical specialists in allied health professions – including physical & occupational 

therapists, respiratory therapists, speech-language pathologists, dieticians

• Administrative assistants – including office managers, case managers, and 

administrative assistants

• Billing/coding specialists 

• Medical assistants

In addition to occupation (or role), EHR users can be profiled according to many criteria,

including: 

• Demographic traits such as age, gender, ethnicity and other cultural attributes

• Education

• Experience and expertise (particularly pertaining to EHR use)

• Learning style

• Work environment (sometimes called the “use environment”)

• Common tasks (as they affect EHR use)

• Performance shaping factors (pertaining to an EHR) such as stress, workload, 

distraction, sleepiness/fatigue, etc.

EHR developers can develop user profiles (see section 2.1.1.1 – User profiles) to communicate to 

the entire development team the intended users’ demographic characteristics, clinical needs, and 

common EHR tasks. 

1.2.3 EHR tasks

EHR developers should perform detailed task analyses to identify potential use errors, some of 

which might be harmful and warrant risk control measures. Such task analyses are likely to 

produce a lengthy list of tasks, which may be complemented by task flow diagrams that depict 

discrete steps.
Technical Basis for User Interface Design of Health IT

6

EHR tasks may be divided into two broad categories:

• Administrative tasks performed primarily by administrative and support staff, including 

medical assistants.

• Clinical tasks performed by clinicians such as nurses and providers.

Common administrative tasks, as determined during the course of this research project, include: 

• Creating and updating patient records.

• Admitting, discharging, and transferring patients.

• Communicating with patients, staff, and external providers and facilities.

• Printing and faxing documents.

• Managing patient insurance information.

• Scheduling appointments.

• Managing clinicians’ schedules.

Common clinical tasks, also as determined during the course of this research project, include:

• Creating patient care plans.

• Writing clinical summaries and notes.

• Entering vital sign measurements.

• Documenting procedures, patient education, and immunization administration.

• Reviewing patient history.

• Reviewing patient clinical information, including vital signs and growth chart.

• Reviewing lab and test results.

• Managing patient problem lists.

• Ordering referrals.

• Ordering tests, labs, procedures, and immunizations.

• Ordering and modifying prescriptions.

• Reconciling patient medication lists.
Technical Basis for User Interface Design of Health IT

7

• Researching clinical conditions and treatment options.

1.3 Optimizing the user experience

1.3.1 Ensuring use-safety

The ability to deliver high quality health care is potentially closely tied to the quality of an EHR's 

user interface design. Simply stated, a poorly designed EHR can induce use errors that could 

lead to patient injury and even death. A system, if used differently than a manufacturer intended

that can lead to hazardous situations. For example, just as an intravenous infusion pump can be 

misprogrammed to deliver a morphine overdose, a user can enter the wrong medication order 

into an EHR. Therefore, as EHRs become increasingly integral to healthcare delivery, it will 

become ever more important to minimize the chance of potentially harmful use errors during their

use.

Mirroring the well-established approach to reducing risk that prevails in other industries (e.g., 

power generation, aviation, transportation, medical devices) where use errors can lead to injury to 

the user, developers should follow a user interface design process that seeks to identify 

potentially harmful use errors and decrease their likelihood of occurrence. Fortunately, a usesafety focused design process typically also increases task effectiveness, work efficiency, and

user satisfaction. 

For example, in the medical device industry, taking steps to reduce the chance of a potentially 

harmful use error is an important part of a broad-based risk management process. Such efforts 

make intuitive sense because medical devices can directly cause harm and use errors can lead 

to infection, laceration, burn, overdose, asphyxiation, and exsanguination. In such cases, risk 

reduction techniques might include placing automatically activating guards on needles, insulating 

heat sources, rounding the edges of mechanical parts, shape-coding tubes and associated ports, 

and adding pressure sensors. The contribution to safety of these design features may be 

augmented by attention-getting warnings, clearly written and illustrated instructions, and thorough

training approaches.

A structured approach to identifying potential use errors using an EHR can lead to conceptually 

equivalent protections, such as preventing orders of the wrong medication for a given patient by 

presenting prescription information in a coherent structure, including bold screen titles, using 

color to effectively highlight important information, and including helpful, non-distracting prompts. 

The user interface principles presented in section 3 – EHR User Interface Design Principles

promote the implementation of these features and many more features to reduce use-related 

risks associated with the use of EHRs.

1.3.2 Facilitating task effectiveness

The first priority is to ensure that user interactions with an EHR are safe, and the second is to 

ensure that they are effective.

An effective EHR not just enables, but also facilitates task performance. It helps various types of 

users to complete tasks easily and efficiently. As discussed in section 2.2.4 – Reduce use-related 
Technical Basis for User Interface Design of Health IT

8

risks, effectiveness may be a natural by-product of design features principally intended to ensure 

use-safety. Moreover, an effective EHR is likely to garner compliments from users about its 

usability.

Usability testing is a productive means to evaluate an EHR’s effectiveness. In a usability test, a 

representative sample of an EHR's intended users attempts to perform selected tasks. Such

tasks may be derived from meaningful use criteria. In parallel, they also can be tasks judged to be 

safety-critical, urgent, frequent, and challenging (see section 2.5.5.2 – Specifying usability test 

tasks for additional information on task selection).

If a test participant completes a task, but also commits a potentially harmful use error, the task 

should be characterized a failure. The outcome should be the same – declaration of task failure –

if there is any need for the test administrator to help the participant complete a task, because

such assistance might not be available during actual use and a use error could result.

Developers should aspire to produce EHRs with which all intended users can interact effectively, 

albeit while recognizing the near impossibility of achieving this goal. Inevitably, certain people at 

certain times will fail to complete a given EHR task, perhaps due to use errors that cannot be 

attributed to a design-related root cause. However, if a usability test reveals that several 

individuals (e.g., 3 out of 30) cannot complete selected tasks, this is a strong indication that the 

user interface needs modification. 

1.3.3 Optimizing usability

While use-safety and effectiveness are key components of an optimal user experience, another 

key component is usability, especially as it relates to user satisfaction. Satisfaction with a 

technology or software application influences users’ willingness to use the product and, when 

they do, to tolerate aspects of the user interface that do not fully meet their needs. User 

satisfaction is usually influenced by multiple, interrelated user interface design features, rather 

than just one or a few features. For example, a user might be satisfied by an EHR that has the 

following characteristics:

• Intuitiveness enabling the user to perform basic tasks without first reading instructional 

materials.

• Workflow that closely matches the conventional clinical workflow that existed before EHR 

implementation.

• Visual appeal resulting from the balanced-looking arrangement of onscreen contents, the 

use of harmonious colors, easy to interpret icons augmented by text labels, large and 

three-dimensional looking controls (i.e., buttons), and the use of blank space to separate

blocks of information.

Table 1-1 provides additional examples of user interface characteristics that can lead to user 

satisfaction or dissatisfaction.

Table 1-1: User interface characteristics that can lead to user satisfaction or dissatisfaction.
Technical Basis for User Interface Design of Health IT

9

Source of satisfaction Source of dissatisfaction

Harmonious color palette Garish screen appearance

Large, meaningful screen titles Lack of screen titles

Prompt placed in a consistent location Minimal prompts presented in varying formats

Key information summarized on a single 

screen

Key information spread across multiple 

screens

Confirmation pop-ups associated with 

irreversible actions

No means to undo an erroneous action

Information, prompts, and alerts provided in a 

context-appropriate manner and time

Alerts and prompts that interrupt user 

concentration and workflow

Note that these characteristics could have a positive influence on EHR use-safety and 

effectiveness.1 But, even if they do not, a well-designed EHR should possess these and/or 

comparable interface characteristics to foster task efficiency and user satisfaction. 

The automobile provides a fitting comparator for recognizing the value of usability. Comfortable 

seats and air conditioning might not be essential for safety and effectiveness, but both are 

important to users and likely to have a disproportionately strong influence on consumer 

preference for one car versus another. Similarly, usability is likely to have a disproportionately 

strong influence on user preference for one EHR versus another.

Accordingly, developers should consider taking the following steps to increase an EHR's usability:

• Address EHR usability concerns along with use-safety and effectiveness concerns during 

user research activities.

• Write usability-focused user interface requirements.

• Conduct benchmarking studies of competitor EHRs to better understand user 

expectations, prominent design trends, and opportunities for market differentiation

through usability improvements.

• Establish quantitative usability goals that will be upheld with the same diligence as other 

technical or software engineering goals (e.g., software response time).

• Invest user interface design effort into making an EHR visually appealing and intuitive to 

use.

• Conduct a variety of usability-related evaluations, such as expert reviews and usability 

tests.

 1 Tractinsky, N., Katz, A. S., & Ikar, D. (2000). What is beautiful is usable. Interacting with 

computers, 13(2), 127-145.
Technical Basis for User Interface Design of Health IT

10

• Iterate the design process (i.e., establish user interface requirements  design  model 

 test) to the extent necessary to ensure EHR usability.

Developers are likely to find that usability is often a natural by-product of efforts to ensure an 

EHR’s use-safety and effectiveness because an investment in user-centered design can have a 

positive influence on all three factors. However, developers might have to invest at least some 

extra effort to ensure an EHR's usability, which should pay off well in terms of higher user 

satisfaction.
Technical Basis for User Interface Design of Health IT

11

2 User Centered Design and 

Evaluation Methods

This section describes an approach to developing and validating an EHR's user interface so that 

the application is reasonably safe and effective. The intent is to promote good development 

practices without being overly prescriptive or stalling innovation. 

The need for this guidance is based on the fact that EHR development practices to date have not 

consistently considered users’ needs, particularly in the context of less than optimal conditions of 

actual clinical work. As a result, some EHRs have been vulnerable to use errors.

Some EHR functions, such as medication prescribing, are potentially, safety-critical similar to the

functions on medical devices such as defibrillators, intravenous infusion pumps, and anesthesia 

delivery machines. Even EHR functions perceived by some to be “low risk,” such as clinical 

documentation capabilities, have been shown to contribute to patient harm. For example, if a 

provider fails to document or incorrectly documents a patient’s medical condition or allergy, the 

consequences associated with subsequent care (or lack thereof) could be catastrophic. 

As such, developers should commit themselves to developing EHRs: taking a user-centered 

design approach to ensure EHR use-safety and effectiveness, as well as EHR usability and user 

satisfaction.

Note that a particular EHR user interface development effort is likely to involve parallel activities 

and iterative cycles that are difficult to describe in a linear narrative. Therefore, developers should 

consider opportunities for sequencing the steps described below in a manner that complements

other EHR development activities and proceeds in a productive and efficient manner.

Insights shared in this section are based on the following:

• Findings from research into the best practices already employed by selected EHR 

developers, including those that have developed a wide array of EHR applications to be 

sold to and implemented within diverse clinical settings, including physician’s offices,

outpatient clinics, and hospitals2

.

• Review of human factors engineering and related literature, including many guidance 

documents and standards, on best user interface design practices.

• Research team member experience conducting user research, designing user interfaces, 

and evaluating user interfaces for a multitude of products including software applications, 

 2 The authors express their gratitude to the National Center for Human Factors in Healthcare, Medstar Health, 

Washington DC., which shared the results of their own research into best user interface design practices among EHR 

developers; work they performed under contract to the Office of the National Coordinator in 2013. Some of their findings 

are also documented in the following article: Ratwani, R. M., Fairbanks, R. J., Hettinger, A. Z., & Benda, N. C. (2015). 

Electronic health record usability: analysis of the user-centered design processes of eleven electronic health record 

vendors. Journal of the American Medical Informatics Association, ocv050.
Technical Basis for User Interface Design of Health IT

12

websites, consumer products, industrial products, military equipment, power generation 

equipment, aviation equipment, and medical devices.

Figure 2-1: An illustration of a sample implementation of a user-centered design process.

The balance of this section covers the following major elements of a user-centered approach to 

designing an EHR's user interface:

• Conducting user research.
Technical Basis for User Interface Design of Health IT

13

• Managing use-related risk.

• Designing the user interface.

• Evaluating the user interface.

2.1 Conducting user research

The primary goal of user-centered design is to develop user interface design solutions that meet 

users’ needs, a key one of which is to operate the user interface safely and effectively. This goal 

can be accomplished in part by taking energetic steps to identify user needs. Even though an

EHR developer might already have (or believe it has) extensive knowledge of user needs based 

on the developer’s prior market research activities or general knowledge, some specific user 

research is usually still warranted. 

It is important to emphasize that clinicians who are employed by a developer, or are hired as 

consultants because of their special expertise, are never representative of all of the EHR's 

intended users. Thus, active research involving a cross-section of typical users is beneficial.

This subsection describes how developers can identify user needs, convert the needs into user 

interface requirements, and then use the requirements to drive the user interface design effort.

2.1.1 Determine user needs

As suggested above, a broad and deep understanding of an EHR's users’ needs is fundamental 

to designing an EHR user interface that is safe, effective and easy to use. Common and effective 

methods for developing this understanding involve (1) observing the intended users at work, and 

(2) speaking with them about their EHR-related needs and desires. 

Observation and interview methods vary in name and emphasis depending on what type of 

professionals perform the research. The possibilities include people trained in the overlapping 

fields of human factors, ethnography, interaction design, information design, marketing, 

communications, and related disciplines. For example, human factors specialists use the term

contextual inquiry when referring to interviewing people while they work. Ethnographers speak of 

performing ethnographic research as a specialized means of observing people unobtrusively to 

gain a more accurate understanding of how they work and performance-shaping factors related to 

the environment and system in which they work. Market researchers speak about conducting

interviews and focus groups to capture the voice of the customer. 

During such research activities, users might articulate their needs such as those presented below 

in hypothetical, first-person forms: 

• “I want the patient’s chart to clearly show their name, age, hospital ID number, principal 

medical condition, and maybe even a photograph for ease of recognition.”

• “I don’t like having to go to many screens to get the information I need to make a clinical 

decision. The key information should be on one screen. Stuff it in if you need to.”
Technical Basis for User Interface Design of Health IT

14

• “I need the system to check for drug interactions and grab my attention if there is a 

problem.”

The overarching point is that observing and speaking with users can generate useful insights 

regarding the qualities that will make an EHR safe, effective, usable, and satisfying. As such, best 

practices suggest that one or more development team members should conduct some form of 

user research with a heavy focus on EHR safety and effectiveness.

A critical element of any user research method is to get beyond users’ current practices (i.e., the 

tasks they currently perform with the tools they currently use) to identify their underlying work 

goals and priorities. For example, the best software products do not simply convert a paperbased form into an electronic one. Rather, by first gaining a thorough understanding of the 

underlying associated work, developers can produce electronic forms that harness the value

added by a computer to improve task safety and effectiveness, as well as usability (encapsulating 

efficiency, intuitiveness, and satisfaction). 

Further, neither interviews nor observations alone will suffice. Observations, no matter how 

extensive and detailed, in the absence of user interviews, will not reveal users’ underlying 

reasons or motivations for their actions and thus miss essential aspects of users’ real needs. On 

the other hand, relying solely on users’ descriptions of their current practices and their 

preferences for future EHRs will inevitably yield suboptimal products. Therefore, it is important to 

observe and speak to users. 

Ultimately, EHR developers should adopt a user research approach of its own choosing while 

considering the following advice:

• Extend the research to cover the widest possible range of intended EHR users, including 

primary and secondary users.

• Extend the research to cover not only common use scenarios, but also uncommon ones

(i.e., edge cases), especially if those use scenarios are safety-related.

Common deliverables for documenting user research include a prioritized list of user needs, a list 

of use scenarios (i.e., common and high risk tasks), and a description of user characteristics, 

sometimes expressed as user profiles and/or user personas, which are described below.

Research findings may be described in stand-alone documents of the research activities or 

converted directly into user interface requirements (see section 2.1.6 – Develop user interface 

requirements).
Technical Basis for User Interface Design of Health IT

15

2.1.1.1 User profiles

A user profile is a description of users who are members of a distinct user group (i.e., a sub-group 

of the overall intended user population). User profiles may be brief (e.g., 1⁄2 page) or expanded (2-

3 pages) documents. They typically cover characteristics that could have bearing on an EHR’s 

user interface design, such as the following:

• Demographic traits such as age, gender, ethnicity and other cultural attributes

• Education, experience and expertise (particularly pertaining to EHR use)

• Learning style

• Work environment

• Common tasks (as they affect EHR use)

• Performance shaping factors (pertaining to an EHR)

Performance shaping factors might include the following details3

:

• General health and mental state (stressed, relaxed, rested, tired, affected by medication 

or disease) when using the EHR

• Sensory capabilities (vision, hearing, touch)

• Coordination (manual dexterity) as it might influence onscreen navigation and data entry

• Cognitive ability and memory

• Knowledge about EHR operation and the associated functions (e.g., physician order 

entry)

• Previous experience with EHRs (particularly EHRs that serve similar purposes)

• Previous experience using software applications (including desktop, web-based, and 

mobile applications)

• Expectations about how an EHR will operate,

• Motivation

• Ability to adapt to adverse circumstances associated with EHR use (e.g., using it in an 

emergency use scenario)

 3 FDA: Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management, 3.2.2 

Medical Device Users, Page 12, Document issued on July 18, 2000.
Technical Basis for User Interface Design of Health IT

16

• Amount of cooperation with other EHR users (e.g., individual EHR use versus teambased use)

• Work pace (e.g., slow and deliberate or fast and decisive) 

Appendix D: User Profiles of 10 EHR Users support the development of user interface 

requirements that can be linked to the traits and work habits of specific user groups.

2.1.1.2 Personas

A persona is an alternative or a complement to a user profile. Typically a 1-2 page narrative, it 

describes a particular but usually hypothetical (or at least an actual but de-identified) individual 

rather than members of an overall user population. Developers may create multiple personas for 

each user group, with each persona reflecting characteristics and behavioral traits amalgamated 

from user research findings. 

Personas are often used by market researchers to describe specific types of customers. They 

often include potentially relevant personal life details (e.g., hobbies) and behavioral descriptions 

that are not normally included in a user profile. Some user interface developers prefer personas 

over user profiles because they believe that it can be more productive to design an application to 

meet the needs of selected individuals rather than the general needs associated with distinct 

types of users. They may find it easier to imagine and empathize with hypothetical individuals

rather than more general user profiles. While the comparative values of both end products are

debatable, either approach can support the development of user interface requirements. 

2.1.2 Identify work environment characteristics

A solid understanding of the environments in which people will interact with an EHR (the “use 

environments”) also provides a foundation for making good user interface design decisions. 

It is practical to study EHR users’ work environments at the same time one learns about user’s 

needs and preferences (i.e., while conducting user interviews or observations – see section 2.1.1

– Determine user needs). Insights are typically documented in the form of use environment 

descriptions; one for each significant type of use environment.

Similar to a user profile, a use environment description may be a brief (e.g., 1⁄2 page) or expanded 

(e.g., 1-3 page) description of a particular setting. Use environment descriptions discuss 

characteristics that might affect an EHR’s user interface design, such as:

• EHR placement within the use environment and expected viewing distances 

• Availability of work surfaces

• Network connectivity 

• Connected and adjacent medical devices

• Seating (affecting viewing angle)
Technical Basis for User Interface Design of Health IT

17

• Noise levels, lighting, and other environmental factors

• Sources of distraction (e.g., phone calls, patient requests)

• Concurrent tasks and activities

• Nearby personnel

• Potential for unauthorized use (e.g., by hospital visitors)

Note that an EHR might be used on a fixed workstation, such as those installed in central nursing

stations, patient rooms, and offices; on a rolling or hallway workstation; or on mobile devices 

(e.g., tablets, smartphones) that travel throughout a clinical environment.

Similar to user profiles, use environment descriptions support the development of user interface 

requirements pertaining to such factors as visual and physical access to the EHR display and 

pointing device (if not a touchscreen), and conditions and events that could interrupt interactions 

with the EHR.

2.1.3 Define preferred workflows

Whether or not people are accustomed to healthcare delivery workflows involving existing EHRs, 

they will be accustomed to particular workflows. Those workflows can vary widely in terms of 

safety, effectiveness, efficiency, and the degree to which workers consider them to be 

satisfactory. Developers should study existing workflows to determine which characteristics must 

or should be preserved in a new EHR, and most importantly, how the EHR could enhance or 

facilitate task safety, effectiveness, and efficiency.

There are ample examples of EHR's technical limitations or user interface design flaws that have 

led to undesirable changes in clinicians’ workflow. Developers should be acutely aware that 

changes to existing workflows might be disruptive and even unsafe, sometimes in unanticipated 

ways. As such, they should analyze the potential effects of all changes in workflow and proceed 

with solutions that change workflow only when there is a significant benefit to the EHR users.

2.1.4 Determine and evaluate common workflows

Developers should study existing workflows before designing an EHR, noting that an EHR will 

invariably affect future workflows to some extent. Specifically, a developer should determine how 

clinicians complete EHR-related tasks in the absence of an EHR (i.e., using paper-based records) 

and/or with a legacy EHR system.

It is common to document existing and anticipated workflows in the form of flow charts that depict 

user actions and decisions in response to computer actions.

2.1.5 Define use scenarios

In the context of EHR development, a use scenario is a description of possible interactions 

between the user and the application. Use scenario details may include:
Technical Basis for User Interface Design of Health IT

18

• Types of users involved in the use scenario

• Use environment in which the use scenario occurs

• Conditions influencing user interactions (e.g., workload, task urgency, experience using 

other EHRs)

• Tasks performed during the use scenario

Common use scenarios and their associated details can be identified by speaking with EHR 

users about how they use their current EHRs or how they currently perform tasks that will 

eventually performed using an EHR under development. Direct observations are useful in both 

identifying potential use scenarios and in confirming scenarios derived from user interviews.

Developers should identify a wide range of EHR use scenarios as an input to the user interface 

requirements development and risk management process. 

The following are summaries of a few sample use scenarios:

• Neonatologist using an EHR in a neonatal intensive care unit to order an emergency 

medication for a newborn baby.

• Medical assistant using an EHR in an outpatient clinic to schedule a patient’s follow-up 

visit.

• During shift-turnover, a registered nurse starting her shift by using an EHR in a hospital’s 

medical/surgical unit to review current medication orders for the 8 patients for whom she 

will be caring.

2.1.6 Develop user interface requirements

Just as technical requirements can drive the design of an EHR’s database structure or software 

architecture, user interface requirements can drive user interface design. Requirements can be 

derived from the following sources:

• User interface design principles, such as those found in this document and many other 

articles, websites, textbooks, and standards

• Needs expressed by prospective EHR users, documented in user research documents, 

user profiles, or personas

• Use environment characteristics that influence users interactions with the EHR, 

documented in use environment descriptions

• User interface designer judgment, informed by education, experience, and design talent

• Usability problems and use errors identified in legacy or competitor EHRs, in the 

literature, or in publically available databases
Technical Basis for User Interface Design of Health IT

19

• User interface design principles applicable to the particular operating system on which 

the EHR runs

There should be sufficient user interface requirements to address important user needs, ensure 

adequate EHR functionality, prescribe error resistant and error tolerant features, and imbue the 

final EHR with other relevant usability-related characteristics. As such, it is common for EHRs to 

have many user interface requirements, typically numbering in the dozens and perhaps 

exceeding one hundred. 

2.1.7 Write usability goals

Recognizing that they are not normally a mechanism for ensuring an EHR's use-safety, 

developers may still write usability goals that quantitatively specify the desired quality of user 

interaction with and the desired user impressions of the EHR. Usability goals can be established 

based on usability evaluations of legacy and competing EHRs, competitive market goals, or the 

developer’s aspirations for the overall quality of the EHR’s user experience. Data collected during 

usability testing efforts can then be compared to the established usability goals, enabling the 

developer to determine whether the evolving or final EHR design meets the target metrics. 

Usability goals gained favor in the 1990s and continue to be embraced by some developers as a 

means to elevate an application’s usability to the same level as other, testable quality measures. 

Meanwhile, others believe the technique can mislead developers to accept a sub-optimal level of 

application dysfunction. For example, if a developer sets the apparently high usability goal that 

90% of new users will be able to complete a task, meeting the goal would still allow that 10% of 

new users may unable to complete that task during actual use. On the other hand, setting a 

usability goal of 99% is simply not feasible since hundreds of users would need to be tested to 

assure that the goal has been attained. 

Therefore, best practice suggests limiting the use of usability goals to matters of general usability, 

efficiency, intuitiveness, and appeal, but to eschew them when it comes to matters of safety. 

Clearly, percentage-based usability goals are inappropriate for safety-related task performance 

because even a single instance of failure is cause for serious investigation and design revision. In 

contrast, time based usability goals might be valuable and provide a straightforward basis for 

performance assessment. 

In clear cases where the time to perform a task is safety critical (e.g., ordering a stat ECG), 

ensuring that an EHR meets a time-based usability goals could be an important step toward 

validating an EHR's safe use.

Typically, a complete set of usability goals includes some that are objective and thus observable 

and others that are subjective and thus require users to express their opinions. Objective usability 

goals are often based on the time taken to perform a selected task or the rate at which new users 

are able to complete a selected task successfully. Subjective usability goals call upon individuals 

who have used an application to express their opinion about it, typically using a rating scale.

Table 2-1 presents a sample of objective and subjective goals pertaining only to an EHR's 

usability.
Technical Basis for User Interface Design of Health IT

20

Table 2-1: Sample objective and subjective usability goals.

Objective usability goal Subjective usability goals

85% of new users shall successfully log into 

the EHR on their first attempt.

On average, new users shall rate the EHR’s 

ease-of-use as 4.5 or better (scale: 1 = poor, 

7 = excellent)

90% of new users shall be able to load a 

patient’s chart within 30 seconds or less. 

On average, new users shall rate the patient 

chart’s readability as 5 or better (scale: 1 = 

poor, 7 = excellent)

75% of new users shall be able to enter a 

patient’s vital signs in 5 minutes or less.

On average, new users shall rate the EHR’s 

intuitiveness as 3.5 or better (scale: 1 = poor, 

7 = excellent)

Developers have the prerogative to make the success criteria for each goal (e.g., target task time 

for an objective goal, target average rating for a subjective goal) based on their ambitions for the 

EHR’s interaction quality. Ideally, the set criteria should be based on user research or usability 

testing results (e.g., average task times collected from a usability test of a legacy or competitor’s 

EHR). 

2.2 Managing use-related risk

Another goal of user-centered design is to develop user interface solutions that are less 

vulnerable to potentially harmful use errors. This goal can be accomplished by taking the 

necessary steps to understand how EHR users might err and either preventing such occurrences 

altogether or mitigating their negative effect. This process is called use-related risk management. 

In summary, use-related risk management involves identifying hazards and associated use 

errors, estimating the risk associated with the use errors, and reducing the risk of use errors that 

could cause significant harm. The requisite risk management steps are described below.

2.2.1 Identify hazards and associated use errors (top-down approach)

One might normally think about hazards as physical things that can cause harm. In clinical 

environments, for example, use of medical devices can introduce hazards such as an unguarded 

needle, energized electrode, leaking blood tubing, or unshielded radiation beam. Each of these 

hazards could cause harm to a patient or a clinician. In this case, to address these risks of harm, 

device developers are compelled to identify hazards associated with the use of their devices and 

to implement protections against use errors that could expose users to hazards (i.e., create 

hazardous situations) and lead to harm. The implementation of risk control (i.e., reduction) 

measures is often termed risk mitigation. The “top down” approach described here (starting with 

identification of possible hazards and the harms they can cause, and then analyzing how use of 

the product could lead to such harms, is typically called a use-related hazard analysis.

For example, in contrast to therapeutic medical devices such as infusion pumps, a use error 

committed with an EHR cannot harm a patient directly. However, EHR users can commit use 
Technical Basis for User Interface Design of Health IT

21

errors that create hazardous situations whereby the actions or inactions resulting from EHR use 

can be injurious or even deadly. Therefore, it is incumbent on EHR developers to identify 

potential hazards, just as would the developer of nuclear radiation delivery software, dialysis 

machine, or anesthesia workstation.

Table 2-2 presents sample use errors and possible harms.

Table 2-2: Sample possible harms and use errors, which may be derived from a fault tree or 

similar analysis.

Possible harms Use errors

Intended patient does not receive treatment, 

resulting in a range of possible harms ranging 

from suboptimal disease management to 

death

Incorrect patient receives unnecessary 

procedure, resulting in a range of possible 

harms ranging from temporary and/or mild 

discomfort to permanent injury or death

Ordered procedure for the wrong patient

Delay in diagnosis or suboptimal disease 

management due to additional time required 

to recognize wrong test order and re-order 

correct test

False positive diagnosis based on test results 

of wrong test, resulting in unnecessary 

treatment 

Ordered wrong test

Patient is subsequently (re)prescribed that 

medication, resulting in a deadly allergic 

reaction 

Stopped a medication to which a patient had 

an allergic reaction but did not add medication 

to the patient’s allergy list 

Delay in follow-up care for intended patient, 

resulting in suboptimal disease management.

Scheduled appointment for wrong patient

Patient receives unnecessary medication, 

resulting in anything from mild discomfort to 

deadly allergic reaction 

Ordered an unnecessary medication

Patient does not receive influenza vaccination 

and contracts a form of influenza, resulting in 

a life-threatening pulmonary infection

Documented that an influenza vaccine had 

been administered without actually ordering 

(or administering) the vaccine

Patient does not receive the diagnostic test, 

resulting in delayed detection of a critical 

diagnosis (e.g., breast cancer) thereby 

appreciably worsening prognosis

Overlooked clinical reminder and failed to 

order a diagnostic screening test (e.g., a 

mammogram)
Technical Basis for User Interface Design of Health IT

22

Risk analysts should consider how user interactions with the EHR could expose people to the 

following types of hazards:

• Biological / clinical (including both over- and under-diagnosis or treatment)

• Chemical (including medications)

• Electrical

• Mechanical (i.e., physical injury)

• Psychological / emotional

• Radioactive

Once hazards are identified, developers should determine all of the possible use errors that could 

lead to exposure of the patient (or even provider or bystanders) to one or more hazardous 

situations. Fault tree analysis is a common way to determine use errors that could expose the 

user to a hazard and potential harm. The technique calls for analysts to start with a harm and 

then work backwards to determine what event or series of events, including one or more use 

errors, can lead to the harm.

2.2.2 Identify potential use errors and associated hazardous scenarios (bottom-up 

approach)

In addition to taking the top-down approach of identifying hazards and linking them to use errors 

that can lead to exposure, developers can take a bottom-up approach that calls for identifying 

potential use errors and then determining what harm the errors could cause. This process is often 

termed a use-related failure modes and effects analysis.

The first step in this approach is to perform a task analysis, defining each step users will take to 

complete particular tasks with the software. This poses a significant challenge when an EHR’s 

user interface design is incomplete or perhaps not substantially advanced beyond an initial 

concept. In such cases, the analysis will be more speculative, but the results can actually guide 

the ensuing design effort. When there is already a preliminary user interface design, or a new 

version will be heavily based on a previous version (i.e., share many of the predecessor’s 

characteristics), the task of tracing the interactive steps involved in the selected tasks is relatively 

straightforward. 

A user-EHR interaction can be deconstructed into one or more of the following elements:

• Perception – acquisition of information (e.g., reading a growth chart) 

• Cognition – mental processing of the information (e.g., deciding if a child is growing at a 

healthy pace and what to do if this is not the case)

• Action – taking action (e.g., ordering a diagnostic test or a medication)
Technical Basis for User Interface Design of Health IT

23

Deconstructing tasks into these categories constitutes a PCA analysis (the acronym PCA stands

for Perception-Cognition-Action). EHR developers are encouraged to perform a PCA analysis to 

identify potential use errors, noting that one can generate a large set of potential use errors by 

exploring the range of perceptual errors (e.g., not noticing an on-screen alert), cognitive errors 

(e.g., incorrectly recalling a vital sign value), and action errors (e.g., clicking on the wrong patient 

name). 

A PCA-type analysis is likely to generate hundreds of potential use errors. While many such 

errors are unlikely to be hazardous, some might lead to harm. A risk analysis should be 

performed to identify those posing significant risk.

2.2.3 Determine risks associated with use errors

The dominant form of use-related risk analysis calls for developers to use numerical rating scales 

to characterize both the probability (i.e., likelihood) of a use error, and the severity of the harm 

that can arise due to that use error. The resulting risk estimation for each use error is derived 

from the product of the probability and severity ratings. 

Commonly used rating scales and a risk estimation matrix are shown in Table 2-3 and Figure 2-2. 

Using these ratings scales, a developer might estimate the probability of a particular use error to 

be a 3 (Occasional) and the severity of the harm it might cause as a 4 (Critical), resulting in a risk 

of 12 (3 x 4). According to the sample risk estimation matrix, the use error falls in the highest part 

of the yellow zone, suggesting the need to decrease the risk through user interface redesign or 

other risk mitigations.
Technical Basis for User Interface Design of Health IT

24

Table 2-3: Levels of probability and severity associated with use errors and their potential harms

(adapted from ISO 14971:2007 Medical devices -- Application of risk management to medical 

devices).

Severity Probability (i.e., Likelihood)

5 – Catastrophic

Results in patient death.

5 – Frequent

Likelihood of occurrence is greater than or 

equal to 10−3.

4 – Critical

Results in permanent impairment or lifethreatening injury.

4 – Probable

Likelihood of occurrence is less than 10−2 and 

more than 10−4.

3 – Serious

Results in injury or impairment requiring 

professional medical intervention.

3 – Occasional 

Likelihood of occurrence is less than 10−4 and 

greater than 10−5.

2 – Minor

Results in temporary injury or impairment not 

requiring professional medical intervention.

2 – Remote

Likelihood of occurrence is less than 10−5 and 

greater than 10−6

.

1 – Negligible

Inconvenience or temporary discomfort.

1 – Improbable

Likelihood of occurrence is less than 10−6.
Technical Basis for User Interface Design of Health IT

25

Figure 2-2: Use error probability and severity matrix.

Depending on a developer’s risk management philosophy, it may explore ways to reduce all risks 

that start in the red and yellow zone, ideally dropping them into the green zone or lower region of 

the yellow zone. For example, in the medical device industry, manufacturers normally view risks 

in the red zone as unacceptable and mandating risk reduction, while risks in the yellow zone as 

warranting an exploration of opportunities to reduce risk through various strategies.

For example, medical device developers refer to ISO 14971: Medical devices -- Application of risk 

management to medical devices, for conceptual and detailed guidance on how to approach a risk 

analysis properly. While there is an ongoing effort to develop a national risk management 

standard for EHR development, in the interim, EHR developers should refer to ISO 14971 as well 

as existing national and international standards software risk management. 

In practice, it is quite difficult to accurately estimate the probability of a use error occurring. For 

example, there is little basis for estimating the chance that a user will not detect an onscreen 

alert. Developers can review field experience with predecessor products to help estimate 

probabilities, but reliable use error reporting is uncommon, which undermines the integrity of the 

analysis. Therefore, probability estimates usually are educated guesses that could be wrong by 

an order of magnitude. As a result, the emerging trend in high-risk industries (for example, 

including medical device industry) is to focus more on severity of harm when deciding if there is a 

need for risk reduction measures. For example, using the rating scale presented above, a 

conservative approach would be to explore ways to eliminate the risk of any use error that has a 

severity rating of 3 (Serious) or above. 
Technical Basis for User Interface Design of Health IT

26

Other factors that play a role in risk management are the detectability of a use error and the 

ability of the user to correct the error if he or she detects it. Thus, developers may choose to 

factor these variables into their risk analyses. In such a scheme, for example, low use error 

detectability would increase risk, and high use error detectability would reduce risk. These factors 

also present opportunities for risk mitigation. For example, a user interface could be redesigned 

to make a use error more apparent and, therefore, more recoverable due to its timely detection. 

2.2.4 Reduce use-related risks

When the likelihood of a user committing a use error is high and the resulting harm can be 

severe, the risk must be reduced to a level that the developer’s risk management process 

stipulates is an acceptable level. EHR developers have little, if any, control over the severity of 

the harm that can result from an EHR use error, such as overdosing a patient, because the harm 

is a matter of biology rather than technology.

Therefore, EHR risk control measures focus on reducing or eliminating the chance of a use error 

occurring, or providing means to detect and recover from the error before it causes harm. 

Applying the user interface design principles presented in EHR User Interface Design Principles

is one way to reduce the risk of use error occurrence. 

Table 2-4 lists several sample principles and their intended use-safety benefit. 

Table 2-4: Sample principles and their intended use-safety benefit.

Guideline Intended use-safety benefit 

Persistently display and highlight important 

patient information, such as disease 

mechanisms, current medications, and 

allergies, on patient information displays. 

Information may be presented in a persistent 

header, “dashboard,” “whiteboard” or similar 

user interface element that contains the key 

information. Do not permit the patient name to 

become hidden due to paging or scrolling, for 

example.

Reduce the chance that a user will place a 

medication order for the wrong patient

Present users with options that are 

operational mode-appropriate. For example, 

when prescribing medication to a pediatric 

patient, present medication dose options that 

are appropriate to children rather than adults.

Reduce the chance that a clinician will enter a 

pediatric patient’s weight using the wrong 

units of measure
Technical Basis for User Interface Design of Health IT

27

Guideline Intended use-safety benefit 

Provide users with a direct means to perform 

emergency tasks, rather than requiring them 

to first perform non-essential tasks. Relatively 

low importance and non-urgent steps could 

cause an undesirable delay that could lead to 

patient harm. For example, enable 

appropriate users to order an emergency 

medication (e.g., tissue plasminogen activator 

(t-PA) for ischemic stroke) without having to 

complete a patient admission form ahead of 

time.

Reduce the chance that there will be a delay 

in delivering therapy to a new EHR patient 

with an acute stroke who has not yet been 

“admitted” in the system

The principles provided in section 3.2 – Principles can serve as a good general starting point for 

identifying mitigations. However, certain risks will likely require developers to develop specific, 

custom mitigations based on the developed EHRs distinct design.

To produce a reasonably safe EHR, developers must be prepared to modify an EHR's user 

interface in response to evidence and expert judgments that certain user interface aspects are 

leading to potentially harmful use errors. Human factors experts describe a hierarchy of risk 

mitigations where the most effective (and often the most effortful) is to redesign the user interface 

to eliminate the potential of use error. Often, effective but somewhat less reliable risk mitigation 

strategies include making the correct actions more obvious by providing cues (i.e., affordances), 

making the error less likely through preventative measures (i.e., constraints), or making the use 

error or its consequences more detectable. Generally, warnings, alerts, and instructions that 

essentially inform the user to “be careful” or “avoid making this error” are much less effective 

mitigations.

For example, experience in the medical device industry suggests that, in the interest of 

minimizing disruption to a product development effort, some developers eschew significant 

changes by defining a user interface designs as “frozen” (i.e., not subject to change) ahead of a 

final user test of the device. Instead, they favor changes to user documentation, product labeling,

or user training in response to suboptimal test results. However, modifications to documentation 

and training are generally considered weak risk mitigations as compared to user interface design 

modifications. For example, it is more effective to require users to confirm an important parameter 

setting, rather than place an advisory in the user manual for users to double-check settings.

As discussed in section 2.4 – Evaluating the user interface, developers can conduct usability 

tests to evaluate the effectiveness of chosen risk reduction measures. If the risk mitigations are 

effective, users will be able to complete tasks without committing safety-related use errors. If 

even one user still makes a safety-relevant use error despite the mitigation(s), then different or 

additional risk control measures are warranted.
Technical Basis for User Interface Design of Health IT

28

2.3 Designing the user interface

A comprehensive description of an EHR user interface design process is outside the scope of this 

document. Otherwise, this document would devolve into a lengthy discussion of such topics as:

• Exploring a range of conceptual models that best satisfy the EHR's function requirement 

and user interface requirements, and foster the formation of simple and accurate mental 

models among users.

• Considering a range of user interface structures that reinforce a simple and accurate 

mental model, provide rapid access to frequently used as well as important functions, and 

afford a logical and desirable workflow.

• Developing multiple visual design solutions that emphasize the right information and 

controls while also addressing aesthetic goals.

• Converging on a user interface design solution that combines the strongest conceptual 

model, user interface structure and visual design solutions.

Important steps:

1) Ensure that user interface requirements drive the design, rather than letting technical software 

requirements and programmers’ personal judgments override the user needs expressed in the 

form of user interface requirements.

2) Repeatedly evaluate the design-in-progress to determine if there are any new opportunities for 

use error that should be a new input to the risk management process. For example, it may be 

quite productive to evaluate a design near the completion of the following stages of development:

• Conceptual design – which might be represented in the form of several sample screens

(e.g., wireframes) and a user interface structure diagram.

• Preliminary design – which might be represented by a medium-fidelity, interactive 

prototype of selected portions of the application.

• Detailed design – which might be represented by a high-fidelity, interactive prototype of 

most portions of the application.

• Final (production-equivalent) design – which should be represented by a fully 

functional (i.e., production-equivalent, ready for release) version of the EHR, including the 

supporting learning aids.

2.3.1 Fulfill user interface design requirements

As suggested above, the user interface design effort should be driven by the user interface 

requirements that, in turn, are based on user needs and preferences as well as risk management 

efforts. In practice, this means that user interface designers should be held accountable for 

meeting the user interface requirements as opposed to designing the user interface according to 
Technical Basis for User Interface Design of Health IT

29

team members’ strictly personal judgments and/or programming expedience. Approached 

properly, meeting user interface requirements should not be an obstacle to innovation. Rather, 

taking a disciplined approach to user interface design might actually reveal innovation 

opportunities.

2.3.2 Re-analyze tasks and perform additional risk management

As an EHR's user interface evolves and becomes more complete, it enables a more detailed 

tasks analysis. Instead of speculating about how users will perform tasks as a basis for identifying 

potential use errors, risk analysts can perform increasingly specific and accurate task analyses. 

This results in a more accurate and comprehensive set of potential use errors, although the 

results should substantially overlap with results of the initial analysis. Updated task analysis 

results – specifically the updated list of potential use errors – should be an input to a continuing 

risk management effort.

2.4 Evaluating the user interface

2.4.1 Evaluate initial concept(s)

There are several ways to evaluate a user interface design in the early stage of its development. 

A couple common approaches are detailed below.

2.4.1.1 Conduct expert review

An expert review is a productive way to identify an EHR’s user interface design strengths and 

opportunities for improvement at various stages of its development. For example, experts can 

evaluate an EHR when it is at the concept development stage and expressed in the form of 

sample screens comprising one or just a few important workflows. They can evaluate an early 

interactive prototype that includes only certain functions. And, they can evaluate more complete 

prototypes as well as finished products, the latter for the purpose of identifying opportunities to 

produce an improved, next-generation version of an EHR already in use. Additionally, developers 

can engage expert reviewers in an extended dialogue regarding a particular finding or comment, 

whereas it might be difficult or impractical to obtain additional feedback from usability test 

participants who have limited time to spend in an EHR evaluation. Therefore, it might be 

advantageous for an EHR developer to initiate two, three, or even more expert reviews over the 

course of a development effort, noting that such reviews can be completed quickly and at 

relatively low cost. 

An expert review can be a valuable complement to formative usability testing (see section 2.4.1.1

– Conduct expert review) because it can generate different types of findings over a wider range of 

time that might arise from an analysis of test data. However, developers should not consider 

expert reviews to be a complete substitute for formative usability testing because certain design 

strengths and opportunities for improvement become evident only when actual users perform 

representative tasks with an EHR. 

An expert review calls for one or more experts to inspect an EHR and state opinions about its 

interactive qualities, including the good and bad. Participating experts need not pass a qualifying 
Technical Basis for User Interface Design of Health IT

30

test of their knowledge and judgment in the same manner as a pilot who must be certified to fly a 

particular airliner. Rather, the standard of care for selecting experts is up to the developer; it is a 

judgment call. 

Still, certification as a human factors professional holding a degree in a user interface designrelated field and similar credentials are certainly hallmarks of a genuine expert. A degree of 

objectivity is advantageous as well, which is why it makes little sense for members of the 

development team to conduct their own expert reviews. For this reason, developers often turn to 

outside consultants, or at least co-workers who are not members of the particular EHR 

development team, to conduct such reviews.

Ultimately, the productivity of a particular review depends on the selected expert(s) to possess a 

suitable base of knowledge and experience in such areas as, but not limited to, the following:

• User interface design and its variants (e.g., user experience design, interaction design, 

user interface architecture)

• Human factors engineering (aka usability engineering)

• Human-computer interaction

• Visual design

• Clinical domain knowledge (i.e., clinical terms, tasks, and overall workflows)

An expert review is a flexible process, one that is usually shaped by a reviewer’s or review team 

members’ preferred practices, which may include the following activities:

• Develop a first impression by exploring the EHR and attempting to perform tasks 

before getting a complete introduction to the EHR through briefings, training, and 

readings.

• Learn about the EHR's intended uses, users, and the environments in which the 

EHR will be used.

• Review user interface design goals with the development team.

• Participate in training, most likely of a condensed form but possibly in its fullest form, to 

use the EHR. Alternatively, observe all or a portion of an actual training session.

• Scan or read in full the EHR learning aids.

• Establish a set of general (i.e., global) and specific (i.e., local) user interface design 

topics upon which the review will focus. The set of topics could mirror the ones that 

guided the expert review that the research team performed on five EHRs (see section

4.4.1 – Expert review categories), or an alternative set that may be assembled based on 

the reviewers’ judgment.
Technical Basis for User Interface Design of Health IT

31

• Document user interface design strengths and opportunities for improvement (i.e., 

weaknesses, shortcomings). The term “opportunities for improvement” is preferable 

because it is a more constructive expression that is aligned with the end-goal of 

producing an optimal EHR user interface. 

Optionally, provide recommendations pertaining to the opportunities for improvement. Such 

recommendations may be narrative and/or graphical depending on the topic at hand. They may 

vary in specificity based on the vendor’s needs, the reviewers’ user interface design expertise, 

and the development stage at which the review is conducted.

Expert review findings are typically presented in slideshow or narrative document formats. 

Slideshow presentations dedicate slides to general and specific topics, each one including an 

illustration of the user interface element(s) of note, if applicable, a brief description of the strength 

or opportunity for improvement, and a recommendation for improvement where warranted (see

section 6.2 – Sample expert review findings). Narrative documents contain the same basic 

content but might include somewhat lengthier discussions of particular findings. 

The most productive expert reviews typically employ a formal process that ensures 

comprehensive coverage of the topics of interest. The review should be presented to the 

development team such that individual findings evoke a constructive response rather than neglect 

or outright dismissal. Measures to ensure that the expert review findings have a positive influence 

on an EHR in development or subject to updating include the following:

• Draw upon the expert review results to update the use-related risk assessment. For 

example, review the expert review results to determine if they have identified additional 

use errors warranting risk analysis, or suggest modifications to prior estimates of a use 

error’s probability (i.e., likelihood) and the severity of the harm(s) that could arise.

• Add the expert review findings – particularly opportunities for improvement linked to user 

interface design shortcomings – into a tracking system that assures they will be 

addressed in some manner, which could include implementing a design change or 

deciding to keep the design as is. This approach to dealing with expert review findings is 

akin to how software developers normally track programming “bugs,” ensuring that highpriority bugs are fixed before the application’s release.

A heuristic analysis is a type of expert review that serves the same basic purpose, but is worth 

discussion given that it is widely used among software developers. The technique calls for 

multiple reviewers – typically two to three – to conduct independent reviews according to a 

common set of evaluation criteria (i.e., design principles such as those presented in section 3 –

EHR User Interface Design Priniciples). After independently developing a list of problems, the 

reviewers discuss and reach a consensus regarding the problems and their severity according to 

applicable criteria such as use-safety, task completion, and usability. In principle, adding more 

experts is likely to identify a greater proportion of the existing design problems. As such, heuristic 

analysis is a more rule-based approach to conducting an expert review, which might or might not 

pay dividends in terms of the end-product’s quality. Notably, a heuristic analysis is normally 

focused on problems as opposed to design strengths. This approach makes it best suited to the 

evaluation of well-developed user interfaces when the goal is to perfect them, whereas an expert 
Technical Basis for User Interface Design of Health IT

32

review that also focuses on design strengths may be more helpful at an earlier stage of 

application development.

2.4.1.2 Conduct cognitive walkthrough

It might be impractical to conduct a usability test of a user interface design at the early stage of its 

development when the EHR might not be functional enough to support such testing. In place of a 

usability test, developers may engage prospective EHR users in a cognitive walkthrough. 

Whereas a formative usability test calls for representative users to interact with a working 

prototype of an EHR, a cognitive walkthrough requires only static screens, complemented by 

supporting explanations by the walkthrough administrator (i.e., the administrator “fills in the 

blanks” left by a lack of design detail and dynamic behavior). 

The term walkthrough, just as it is used describe certain types of rehearsals, delineates the 

process of stepping through a series of activities – a workflow – without actually performing the 

activities. Participants in an EHR cognitive walkthrough would view certain screens and share 

their impressions of them. They would also describe how they might act if interacting with a 

working EHR and discuss the underlying thought processes pertaining to each step of a task 

(e.g., considering options, performing mental calculations, arriving at decisions).

The EHR conceptual design stage is a good time to conduct a cognitive walkthrough, presuming 

that the application’s user interface is instantiated in the form of static screens only, or perhaps 

only marginally interactive prototype. Otherwise, it would be more productive to conduct a

formative usability test.

A good sample size for a cognitive walkthrough is the same as a formative usability test of an 

early prototype – perhaps 5-10 individuals. However, the variety of EHR users might warrant a 

larger sample, albeit one that includes only a few representatives of each type of user. 

The technical steps are similar to a formative test as well (see section 2.5.2.1 – Conduct 

formative usability test). In brief, they may include:

• Determine cognitive walkthrough goals.

• Develop cognitive walkthrough plan.

• Recruit the participants.

• Conduct the cognitive walkthrough sessions.

• Consolidate and analyze the data.

• Document the results.

In practice, cognitive walkthroughs are often conducted in a casual manner as compared to 

formative usability tests and certainly as compared to a summative usability test. In place of a test 

plan, the research team may prepare a general guide or even base their efforts on some notes. In 
Technical Basis for User Interface Design of Health IT

33

place of recruiting participants from outside the development organization, insiders who have no 

prior knowledge of the EHR under development may serve as participants (although recruiting 

outsiders might still be best practice). As compared to usability tests, walkthroughs can be 

conducted by a single researcher more readily. However, a two-person research team might still 

be warranted if the walkthrough covers a significant amount of ground. In place of a document, 

the research team might choose to write a concise memo to document the results. Alternatively, 

the team might choose to convey the study findings in a briefing, capturing the major points in 

meeting notes. 

A conceptual walkthrough should be a helpful, convenient exercise rather than a burden to the 

development process. Still, similar to the way developers should track expert review findings, 

developers should incorporate the findings from a cognitive walkthrough into the risk 

management and design optimization efforts. 

2.4.2 Evaluate the preliminary user interface

When an EHR's user interface has evolved beyond the concept stage and a functional prototype 

is available, an expert review might still be in order. An expert review takes relatively little time 

and can be very productive. However, a functional prototype enables a usability test, which is 

generally considered the optimal way to evaluate a software user interface because it can reveal 

problems that might go undetected in an expert review. When testing involves a design in 

formation, it is commonly called a formative usability test. This technique is described below.

2.4.2.1 Conduct formative usability test

Formative usability testing calls for prospective users to perform hands-on tasks with a prototype 

EHR. As suggested above, the prototype may be fully or partly functional. Indeed, while some 

portions of the user interface might be quite refined, others might be static or missing altogether. 

The point is to invite prospective users to interact with the EHR at its early stage of development,

when design and software changes are relatively easy to implement, and then at subsequent 

stages of its development to ensure the design is on the right path toward a successful validation 

(see section 2.5.4 – Validate the user interface).

Human factors research suggests that even small-scale formative usability tests, involving as few 

as 5-10 prospective users, generate valuable results. Therefore, it is advisable to conduct 

multiple small-scale formative usability tests at various points in the development process, rather 

than one large one at a single point in the development process. Metaphorically speaking, 

developers are better served by taking the EHR out for many short test drives rather than one 

long one.

Formative usability test characteristics usually have the following characteristics:

• Test participants represent the intended users. Ideally but with practical exceptions, test 

participants should not be development organization employees, even if they might have 

previously served in a role matching that of an intended user (i.e., as a clinician). Rather, 

participants should be recruited from the organizations that might use the EHR in the 

future, such as nurses working in large medical practices.
Technical Basis for User Interface Design of Health IT

34

• Testing is guided by a plan (i.e., protocol) that describes the test goal, test method, test 

participants, state of EHR development (i.e., the prototype’s functional and visual fidelity), 

hands-on tasks, and data to be collected data. NIST provides a sample usability test plan 

on its website.

4

• Test participants may think aloud while interacting with the prototype EHR so that testing

personnel can understand the participants’ thought processes and identify the root 

causes of interaction problems that arise.

• Testing reveals the following types of usability-related events, which will indicate where 

the EHR user interface might require modification to ensure its safe, effective, and 

satisfying use:

o Use errors – in which a participant uses the EHR in a manner that does not 

match its intended use and/or could lead to patient injury.

o Close calls – in which a participant almost commits a use error or avoids a use 

error by relying on her/his vigilance (as opposed to guidance provided by the 

user interface).

o Difficulties – in which participants struggle to complete a particular task.

• Testing presents multiple opportunities to collect the test participants’ opinions about 

EHR features they like and dislike, thereby identifying opportunities for design 

improvement.

 4 Schumacher, R. M., & Lowry, S. Z. (2010). NIST guide to the processes approach for improving 

the usability of electronic health records. National Institute of Standards and Technology.
Technical Basis for User Interface Design of Health IT

35

• Test findings are documented in a document that may include design recommendations. 

NIST advises that documents include the following contents:5

Executive summary 

Introduction 

Method 

Participants 

Study design 

Procedure 

Test location 

Test environment 

Test forms and tools 

Participant instructions 

Usability metrics 

Results 

Data analysis and documenting 

Discussion of the findings 

Appendices 

Sample recruiting screener 

Participant demographics 

Non-disclosure agreement and informed consent form

Example moderator’s guide 

System usability scale questionnaire (if used)

Incentive receipt and acknowledgment form 

2.4.3 Verify the user interface 

Developers can ensure that EHRs fulfill user interface requirements by verifying a final user 

interface design. Verification is a matching exercise, often performed and documented using a 

spreadsheet or other requirements tracking application, that seeks to ensure that there is a 

design feature or behavior to match each user interface requirement. The exercise serves to 

ensure that no user interface requirement has been overlooked and/or unmet.

For example, in FDA’s parlance regarding medical devices, verification calls for developers to 

confirm that there is a design output (i.e., user interface design feature or behavior) to match 

each design input (i.e., user interface design requirement). If there is a requirement is to place a 

meaningful title at the top of every window and major grouping, verification calls for the inspection 

of every EHR window and major grouping to ensure that such titles are present.

An EHR's user interface may be considered verified when all user interface requirements have 

been met by the final (i.e., production-equivalent) user interface design.

 5 Schumacher, R., Lowry, S. NISTIR 7742: Customized Common Industry Format Template for Electronic 

Health Record Usability Testing. 15-November 2010.
Technical Basis for User Interface Design of Health IT

36

2.4.4 Validate the user interface

While a developer might produce an EHR that meets established user interface requirements 

(i.e., is verified), it does not ensure that the intended users will be able to interact with it safely, 

effectively, not to mention with a modicum of satisfaction. Therefore, design verification is 

insufficient evidence of user interface design quality. Further evidence of interactive quality is 

needed, and can be provided by performing a step called validation.

To validate a user interface is to conduct a summative (i.e., final) usability test on a productionequivalent EHR. Such testing differs from formative usability testing because the focus is no 

longer on identifying design strengths and opportunities for improvement, but rather on 

determining if users who interact with the EHR in a representative manner are able to complete 

tasks successfully and without committing use errors that could cause harm.

For example, summative usability testing is the de facto standard way to validate a medical 

device’s use-safety and effectiveness, and both US and international standards on the application 

of human factors engineering to medical devices call for such testing.

Summative usability test characteristics should have the following characteristics:

• Test participants include representatives of each distinct group of intended users. Most 

EHR user populations will include multiple distinct user groups.

• The number of test participants is usually greater than the number included in a formative 

usability test. For example, in the medical device industry, the standard of care for 

summative usability testing is to include 15 representatives of each distinct user 

population, suggesting a minimum sample size of 15, 30, and 45 participants for EHR's 

that will be used by people who individually fit into 1, 2, and 3 distinct user populations

(e.g., physicians, registered nurses, and medical assistants), respectively.

• Testing is guided by a plan (i.e., protocol) that describes among other details the test 

goal, test method, test participants, state of the EHR prototype, hands-on tasks, and data 

to be collected data. Again, NIST provides a sample usability test plan in NISTIR 7742 

Customized Common Industry Format Template for Electronic Health Record Usability 

Testing.

• Test participants are not directed to think aloud while interacting with the EHR, as they 

might be instructed to do in a formative usability test, because the information sharing 

technique can affect how people interact with the EHR in ways that do not serve 

validation purposes.

• Testing focuses on the riskiest tasks. The objective is to put the high-risk user error 

mitigations to the test by calling upon test participants to perform the associated tasks 

and see if the error occurs, or if there are patterns of close calls and difficulties that 

suggests a greater chance of use errors occurring in real world use.
Technical Basis for User Interface Design of Health IT

37

• Test personnel seek to identify the root causes of any use errors and patterns of close 

calls and difficulties based on their observations of test participants performing tasks and 

associated interviews that usually come at the end of the test when the participant has 

performed all tasks. A key interview question to pose after a test participant has 

attempted all hands-on tasks is whether he or she believes the user interface is safe and 

effective as designed, or needs modification to ensure that it is.

• Test findings are documented in a document that may include design recommendations. 

Again, NIST provides a sample usability test report in NISTIR 7742 Customized Common 

Industry Format Template for Electronic Health Record Usability Testing.

With test results and associated analyses in hand, developers should perform a residual risk 

analysis on any use errors that occurred during the test as well as patterns of close calls and 

difficulties suggesting an heightened chance of use error. If the residual risk analysis suggests 

that the EHR is reasonably safe and effective, a developer may conclude that the application has 

been validated. If the residual risk analysis suggests that the EHR is not reasonably safe and 

effective, the EHR will require modification and the modifications will require follow-up validation. 

2.4.4.1 Additional details about validation usability testing 

This section provides expanded guidance on conducting an effective validation usability test of an 

EHR.

Developers may consider an EHR to be validated when they can make the claim, supported by

validation usability test data, that:

• The application is not vulnerable to use errors that could potentially, lead to significant 

harm (i.e., that the implemented design mitigations effectively protect against use error). 

• The intended users could successfully complete tasks that are essential to ensuring 

patient safety.

The veracity of these claims depends heavily on the quality of the summative usability test and 

how such testing interrelates with risk management efforts, which in turn interrelates with user 

research efforts. This explains why it is imperative to apply human factors engineering (aka 

usability engineering) techniques early and throughout the EHR user interface development 

process. Starting late or skipping a step not only stands to erode the quality of the user interface, 

but also jeopardizes a developer’s ability to make the above claims.

One approach to summative usability testing, and associated risk management efforts, includes 

the following steps:

1. Review the use-related risk analysis results to identify high-risk tasks.

2. Write a summative usability test plan that calls for a sample of representative users to 

attempt to complete high-risk tasks.
Technical Basis for User Interface Design of Health IT

38

3. Conduct a pilot test (including one or more sessions) to ensure that the test will proceed 

smoothly without artifacts that could artificially degrade or enhance user performance.

4. Conduct the test sessions.

5. Consolidate and analyze the test data.

6. Perform root cause analysis of user interaction problems (see next section for more 

detail).

7. Write a summative usability test report.

8. Conduct a residual risk analysis of identified user interaction problems.

9. (If necessary) Modify the EHR to reduce the chance of user interaction problems and 

conduct follow-on validation testing (potentially focusing only on the modified portions of 

the EHR). In other words, conduct another iteration of the design-model-test cycle.

10. Update the summative usability test report to include the results of the residual risk 

analysis; rationales supporting the claim that the EHR is reasonable safe and effective.

As show in in Figure 2-3 and discussed above (Step 9), the process allows for multiple iterations 

to ensure that all significant, use-related risks have been reduced to an acceptable level in the 

spirit of preventing harm, and that users are able to complete essential tasks. Simply stated, if a 

summative usability test reveals that users are committing significant (i.e., safety-related) use 

errors, the EHR developer should conduct follow-up studies to determine ways to modify the EHR 

to eliminate or reduce the chance of such occurrences
Technical Basis for User Interface Design of Health IT

39

Figure 2-3: An illustration of the risk analysis and mitigation process.
Technical Basis for User Interface Design of Health IT

40

2.4.4.2 Recommendations for conducting successful validation usability tests

Specific validation usability testing recommendations include the following:

• Test participants. Test participants should represent the intended users. Developer 

employees should not be test participants, even if they have appropriate clinical 

backgrounds. In cases that the EHR is being validated for use within the USA, the test 

participants should be USA residents, like, for example, the requirement set forth by FDA 

for validation usability testing of medical devices. 

• EHR configuration. Recognizing that EHRs are often customized for particular 

institutions and departments within them, developers should choose the most common 

and complete configuration for validation testing.

• EHR production equivalence. The EHR should be in a production-equivalent form. It 

should not be a “work-in-progress” that is expected to change before its release.

• Sample data. The EHR should be populated with representative, sample data to enable 

realistic interactions with the application.

• Test session. Common steps in a usability test sessions are the following:

1. Greet the test participants and have him or her review and complete an informed 

consent form, which may include statements pertaining to the non-disclosure of 

confidential information and the use of video recordings and photographs. Inform 

the test participant that the test is intended to evaluate the EHR, not the 

participant’s skills, work procedures, or clinical expertise. 

2. Orient the test participant to the test environment, test personnel, test purpose, 

and data collection instruments (rating scales, rating criteria). The orientation 

may include a general introduction to the EHR in a manner that does not 

constitute training or task assistance.

3. Direct the test participant to perform pre-selected hands-on tasks independently. 

Depending on the EHR, the number and extent of the tasks can vary widely. It is 

common for a validation usability test to call upon test participants to perform 10-

20 separate tasks.

4. After the test participant completes all hands-on tasks, conduct an interview to 

collect test participant impressions of user interaction problems (e.g., use errors, 

close calls, and difficulties) and seek feedback about the EHR's overall usesafety and ways to address any particular safety concerns. In certain cases, it is 

also beneficial to ask follow-up questions after the test participant completes a 

series of interrelated tasks (see Timing of questions below). 

5. Compensate, thank, and dismiss the test participant.
Technical Basis for User Interface Design of Health IT

41

• Test session duration. A summative usability test usually consumes at least 90 

minutes, averages 2 hours, and may extend to 3 hours or longer. Longer test sessions 

usually include one or more rest periods.

• Test personnel. A summative usability test calls for adherence to a formal plan and 

requires extensive data collection. As such, it is advantageous to have two people work 

as a team to administer each test session. Typically, one team member serves as the 

test administrator, directing the test activities and leading discussions with the test 

participant. The other team member serves as the data analyst, observing the quality of 

user interactions with the EHR and recording the associated data (e.g., use errors, close 

calls, difficulties, anecdotal comments, observations). However, it is possible for one 

person to conduct test sessions depending on the test’s focus, amount of test data, and 

data collection methods. 

• Familiarization period. In cases that a user is likely to take time to become familiar or 

reacquaint himself or herself with an EHR before using it, it is acceptable to designate 

time at the beginning of a test session for this purpose. However, test personnel should 

not dictate a minimum amount of time that should be spent, or how the participant should 

act. For example, it would be wrong to instruct the participant to study the EHR’s use in 

detail and review the user manual’s content. Rather, it is appropriate to state something 

like this:

“Imagine that it is your first day working in a new hospital unit. The charge nurse 

expects you to use the unit’s EHR independently, and to seek help from a colleague 

only if you face difficulties you cannot resolve independently. You now have the 

option to take up to 15 minutes to become familiar with the EHR in the same 

manner that you might in a real use situation. My colleague and I will be nearby 

doing other work. Let us know when you feel comfortable proceeding to the handson tasks.”

• Thinking aloud. As mentioned earlier, a technique called thinking aloud calls for the test 

participant to verbalize his or her thoughts while performing a task. It is appropriate 

during formative usability testing but not during summative usability testing. However, it is 

acceptable for a summative usability test participant to think aloud spontaneously, just as 

long as the test administrator does not encourage it.

• Task directions. Task directions are a prompt or instruction provided to a participant at a 

task’s start that describes the high-level task the test participant should perform. It is 

common to present task directions on a card for the test participant to read aloud. Test 

personnel may then ask the test participant if he or she understands the task. If there is a 

lack of understanding, the test administrator may choose to provide minor clarifications 

regarding the task goal, taking care not to provide any information that could be 

considered task assistance.

Task directions should be worded in a manner that clarifies the task goal but does not 

assist test participants by instructing them how to perform the task. Avoid using terms 
Technical Basis for User Interface Design of Health IT

42

that cue users to the proper menu selections or buttons to click. Task directions should 

use words that all test participants will understand, regardless of age and education level. 

Good: Determine if Olivia Green, a 10-month old girl, is growing at a normal rate.

Poor: Olivia Green is a 10-month old girl. Review the growth chart on the “Patient 

Chart” screen to determine if she is growing at a normal rate.

• Presentation of learning aids. Test personnel should not direct users to access

available learning aids (e.g., user manual, online help), noting that no such direction 

would occur in a real world use scenario. Rather, test participants should access learning 

aids only on their own initiative and in cases when such aids are normally available. 

• Assistance. The test administrator may choose to provide assistance to a test participant 

when the test participant has (1) reached an impasse such that he or she cannot 

continue independently, and (2) has passed a practical task time limit. Provide 

progressive levels of assistance, starting with a minimal assist that will help the 

participant to “get back on track.” Note that providing assistance constitutes a task failure. 

The reasons to provide any assistance at all, as opposed to stopping the task, are to (1) 

determine how well the test participant will be able to perform subsequent portions of the 

task, and (2) provide the user with the necessary, contextual knowledge to proceed with 

follow-on tasks.

• Assistance threshold. Only assist a test participant with a task when he or she has 

endeavored to complete the task without assistance for a predetermined period of time 

(e.g., 10 minutes) that is considered sufficient for even slow performers to complete it. If a 

participant asks for assistance before the assistance threshold, encourage the participant 

to persevere with the task.

• Hotline access. It is acceptable to provide test participants access to an actual or 

simulated hotline (i.e., help line) if such a resource will be available to actual EHR users 

and the hotline service can be delivered in a “production-equivalent” form. Participants 

may call a hotline using their cellphone, or a portable phone provided in the test room. 

Ensure hotline calls are completed using a speakerphone to enable test personnel to 

monitor and record the call. 

• Natural task flow. Do not interrupt the natural flow of a user task by dividing an 

integrated task into multiple steps or stopping to pose questions or collect ratings, for 

example. That said, it might be justifiable to divide a large span of activity into chunks that 

are normally separated by significant amounts of time.

• Timing of questions. Pose essential questions about use errors, close calls, and 

difficulties – as well as their potential root causes – only at the natural stopping points 

during the hands-on portion of the test, or after the test participant completes all handson tasks. If debriefing about an event during a post-task interview could bias the 

participant’s subsequent task performance, collect these subjective assessments during 

the post-test interview. 
Technical Basis for User Interface Design of Health IT

43

• Documenting user interaction problems. Document all user interaction problems in as 

much detail as possible, including onset conditions and performance influencing factors.

• Identifying root causes. In a post-task or post-session interview regarding use errors, 

close calls, and difficulties, be sure to ask questions and follow-up questions that 

generate responses helpful to determining the root causes of the interaction problems. 

Dissuade users from blaming themselves and encourage them to suggest design-related 

root causes. Note that the test participants’ shared insights might be judged at a later 

point to be accurate or inaccurate. Indeed, calling on participants to suggest user 

interface design-related root causes of use error might produce some false positives, but 

analysts can subsequently separate truth from creative, off-base suggestions.

• Design improvements. Do not solicit design suggestions from participants during a 

summative usability test. Instead, summative usability testing should focus on collecting 

data that will determine if it is safe and effective. The only appropriate time to solicit 

design suggestions is at the end of the test, if the participant says he or she thinks the 

design needs to change to be safer to use.

• Final use-safety and usability assessment. Near the end of a test after the participant 

has attempted all hands-on tasks, test personnel should give the test participant the 

opportunity to comment on the EHR’s overall use-safety and indicate if he or she believes 

there is a need for design modifications (including changes to instructions and training) 

so ensure its use-safety. Additionally, test personnel may seek test participants’ overall 

impressions of the EHR's usability (unrelated to use-safety) if their responses are of 

commercial interest.

• Ratings. Test personnel may collect usability ratings focusing on matters such as ease of 

use and task speed if they are of commercial interest. However, developers should not 

treat the ratings as evidence of use-safety. Also, to avoid biasing discussions, test 

personnel should delay the collection of commercial-oriented feedback until all other 

technical portions of the summative usability test are completed.

• Pleasant, neutral demeanor. Test personnel, and particularly the test administrator,

should maintain a pleasant, neutral demeanor during all discussions about the EHR. 

They should not communicate any pleasure or displeasure regarding the EHR's

performance or the test participants’ expressed views. 

• Training. Test participants should receive training if the EHR developer plans to 

implement administrative controls that will ensure EHR users receive training before 

using the EHR. Otherwise, the test should include both trained and untrained 

participants. Practicality suggests providing consolidated training in a single session as 

opposed to spreading multiple training sessions over many days or weeks. 

• Representative training. Any test participant training should be realistic, taking a 

realistic amount of time and including the same instruction as a real world training 

session. Company personnel may deliver the training even if actual training might be 

delivered by an independent third party. However, the “gold standard” approach is to 
Technical Basis for User Interface Design of Health IT

44

retain an independent party (e.g., one or more clinician educators) to deliver the training if 

this more closely models how actual training will be delivered.

• Decay period. There should be a decay period between the end of a test participant 

training session and the ensuing test session. Decay, as short as 1-2 hours might be 

sufficient, particularly if the training and test sessions are short and the real world gap 

between training and first use is also short. Longer training and test sessions, and real 

world cases in which substantial time often passes between training and first use, 

suggest a longer training decay period (e.g., training on Day 1 and testing on Day 2) is 

appropriate. For pragmatic reasons, it is unusual for decay periods to extend more than a 

few days.

2.4.5 Additional details about usability testing

2.4.5.1 Selecting usability test participants

The quality of a usability test depends in part on the appropriateness of the test participants 

involved, which is largely under the EHR developer’s control. In principal, the usability test plan 

should include a recruiting script that establishes the characteristics of qualified test participants, 

which should already be available in the form of user profiles or personas (see section 2.1.1.1 –

User profiles and section 2.1.1.2 – Personas).

As discussed in section 2.5.5.1 – Selecting usability test participants, usability test participants 

should bring objectivity to a test session. Therefore, it is generally considered poor practice to 

engage developer organization representatives as test participants. Even if such participants can 

be objective from a technical standpoint, their views of a given EHR might be influenced by their 

organizational affiliation and personal relationships (direct or indirect) with test personnel and 

other stakeholders. Consequently, their feedback about the EHR could be distorted (overly 

positive or negative) as compared to the feedback that could be collected from more objective 

individuals.

Also as discussed in section 2.5.5.1 – Selecting usability test participants, test participants should 

represent members of an EHR's distinct user populations. It is common practice to engage three 

to five representatives of each distinct user population in a formative usability test, although larger 

sample sizes might be warranted, especially when test results will drive major design decisions.

When selecting participants for a summative usability test, test planners should take care to 

sample each distinct user group equally rather than assemble a group that proportionally mirrors 

the user population. In other words, if two-thirds of the users are nurses, but there are three 

additional types of distinct users, nurses should comprise only one quarter of the test participants 

(e.g., 15 out of 60). In parallel, it is advantageous to select individuals with specific, secondary 

characteristics to obtain a sample that represents a normal distribution within a particular group of 

15 individuals, such as the following:

• Type of care environment (e.g., hospital/unit, clinic, physician’s office, long-term care 

facility)
Technical Basis for User Interface Design of Health IT

45

• Occupational experience (e.g., years working as a nurse)

• Experience using one or several specific EHRs

2.4.5.2 Specifying usability test tasks

Formative usability tests afford the opportunity to have test participants perform any task of 

interest to the EHR development team. As such, tasks might be safety-related or not, and task 

selection might have more to do with which portions of the EHR have been prototyped versus not.

Summative usability testing does not afford this degree of freedom. As discussed in section 2.5.4

– Validate the user interface, a summative usability test’s purpose is to validate that the intended 

users can complete safety-related tasks without committing potentially harmful use errors. This 

requirement automatically constrains the task list, at least the list that pertains to validation, noting 

that a test may include other tasks about which there is an interest in ensuring a high degree of 

usability for commercialization sake.

Each task specifications within a summative usability test plan should include the following 

contents:

• Short task description.

• Test participant prompt (Note that the prompt should exclude content that could instruct 

the participant how to perform the task).

• List of associated risks (found in use-related risk management documents, such a userelated failure modes and effects analysis). The list can simply reference risk 

identification numbers included in the risk analysis.

• EHR configuration at the task’s starting point.

• Additional information required to complete the task (e.g., a set of patient vital signs 

requiring manual entry).

• Distractions (if any), such as realistically interrupting a task with a phone call that the test 

participant would be required to answer.

• Assistance threshold – the point at which a test administrator will offer limited assistance 

to the test participant to overcome an obstacle to continuing. Note that such assistance 

should constitute a task failure.

• Summary of expected actions. 

• List of anticipated potential use errors. Note that all use errors, anticipated or not, as well 

as close calls and difficulties should be captured in a data log.
Technical Basis for User Interface Design of Health IT

46

2.4.5.3 Root cause analysis

This document section provides expanded guidance on how to determine the root causes of use 

errors and patterns of close calls and difficulties. 

It is most productive and accurate to assume that most user interaction problems with an EHR 

stem from shortcomings in its user interface and support system. Conversely, it is unproductive 

and arguably naïve to blame the users for interaction problems. As such, summative usability 

testing specialists abide by the mantra “don’t blame the users.” 

Nonetheless, “to err is human.” People play the leading role in the performance of a use error. 

There is no question that people can be forgetful, careless, clumsy, lazy, confused, and 

demonstrate many more shortcomings. But just as it is obvious that people can exhibit these 

shortcomings, it is also obvious that an EHR must be designed defensively to account for these 

shortcomings. 

Developers should be mindful that EHRs are used by different types of people, these people will 

perform a wide range of types of tasks in various environment and use scenarios, and an EHR 

may be in use for many years. Logic dictates that some interactions will involve individuals who 

might not be the strongest performers when it comes to using an EHR, and that the EHR must 

protect against potentially harmful use errors. Moreover, the EHR’s user interface must be free of 

flaws that would induce even the most gifted users to commit use errors despite their best efforts 

to perform tasks properly to ensure safety and success.

Moving forward with the viewpoint that user interface design shortcomings, and not users, are the 

principal cause of use errors, the challenge is to identify the most likely, user interface-related 

cause of use errors. One approach to root cause analysis (RCA) includes the following steps, 

some of which may be performed in parallel.

1. Identify provisional root causes. Test personnel, and perhaps other team members

familiar with the test results, should have a sense for what might have caused a given 

user interaction problem. To start the RCA process, it makes sense to document the 

cause(s) as provisional and subject to change. It might be productive for team members 

to identify provisional root causes independently and then discuss them enroute to 

consensus, provisional findings. 

2. Analyze anecdotal evidence. Test data should include test participant explanations 

regarding the cause of use interaction problems. Recognizing that this information might 

be accurate or inaccurate, analysts should review it to see if it reinforces the provisional 

root causes(s) or suggests modifying them.

3. Inspect the EHR for user interface design flaws. Arguably, the most productive step in 

the RCA process is to inspect the EHR's user interface for design flaws. The inspection 

may be based on the principles provided in section 3 – EHR User Interface Design 

Principles as well as other sources.
Technical Basis for User Interface Design of Health IT

47

4. Consider other contributing factors. Analysts should also consider whether other 

factors contributed to the root cause, such as characteristics of other EHRs, which might 

cause negative transfer of experience that leads to a use error; use environment factors, 

such as poor interoperability among systems; and test artifacts that induce unnatural 

user-EHR interactions. 

5. Develop a final hypothesis. The final step is to develop a final hypothesis about the 

user interaction problems root cause(s), informed by the aforementioned analyses. 

Clearly, the final hypothesis will be the end product of considering evidence and applying 

professional judgment. 

2.4.5.4 Document user interaction problems

This section provides expanded guidance about reporting user interaction problems in a 

summative usability test report.

A report about a summative usability test of an EHR should thoroughly document the quality of 

user interactions with the application. Presuming that a developer has followed a user-centered 

approach to user interface design that has included formative usability testing, the quality of user

interactions with a production-equivalent EHR should be quite good. However, there are almost 

always residual, and potentially minor, problems to report. This is why there is almost always a 

need for root cause analysis of the problems and an associated residual risk analysis, which 

might lead to design modifications and follow-up testing. Therefore, it is important to fully

document user interaction problems, possibly in a narrative or tabular form, including the 

following details:

• Problem title. A short description of the problem for convenient reference. 

• Associated task. The single or multiple tasks during which the problem occurred.

• Associated risks. Cross references to the use-related risk analysis document and line 

item (or equivalent) that addresses the problem, indicating its probability, the severity of 

the potential harm, and any risk reduction measures.

• Potential harm(s). The harm that may arise due to the problem, as already stated in the 

use-related risk analysis document. 

• Problem description. Detailed description of the problem, including the number of test 

participants who experienced the problem (e.g., committed the use error) and how many 

times the problem occurred in total.

• Participant-reported root causes. Descriptions of the root causes identified by the 

participants. 

• Root cause analysis. Descriptions of the root causes determined by the usability

analysts based on their analysis of test participants’ performance and commentary.
Technical Basis for User Interface Design of Health IT

48

These components of a comprehensive problem document may be augmented later on with the 

following:

• Residual risk analysis. Document the results of a residual risk analysis of the problem, 

which may indicate if the EHR's user interface is reasonably safe and effective “as is,” or 

if it needs modification. A description of a potentially effective modification is not 

necessary, but it may be included in a summative usability test report.

Importantly, even if a single test participant commits an error that could lead to patient harm (e.g., 

ordering a 10-fold overdose of the intended medication), the user interface should be assessed 

as a potential cause of the error. Often, the assessment suggests that the user interface could be 

improved to prevent the use error, and that the improvement should be implemented to bring userelated risk into an acceptable range. After all, once the EHR is released there will be many 

thousands of opportunities for other clinicians to make the same, harmful error.
Technical Basis for User Interface Design of Health IT

49

3 EHR User Interface Design 

Principles

3.1 Introduction

This document section presents 343 EHR user interface design principles intended to promote 

good user interface design characteristics and avoid user interface design shortcomings that 

introduce usability and use-safety problems. 

All of the principles are original, although many of them mirror principles developed by other 

organizations and for software types other than EHRs. After all, while EHRs may have unique 

characteristics, they also share characteristics with software used by other industries and in other 

settings. 

The research team’s principles development process included the following steps:

• Conducted a literature search to identify sources of user interface principles pertaining to 

diverse products and systems. The approximately 20 sources included standards, 

textbooks, and websites.

• Starting with a set of over 900 pre-existing principles, assembled a consolidated set of 

the most applicable principles from the identified literature sources, which subsequently 

served as inspiration for EHR-specific principles. Many of these pre-existing principles

were legitimized by strong empirical evidence, and served as a foundation upon which 

the research team built the set of EHR-specific principles.

• Wrote EHR-specific principles based on the project research findings, but in some cases

inspired by pre-existing principles. Specifically, researchers’ qualitative analyses 

identified evidently good and poor user interface design characteristics. These features 

were identified through EHR user responses to a Web-based survey, observations of 

clinicians using EHRs, expert reviews of existing EHRs’ user interfaces, and usability 

tests of EHRs. The researchers then wrote principles. 

• Refined the EHR-specific principles based on feedback from multiple reviews by project 

staff.

The principles prioritize EHR safety and effectiveness over general usability, even though 

usability is also an important attribute. For example, one principle suggests using consistent 

terminology, but continues to explain that this step can make an EHR (1) easier to learn to use, 

and (2) help prevent users from becoming confused by the use of two different terms to describe 

the same thing. In other cases where the rationale might not be as self-evident, clarification is 

provided.
Technical Basis for User Interface Design of Health IT

50

The principles have the following characteristics in common: 

• Based on one or more research findings, complemented by research team members’ 

professional judgments.

• None of the principles are based solely on professional judgment.

• Describe a design strategy rather than prescribe a particular software user interface 

design solution, examples notwithstanding.

• Apply to various types of EHRs rather than just a special class of them.

• Apply to various types of EHR software platforms (e.g., desktop, web, and mobile 

applications).

• Compatible with various types of design and software development processes. 

• Written in plain English as opposed to user interface designer jargon.

• Consistently written in the imperative voice.

The principles are organized into the following categories:

Accessibility

Affordances

Alerts

Clinical Decision Support

Conceptual Model

Content Organization

Customizability

Data Entry

Efficiency

Error Prevention, 

Detection, and Recovery

External Consistency

Feedback

Information density

Internal Consistency

Language

Metaphor

Navigation

Patient Identification

Search

Security

Status Indication 

User Support

Visual Design 

Buttons

Controls

Graphics 

Color

Typography

Workflow

Miscellaneous

Importantly, the principles represent best practices that are likely to enhance a given EHR’s 

usability and use safety. However, they are not intended to be strict requirements and some of 

them might not be fully applicable to a given EHR. Given the distinct qualities of any given EHR 

user interface design, EHR developers should determine which principles are applicable to their 

particular user interface. 
Technical Basis for User Interface Design of Health IT

51

3.2 Good Design Principles

Accessibility

1. Accessibility. Follow standards and principles for software accessibility to the extent 

feasible and appropriate to the application6

.

2. Adjustable font size. Enable users to adjust the EHR's font sizes to improve legibility, 

either by using custom controls in the EHR or using a web browser's built-in “zoom” 

feature. 

3. Display compatibility. Design the EHR in a manner that makes it compatible with 

different size displays. For example, if a user accesses the EHR on a computer with a 

smaller than usual display (e.g., a laptop computer display instead of a desktop 

computer display), critical information and functionality should remain visible and 

legible. 

Affordances

4. Direct manipulation. Enable users to manipulate onscreen objects directly when this 

interaction style is likely to make interactions more intuitive, efficient, and error resistant 

than other interaction styles. 

5. Dynamic menu controls. Place informative symbols in consistent locations to control 

the behavior of dynamic menus (e.g., drop-down menus, roll-over menus, window 

shade menus). For example, include a downward facing arrow on the left or right side 

of a control to indicate that clicking on the button will cause additional information to 

appear.

6. Hidden functions. Avoid implementing key functions in a manner that cannot be 

readily discovered without reading the user manual (e.g., functions that require the user 

to right-click on a control, or place the mouse cursor over a control to present hidden 

information).

Alerts

7. Alerts. Limit alerts to those that are clinically essential to ensure safe and effective 

patient care.

8. Alert activation. Ensure that safety-critical alerts cannot be deactivated.

9. Alert prominence. Make alerts visually prominent to help draw the user’s attention. 

When appropriate, place the alert in proximity to the most closely related onscreen 

contents.

 6 For example, the W3C Web Content Accessibility Guidelines, available at 

http://www.w3.org/WAI/intro/wcag
Technical Basis for User Interface Design of Health IT

52

Figure 3-1: A prominent alert.

10. Alert acknowledgement. Require users to acknowledge safety-critical alerts, but not 

necessarily other types of lower-priority alerts.

11. Alert hierarchy. Display alerts in accordance with an importance hierarchy that may 

give the alerts different appearances, sounds, and behaviors. For example, highest 

priority alerts might feature a flashing red background, while lowest priority alerts might 

feature a non-flashing cyan background7

. 

Figure 3-2: An example of alert hierarchy.

12. Alert timing. Present alerts at the time when they are most relevant to the user's 

actions. For example, certain alerts might be most useful upon opening patient charts, 

and others might be useful during plan creation.

 7 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
Technical Basis for User Interface Design of Health IT

53

13. Alert symbols. Avoid using symbols associated with alerts (e.g., a triangle with an 

exclamation point) for non-alert information. Excessive or incorrect use of alert 

symbols, some of which might have standardized uses, might cause users to overlook 

actual alerts. 

14. Flashing. Minimize the use of flashing to draw the user’s attention to information (e.g., 

use flashing only for high priority alerts). Flash rates should be no faster than 2 cycles 

per second. The signal should be visible at least 50 percent of the time8

.

15. Urgent tasks. Alert users to the need to perform urgent tasks.

Buttons

16. Button appearance. Make buttons and equivalent, selectable objects visually distinct 

from other onscreen content.

17. Button label. Ensure that button labels accurately describe the associated function.

18. Button label location. Place button labels on the button’s themselves or above the 

button. Avoid placing button labels below the buttons because the labels are unlikely to 

be visible during a button press, thereby preventing the user from detecting an 

erroneous button press.

19. Button names. Generally, label buttons using verb-noun pairs, such as “Add Note” and 

“Open Chart.” The pairing reduces the ambiguities that can arise when the label is a 

standalone verb or a noun.

20. Button size. Size buttons to facilitate rapid selection using all of the possible pointing 

devices (e.g., trackpad, mouse, finger), noting that overly small targets can increase 

selection time and selection errors.

21. Button spacing. Space buttons apart so that their centers are separated by the pixel 

equivalent of at least 0.5 inches and optimally 0.75 inches or more9

.

Clinical decision support

22. Decision support. Provide users with convenient access to the information necessary 

to make a given clinical decision. For example, the necessary information may be 

presented on a single screen, or mostly on a single screen with direct links to the rest 

of the needed information. Avoid partitioning information if it would be more easily 

acquired and interpreted when presented in an integrated form. 

 8 ANSI/AAMI HE75:2009/(R)2013 Human factors engineering – Design of medical devices.

Section 21.4.10.3.

9 ANSI/AAMI HE75:2009/(R)2013 Human factors engineering – Design of medical devices.

Section 18.3.2.2.2
Technical Basis for User Interface Design of Health IT

54

23. Reliance on memory. Minimize the number of EHR-specific information (e.g., codes, 

terms, symbols, special interaction sequences, color meanings) users must remember 

to interact effectively with the application.

24. Contextual patient details. Persistently display and highlight important patient 

information, such as disease mechanisms, current medications, and allergies, on 

patient information displays. Information may be presented in a persistent header, 

“dashboard,” “whiteboard” or similar user interface element that contains key 

information. Do not permit the patient name to become hidden or displaced by other 

information due to paging or scrolling, for example. 

25. Patient information summary. Present patient information in a form that enables 

users to quickly develop a comprehensive understanding of the patient’s condition, 

particularly at the start of a new shift (i.e., during shift-turnover). Some use scenarios

might warrant displaying the summary in parallel (e.g., in a dedicated window) with 

other EHR content. 

26. Patient history. Enable clinicians to review multiple facets of a patient’s medical 

history at once, serving many possible purposes including orienting clinicians during 

the shift-turnover process and preparing for rounds.

27. Medication orders. Enable users to order medications with sufficient specificity and 

precision to cover all potential needs including highly complex ones and those 

associated with special populations (e.g., neonates, children). For example, a physician 

might need to order a medication for delivery in one of many possible forms (e.g., 

injection, liquid, nasal, tablet) and with an unusual degree of precision to treat a patient 

that is particularly sensitive to a drug (e.g., a low-weight neonate receiving a powerful 

drug administered based on body weight).

28. Medication range. Display the normal limits (e.g., fluid delivery rate) associated with 

the delivery of a particular medication. Such information can help users detect a dosing 

error, such as a ten-fold dosing error that could arise simply by typing an extra “0” in a 

data entry field. 

29. Recent medications. Provide users with a convenient means to view all medications 

that a patient has taken recently as compared to all prescribed medications. Similarly, 

indicate which medications the patient was previously prescribed, but has since 

stopped taking (i.e., discontinued medications).

30. Similar medications. Where appropriate, present lists of similar medications to remind 

users of different medications that might serve the same purpose as a selected 

medication and provide certain benefits (e.g., cause fewer side effects). 

31. Pending orders. Give users access to a summary of all pending orders for a given 

patient. Such a summary will enable them to check the accuracy of the orders and 

possibly edit them to correct mistakes and make necessary additions.
Technical Basis for User Interface Design of Health IT

55

32. Calculators. Build-in calculators (e.g., determine a drug dose based on patient weight) 

that that can increase the speed of tasks requiring calculations, and prevent users from 

having to perform mental calculations that could be subject to error. 

Figure 3-3: An example of a dose calculator.

33. Educational materials. Provide access to educational materials that might help the 

user make clinical decisions and that the user can provide to patients to help them 

understand certain medical topics.

34. Discontinued medications. Enable users to indicate why medications were 

discontinued. For example, if a clinician discontinued a patient’s medication because it 

induced an undesirable side effect, other clinicians could use such information to 

optimize future prescription decisions (e.g., by avoiding medications in the same class)

Conceptual Model

35. Conceptual model. Establish an overarching EHR organization scheme (i.e., 

conceptual model) that enables users to form a simple mental model of how to navigate 

within it and locate specific content. For example, users may be well served by a 

conceptual model that parses the user interface into a limited number (e.g., 5-7) of 

major elements. 

36. EHR prioritization. Ensure that the conceptual model emphasizes the most important 

EHR capabilities, such as admitting a patient or charting a patient’s progress in a 

certain type of EHR.

37. Integration. Integrate EHR functions in a manner that gives the user the sense of 

working within a single, consistently designed application, even if it is actually a set of 

individual applications that are linked together. 
Technical Basis for User Interface Design of Health IT

56

Content Organization

38. Information order. Place information in a useful order. For example, within a list of 

patient visit records, place the report from the most recent visit ahead of the second 

most recent visit.

39. Information layout. Arrange information in a manner that clarifies functional 

interrelationships and facilitates efficient visual scanning.

40. Information placement. Place the same information in the same location (on a given 

screen or within a given type of window, for example) to the extent possible.

41. Information and control duplication. Limit the redundant presentation of information 

and controls to cases where they serve safety-critical purposes and/or substantially 

increase task efficiency (i.e., are a major convenience).

42. Unnecessary information. Omit,(i.,e., hide) or de-emphasize (e.g., gray-out) 

information that is not directly relevant to the user's role, current task, or to other 

information on the screen. 

43. Menu depth. Where possible, limit the menu system depth to three or fewer levels.

44. Similar functions. Avoid providing different functions that users might perceive as 

being identical to each other. Instead, seek opportunities to consolidate similar 

functions, thereby simplifying the user interface structure. For example, instead of 

providing separate tabs for “Patient Conversations” (for documenting telephone calls 

with patients) and “Patient Visits” (for documenting in-person meetings with patients), 

provide a single tab “Patient Encounters” that enables users to document both phone 

and in-person conversations with patients.

45. Data grouping. Present data in logical groups that facilitate patient monitoring and 

diagnoses (e.g., respiratory ailment, cardiovascular ailment). For example, present on 

the same screen those parameters that are nearly continuously monitored.
Technical Basis for User Interface Design of Health IT

57

Figure 3-4: A sample patient summary that presents five groupings of related patient 

information.

46. Data ordering and filtering. Enable users to control the view of tabulated data, 

arranging and filtering it to display information in the most useful form.

Figure 3-5: Clicking on a table header sorts the table's data according to selected column.

47. Information types. Clearly distinguish between different types of information that could 

be mistaken for one another (e.g., a flu test vs. a flu shot). 

48. Diagnostic data. Provide users with the means to view all diagnostic information (e.g., 

laboratory results, vital signs, etc.) for a selected patient and the ability to sort or filter 

them by type, date (e.g., most recent to oldest), and any other important factor.

49. Patient-related content. Clearly distinguish between content that is related to a 

particular patient and content that is not. 
Technical Basis for User Interface Design of Health IT

58

50. Scrolling. Enable users to scroll within tables and other information presentations that 

are too large to fit at one time on the screen or within a window, for example. Present 

scroll controls in a consistent manner throughout the EHR and enable users to scroll 

either by touching or clicking on the scroll controls or by scrolling the mouse wheel 

while the mouse cursor hovers over the associated table. Horizontal scrolling should be 

avoided as much as possible.

Figure 3-6: Samples of scrolling controls for tabular data.

51. Use of labels. Label all major user interface elements (e.g., information groups, 

windows, pop-up dialog boxes) and special objects (e.g., file cabinet illustration).

Figure 3-7: Examples of panel and pop-up window labels.

52. Hierarchical labeling. Use hierarchical labeling to reinforce functionally-related or 

task-related information and controls and to reduce the number of words needed to 

identify the labeled elements. For example, instead of including the labels “Patient 

name”, “Patient age”, and “Patient height”, include a heading label “Patient”, followed 

by secondary labels “Name”, “Age”, and “Height”.

53. Label placement. Minimize the distance between labels and the related onscreen 

elements to ensure that they will be associated.

54. Current parameter values. Differentiate the most recent (i.e., current) parameter value 

from older ones.
Technical Basis for User Interface Design of Health IT

59

Figure 3-8: Today's current parameters are highlighted with a green header and thick black 

outline.

Controls

55. Control-display relationship. Place controls adjacent to associated information. For 

example, place a control just below the associated information so that users may 

immediately recognize the relationship. This physical arrangement also enables users 

to view the information, rather than block it with their finger, when pressing the control 

on a touchscreen, for example.

56. Control conspicuity. Make sure that important controls are sufficiently visually 

conspicuous to stand out from other onscreen elements. 

57. Control actions. Controls that have a similar appearance and are grouped together 

should behave consistently (e.g., each of four controls in a 1 x 4 arrangement should 

evoke pop-up menus, rather than having one of the controls send a message).

58. Single control purpose. Assign a single control a single purpose. Do not vary a single 

control’s function based on the context of use. 

59. Antiquated interaction mechanisms. Avoid using user interface mechanisms (i.e., 

widgets) that are widely considered to be “old-fashioned” and arcane because (1) users 

might lack familiarity with them (i.e., there would be no positive transfer of experience 

from other applications), and (2) users might feel disdain for learning to use an 

application that does not work like other, contemporary applications.

60. Highlighting selections. When a user selects an option that remains on the screen 

afterward (e.g., 1 out of 10 tabs), change the object’s appearance to indicate that it is 

the one selected.
Technical Basis for User Interface Design of Health IT

60

Customizability

61. Customization scope. Enable users to customize EHR functions when there can be 

significant safety and efficiency improvements, but only when all users will use the 

same, customized version of the EHR or will log into the system and be the only person 

to view it in its customized form.

62. Customization constraints. Constrain customization options so that users cannot 

configure the EHR in a manner that would jeopardize its usability or use safety. For 

example, if enabling users to customize the colors used for displaying a vital sign, 

enable users to select only colors that do not produce a low color contrast with the vital 

sign's 

63. Default settings. Enable users to easily return settings to their default values except 

when the action could cause problems (e.g., initial confusion, longer information search 

times, erroneous data and control inputs) for other users.

Figure 3-9: An example of "Reset" controls that cause the EHR to revert to its default 

settings.

64. Institutional customization. Enable large user groups (e.g., entire hospital units) to 

customize user interface elements to provide necessary functions and optimize 

workflows

65. EHR configuration. When an EHR has many distinct user groups, enable users within 

a group to configure it to best suit their particular needs. Do not make one group of 

users adapt to a user interface configuration better suited to another user group of 

users. 

66. User accounts. Prevent unauthorized users from customizing the EHR in a manner 

that will affect other users' interactions with the EHR. For example, enable users to 

customize settings only for their particular EHR account, but not other users' accounts. 
Technical Basis for User Interface Design of Health IT

61

67. User control. Give users the opportunity to perform tasks in the order that best 

matches their preferred and appropriate workflow. Make sure that such flexibility does 

not degrade the users’ ability to form a simple mental model of the EHR’s organization 

and workflows.

68. Permanence of customized settings. If the user adjusts a customizable setting on 

one page in the EHR, apply the setting to other pages in the EHR, thereby avoiding the 

need to repeat the adjustment. 

69. Saving user settings. Avoid requiring users to set their preferences repeatedly. For 

example, instead of requiring users to manually hide an informational pop-up window 

multiple times, provide a "Do not show pop-up window" button that will hide the pop-up 

window permanently. 

70. Indication of customizable features. Indicate which aspects of the user interface may 

be customized. 

71. Layout. Consider enabling users to re-arrange on-screen information to best meet their 

information needs and workflow. 

72. Changing units of measure. Enable users to change the units of measure in cases 

that parameter values might be measured in more than one type of units. For example, 

enable users to choose to enter patient weight in pounds or kilograms to match the 

units in which the weight was taken. 

73. Resizing. Enable users to resize selected onscreen elements, such as windows, to 

optimize their view of onscreen content to best suit their needs and preferences. 

However, an EHR should not enable users to hide or otherwise diminish the 

conspicuity of essential and safety-critical information, such as alert windows (or 

equivalent displays).

74. Progressive disclosure. Initially present users with essential information, such as in 

an overview or summary, and give them the option to access supplemental information 

upon request. This approach, which gives users control over how much information 

they view and the pace of presentation, can prevent overloading users with 

unnecessary information. 
Technical Basis for User Interface Design of Health IT

62

Figure 3-10: The "View more" buttons provide access to additional details; an example of 

progressive disclosure.

75. Lists. List items in a column rather than in a row to facilitate scanning and differentiate 

the list from text paragraphs. 

Figure 3-11: An example of items presented in a vertical list (left) and in a paragraph format 

(right).

76. Pacing. Let users establish the pace of interaction with the EHR rather than forcing 

users to perform tasks at a predetermined pace that might exceed their capabilities.

Data Entry

77. Data input constraints. Constrain the format in which users may enter data. For 

example, if a numerical entry should be in the 0 to 10.0 range, constrain data entries to 

be in that range and automatically insert the decimal point when a user enters “2” and 

“7” to specify a dose of “2.7,” for example. This technique is called “data masking.”
Technical Basis for User Interface Design of Health IT

63

78. Inputted data validation. Automatically check safety-related, inputted data to ensure it 

is in the correct format and within an appropriate range. Alternatively, prompt the user 

to confirm the correctness of inputted values and correct them if necessary. Reject 

values that are clinically impossible or inappropriate based on patient's characteristics 

(i.e., patient gender, age) or previously stored values.

Figure 3-12: An example of a data input validation error.

79. Saving changes. Prompt the user to confirm or cancel new data inputs. Also, make 

the mechanism for saving new inputs explicit (e.g., pressing a “Save” button) as 

opposed to implicit (e.g., saving by closing a window). Implicit methods for saving 

inputted data can lead users to question whether or not their inputs were saved.

80. Clear function. Enable users to clear the data entered into a form and start the data 

entry task again.

81. Unsaved changes. Indicate when the user has made a change (e.g., selected a new 

setting, entered information into a data field) that still needs to be saved or canceled.

82. Overwriting data. Indicate when new data entries will overwrite existing data.

83. Data protection. Prevent users from editing information considered to be final (e.g., 

signed off). If users need to modify existing data, require them to "sign off" on their 

edits and possibly to explain the change. 

84. Annotation. Enable users to annotate EHR information as needed to ensure effective 

patient care. For example, enable users to add a note to vital sign data that might be 

highly variable for a specific reason that should be communicated to others.
Technical Basis for User Interface Design of Health IT

64

Figure 3-13: Examples of annotation.

85. Selection versus typing. Where possible, enable users to enter data by selecting from 

a set of options (e.g., drug names) rather than typing the entry. This approach can 

accelerate tasks and prevent data entry errors (e.g., typos). The approach also 

provides users with a sense of the input options as opposed to requiring the user to 

recall them. In cases where typing allows for improved accuracy or efficiency, enable 

users to enter data by typing rather than selecting. 

Figure 3-14: Examples of selection controls (left) and text entry fields (right).

86. Alternative means of data entry. As appropriate, enable users to enter data using 

various input methods. For example, to the extent made possible by the hardware, 

enable users to enter data using an on-screen or a physical keyboard. 

87. Onscreen keyboards. Use onscreen keyboards that have a conventional layout (e.g., 

keyboards with an alphabetical or QWERTY layout). Do not require users to type on a 

keyboard with an unconventional layout because it is likely slow down data entry tasks 

and increase the chance of data input errors. 
Technical Basis for User Interface Design of Health IT

65

Figure 3-15: An example of a conventional QWERT keyboard layout (top) and a less 

common Dvorak layout (bottom).

88. Sliders. Provide users with sliders (or equivalent) to change values when this input 

modality provides sufficiently precise input values. This data entry approach can be 

faster that typing-in values and less prone to error because typos are impossible.

Figure 3-16: Slider controls used to toggle the alarm status and adjust its volume.

89. Input fields. Make input fields visually distinct from other on-screen elements (e.g., 

static text fields, instructions, examples).

90. Input field layout. Fit input fields into an alignment grid (system of invisible vertical and 

horizontal lines) to facilitate content scanning. Do not arrange input fields in what may 

appear to be a random pattern, presenting multiple input fields in a single row, with 

spacing dependent on field length alone because such layouts are difficult to scan. 

Place the fields in a logical order that facilitates a natural workflow. 
Technical Basis for User Interface Design of Health IT

66

Figure 3-17: Examples of a well aligned field layout (left) and a haphazardly arranged layout 

(right).

91. Input field size. Make data input fields sufficiently large to contain the necessary 

amount of information. Do not force users to limit data entries when the limitation can 

have negative consequences (e.g., an overly terse or incomplete diagnostic comment). 

Limit the field size to an exact length when the inputted data format is fixed (e.g., 9 

numbers such as found in a social security number).

Figure 3-18: An example of well-sized fields (left) and fields that are too small to contain the 

expected information (right).
Technical Basis for User Interface Design of Health IT

67

92. Units of measure. Clearly present units of measure adjacent to the associated 

measures (e.g., vital signs). Avoid mixing units of measure from different systems (e.g., 

English and Metric) except in cases in which a mixture is conventional. Do not change 

units automatically, instead require users to make such changes so that they are 

immediately aware of the change. It is acceptable to present units of measure using 

common shorthand, such as using “lbs.” as shorthand for “pounds.”

Figure 3-19: Sample controls for adjusting weight, height, and temperature units.

93. Settings. Clearly differentiate between settings where only one option may be selected 

at a time (e.g., radio buttons) and multiple selections are possible (e.g., check boxes).

94. Data format example. Provide an example of how to format data (e.g., mm–dd–yyyy 

to indicate the proper format for a birthdate) when a special format is required.

Figure 3-20: A sample format suggestion appearing below the Birth Date field.

95. Leading and trailing zeroes. Do not require users to enter leading or trailing zeroes 

when inputting numbers.
Technical Basis for User Interface Design of Health IT

68

96. Incomplete or missing data. Enable users to indicate, perhaps by annotating a data 

entry with text, when certain data might be incomplete or unavailable. 

97. Missing information. Prompt users to enter any required and missing information 

before they finish a particular data entry task. For example, a user who is preparing a 

referral but does not specify a time frame within which a consultation should occur 

should be reminded to enter the time frame. This principle does not apply to optional 

information and urgent and emergency use scenarios.

98. Required versus optional fields. Indicate which fields within a data entry form are 

required (i.e., must be filled-in) versus may be left empty. A common convention is to 

place an asterisk with required fields, denoting that the asterisk means required in an 

adjacent key. 

99. Copying and pasting information. Enable users to “copy and paste” appropriate 

information within the EHR, as well as import and export copied information where the 

capability will reduce user workload and prevent use error.

100. Automated entry of large datasets. Enable automatic data entry where possible, 

such as enabling the EHR to upload electronic lab report data that automatically enters 

data for multiple patients.

101. Auto-populate data. Automatically populate forms with data (e.g., patient vital signs) 

when the data is available electronically. This approach will reduce clinician workload 

and eliminate data transcription errors.

102. Pre-filling information. Pre-fill information that has already been entered into the 

system (e.g., patient identifiers) or is known by the system (e.g., city name based on a 

previously entered zip code).

Figure 3-21: An example of a workflow that utilizes the entered postal code to automatically 

fill the city field.
Technical Basis for User Interface Design of Health IT

69

103. Type-ahead. Present data possibilities dynamically as users enter letters into certain 

fields (e.g., drug name). For example, display a list of all drugs that start with the letters 

“d” and “o” as soon as the user enters these letters into a drug name field.

Figure 3-22: An example of type-ahead functionality that presents drug names including the 

entered characters.

104. Repetitive data entry. Do not require users to enter the same information more than 

once unless it serves a safety-critical or security-related purpose. The task of reentering data can frustrate users and unnecessarily introduce opportunities for use 

error.

Efficiency

105. Improving efficiency. Provide users with the means to complete urgent and frequent 

tasks rapidly to increase patient safety, limit user workload, and boost productivity. 

Where necessary, the increased efficiency of high priority tasks may come at the 

expense of reduced efficiency of low priority and infrequent tasks.

106. Frequent tasks. Ensure that users can perform frequent tasks quickly, compromising 

the speed of less frequent tasks other than those for which patient safety depends on 

rapid task performance.

107. Emergency access. Enable users to access the EHR immediately in an emergency, 

even if they do not have or remember the proper password, for example. Do not lock 

users out of the system in a use environment in which emergency access might be 

necessary. Alert the system administrator (or equivalent), as well as other appropriate 

individuals to the emergency access so that the proper security checks can be initiated.

108. Emergency task performance. Provide users with a direct means to perform 

emergency tasks, rather than requiring them to first perform non-essential tasks. For 

example, enable appropriate users to order an emergency medication (e.g., tissue 

plasminogen activator (t-PA) for ischemic stroke) without having to complete a patient 

admission form ahead of time. The requirements to first perform relatively low 
Technical Basis for User Interface Design of Health IT

70

importance and non-urgent steps could cause an undesirable delay that could lead to 

patient harm. 

109. Required actions. Provide users with a means to determine required (i.e., pending) 

actions rapidly. For example, present a prompt guiding the user to perform the next 

step in a task.

110. Number of steps. Reduce the number of steps required to complete tasks, such as 

printing a patient chart, by employing default settings and consolidating choices to the 

fewest screens possible.

111. Keyboard shortcuts. If the EHR will run on a system featuring a physical keyboard, 

explore opportunities for utilizing keyboard shortcuts that will reduce the time to perform 

frequently performed actions. 

112. Navigation shortcuts. Consider including a shortcut menu that provides direct access 

to the EHR's most frequently used features (e.g., print, search, medication orders), 

individuals (e.g., physicians, therapists), and facilities (e.g., referral providers, 

pharmacies).

113. Previews. Seek opportunities to present previews of information that might eliminate 

the need for users to navigate to a different page within the EHR. For example, enable 

users to preview past test results by placing the mouse cursor over a test name, rather 

than requiring users to click on the test name, go to another screen, and then return to 

the original screen.

114. Processing time. Minimize the application’s processing times, such as data loading 

times, which occur in the course of performing a task. 

115. Pre-set content. Explore opportunities to limit the need for manual typing by providing 

pre-set content for frequently used functions. For example, include “canned” notes or 

messages that users can select easily. 

116. Operations on multiple selections. Enable users to perform certain functions on 

multiple selections simultaneously. For example, enable users to select multiple 

patients simultaneously and allocate them to a particular clinician with a single action. 

117. Macros. Consider enabling users to implement “macros” - user-defined combinations 

of multiple interaction steps - to automate frequently performed actions. 

118. Interoperability. Enable the EHR to share data with other systems when it promises to 

reduce clinicians’ workload and data entry and retrieval tasks that otherwise might be 

vulnerable subject to use error.

119. Integration with billing system. Indicate whether a particular procedure, prescription 

formulation, or diagnosis is likely to be rejected by a patient's insurance.
Technical Basis for User Interface Design of Health IT

71

120. Logging in. Limit the effort required to log into the application, considering that users 

might need to do so dozens of times per day. For example, limit the number of steps 

required.

121. New patient records. Enable users to create a new patient record rapidly to facilitate 

urgent or emergency care, such as might be delivered to a newborn baby. Enable nonessential inputs to be omitted, albeit after indicating that some fields have been left 

blank and confirming it was the user’s intention.

122. Recurring orders. Enable users to enter recurring orders, rather than requiring them to 

re-enter all portions of new but identical orders. 

123. Consolidated information. Eliminate or limit the need for users to view many screens 

to gather the information necessary from multiple screens to perform high-priority tasks. 

Requiring users to view many, rather than one screen, to acquire the information 

necessary to accomplish a task can lead users to overlook key information and/or 

forget it while performing intermediate information collection steps.

Error Prevention, Detection, and Recovery

124. Safety checks. Build-in safety checks when erroneous or detrimental user actions 

(prescribing two drugs that have harmful interactions, prescribing a dose that exceeds 

norms) could lead to harm. For example, alert the user to unusual (i.e., outlier) 

medication orders.

125. Dependence on memory. Minimize or eliminate the need for users to remember 

critical numbers (e.g., blood glucose reading)

126. Confirmation. Require the user to confirm or cancel patient safety-related inputs and 

important, irreversible actions. Do not automatically dismiss the confirmation message 

after a period of time.

127. Extensive confirmations. In cases where users are about to perform a particularly 

critical action, consider requiring a confirmation action. For example, require users to 

re-enter their account password before deleting a patient account or re-entering a dose 

amount before ordering a medication delivery.

128. Error message appearance. Ensure that error messages have a distinct appearance 

that reliably draws the users’ attention.

129. Error message visibility. Ensure that critical error messages, or direct links to them, 

will remain visible rather than become covered-up by other information (e.g., overlaying 

window), contained within a collapsed window, or otherwise not in view.

130. Error message wording. Provide plainly worded messages that adequately explain 

the error condition without introducing unnecessary details. Do not present error 

messages using codes (e.g., E-45) that must be memorized or understood by referring 

to another resource (e.g., instructions for use). Provide clear recovery instructions to 
Technical Basis for User Interface Design of Health IT

72

resolve the given problem, or perhaps instruct the user to contact technical support. 

State error messages in a neutral tone that does not place blame on the user, but 

rather provides an objective statement about the error that occurred and how to recover 

from it.

131. Error recovery. Provide users with the information and mechanisms necessary to 

recover from use errors immediately upon error detection, and perhaps after 

considerable time has passed since the error occurred. For example, give users the 

ability to immediately “undo” an incorrect action and, later on, change a previously 

submitted order.

132. Undo function. Enable users to undo an action. This capability will enable users to 

explore (i.e., try-out) application capabilities more freely without concern for taking 

irreversible steps. It will also enable users to check their work and correct mistakes.

133. Automation. If the EHR can fully resolve an error without user action, then it should 

not ask the user to do so (e.g., rather than displaying a pop-up error message 

instructing the user to open the Summary tab, the interface could simply open the 

Summary tab for the user).

134. Mode sensitivity. Present users with options that are operational mode-appropriate. 

For example, when prescribing medication to a pediatric patient, present medication 

dose options that are appropriate to children rather than adults.

135. User roles. Restrict user permissions (i.e., ability to modify and access certain data 

and functions within the application) based on user roles. For example, do not enable a 

medical assistant to sign off on a lab result. 

136. Use of defaults. Avoid the use of default values when there is a significant risk of harm 

arising due to inappropriately accepting a default value (e.g., accepting a default 

medication dose intended for an adult when treating a child). Otherwise, pre-fill fields 

when there is an especially common input value.

137. Reset. Enable users to return settings to previous and/or default settings except where 

such actions are contraindicated due to an associated risk.

138. Aged data. Do not display data that has aged to the point that it is no longer pertinent 

to, or could actually interfere with, safe and effective medical care. Such data could be

stored in an archive and be available by request.

139. Updated/synchronized information. Present up-to-date (i.e., time-synchronized) 

information at a rate that ensures it remains useful and does not conflict substantially 

with other displays of the same information. At a minimum, indicate when information 

has aged to the point that it could compromise clinical decisions if actual conditions 

(e.g., vital signs) have changed. Limit the speed at which values update so that users 

can read them before they change to a duration matched to the reading task.
Technical Basis for User Interface Design of Health IT

73

140. Auto-saving. In cases where the user is entering non-safety-related data, 

automatically save data as the user enters it into the EHR, thereby preventing the 

deletion of information if users inadvertently navigate to another tab. 

141. Data importing. Inform users when they must take action to import data from an 

external system or website into the EHR. For example, inform users that they must load 

an external drug library before they can use the EHR’s dose calculation settings. 

142. Date formatting. Where possible, utilize a date presentation format that explicitly 

distinguishes between the day and month (e.g., 12-Jun-2013).

143. Duplication. If the user attempts to add data that already exists in the EHR (e.g., 

adding a duplicate patient chart or medication order), inform the user of the potential 

duplication. 

144. Information sources. Provide a means for users to identify the source of information 

that was not generated locally (e.g., test results received from a third party or copied 

from an external source).

145. Information suppression. Indicate when information (e.g., a new message) has been 

suppressed (i.e. hidden from view) so that users remain aware of it, and provide the 

means to display it quickly.

146. Medication names. When presenting medication names in the medication order, 

display both the brand and generic names. 

147. Order status. Clearly indicate the status of medication orders (i.e., whether a 

medication has been ordered or administered)

148. Original data. When it facilitates a task, display original data at the same time that 

replacement data is entered and until the user confirms the replacement data. For 

example, when a user reschedules a patient visit, display the original visit date until the 

user confirms the new date. 

149. Patient selection. Require users to load a patient chart by explicitly selecting a patient 

(e.g., clicking on a patient name in a list of patients). Avoid implicit means of loading a 

patient chart, such as clicking a "Next" button to load the subsequent patient in the 

patient list, to prevent inadvertent patient selections.

150. Pre-processed information. Pre-process information for presentation to users in a 

directly useful form. Do not require users to decode or mentally manipulate the 

information in complex ways to make it useful. For example, an EHR should perform 

mathematical calculations for the user when the necessary data is available. As 

another example, an EHR could present a user with a list of priority tasks distilled from 

a longer list of pending tasks. Pre-processing information reduces user workload and 

eliminates opportunities to commit use errors (e.g., incorrect calculations, forgetting to 

perform a task). Meanwhile, it might be appropriate to present users with raw data 
Technical Basis for User Interface Design of Health IT

74

along with the processed results to ensure a full understanding of the given condition or 

situation.

151. Recovery timeout period. After users perform destructive actions (e.g., deleting a 

patient profile), provide a “recovery” period during which they can recover deleted 

content. For example, enable users to recover deleted messages within the 24 hours 

following the deletion of a message.

152. Rounding of numbers. Ensure that rounding of numbers cannot result in the loss of 

valuable precision. 

153. AM/PM. When presenting times using a 12-hour format, make the AM/PM indication 

prominent on clocks and timestamps that serve safety-critical purposes. In particularly 

critical displays, consider adding reinforcing text, such as “Morning,” “Afternoon,” 

“Evening,” and “Night.”

154. Pop-up location. Pop-up elements (e.g., dialog box) should not cover safety-critical 

information or information necessary to respond appropriately to the pop-up.

155. Scrolling. Do not require users to scroll to see safety-critical information and controls.

Feedback

156. Scheduling. Perform automatic checks to prevent schedule conflicts.

157. Use of feedback. Indicate when the EHR is “working” on a task that will not be 

completed in what users would perceive as an instant. For moderate-length tasks (e.g., 

a task consuming 5 to 60 seconds), show progress in accurate increments. For longer 

tasks (e.g., a task consuming 1 minute), consider also displaying the amount of time 

remaining before the task will be complete. Adjust the time frames to best suit user 

perceptions, such as those that might be expressed in a usability test. 

Figure 3-23: An example of a data import progress indicator.
Technical Basis for User Interface Design of Health IT

75

158. Confirmation of user actions. Inform the user when their actions have been detected 

by the EHR. For example, if the user saves changes to a patient chart, provide a clear 

indication that the changes have been saved successfully. 

159. System response time. Ensure that the EHR responds to user inputs rapidly (e.g., 

within 0.1 second) so that users perceive the response as immediate. Perceptibly 

immediate system responses will help prevent users from committing double key 

presses and becoming irritated by delayed system responses.10

160. Pop-up windows. Reserve pop-ups for situations requiring prompt user intervention. 

When presenting pop-up windows that require prompt user intervention, disable other 

portions of the user interface, so that the user cannot proceed to use the EHR until 

taking action with the pop-up window. 

161. Updated/synchronized information. Indicate when displayed information has been 

updated dynamically, such as when the EHR receives updated data from a connected 

patient monitor or when another user updates information in the EHR. For example, 

highlight newly updated information or present a prompt that informs the user about the 

information having been updated. 

162. Deletions. Provide users with an immediate confirmation when content has been 

successfully deleted.

163. Interoperability. Provide confirmations that data exported from the EHR has been 

successfully sent to and/or received by the target system. For example, confirm that a 

pharmacy successfully received an electronically transmitted prescription.

164. Touchscreen button response. Touchscreen buttons should respond immediately, as 

perceived by the user, to a touch. The response may be to change appearance as well 

as actuate the associated function, thereby following a “touch down” control approach. 

Or, the response may be to change appearance to indicate the “down” state but not 

actuating the associated function, thereby following a “lift-off” control approach. The 

latter approach allows users to slide their finger off a button to release it without it 

actuating the associated function.

165. Use of sound. Do not rely solely on sound alone to provide users with essential 

information and feedback because some users might mute their computer’s speakers 

or might have a hearing impairment (e.g., conditions that reduce the perceived volume 

of sounds and make high frequency sounds inaudible) that interfere with their ability to 

perceive the feedback.

External Consistency

166. Consistency with for example, medical devices. Explore opportunities to optimize 

consistency for example, with medical devices that users might use in conjunction with 

 10 Source: http://www.nngroup.com/articles/response-times-3-important-limits/.
Technical Basis for User Interface Design of Health IT

76

the EHR. For example, arrange vital signs in a manner that is similar to the 

arrangement on a typical patient monitor. 

167. Consistency with legacy EHRs. Avoid non-essential design changes that introduce 

unnecessary inconsistencies between the EHR and legacy EHRs (i.e., previous 

versions of the same EHR). Limit the frequency of user interface changes so that the 

EHR meets users’ established expectations, and notify users when changes have been 

implemented. However, discard suboptimal legacy design features when they become 

a liability; a threat to EHR use-safety and effectiveness.

168. Cross-platform consistency. If the EHR can be accessed using different types of 

computers (e.g., desktop computer, laptop computer, tablet, smartphone), ensure that 

the user interface on each platform is consistent in essential ways with the user 

interface on the other platforms. 

169. Operating system software conventions. Follow software user interface design 

conventions common to the EHR’s operating system (e.g., drag bottom-right corner of 

a window to re-size it, enable users to use the tab key to jump among data entry fields) 

to the extent that they help users learn to use EHR in a safe, effective, and efficient 

manner.

170. Uncommon controls. Avoid using novel or proprietary controls when a conventional 

control provides similar functionality. Use novel controls only in cases where they 

enhance the EHR's usability or use-safety. For example, it may be appropriate to 

implement a specialized control that requires users to confirm a medication order by 

gesturing a particular pattern on the screen. 

171. Keyboard and mouse behavior. Make sure the EHR responds to keyboard and 

mouse behaviors in a manner that is consistent with established conventions (e.g., 

right-clicking on the mouse shall cause a contextual menu to appear). 

172. Keyboard shortcuts. Avoid using keyboard shortcut combinations that might conflict 

with established keyboard shortcuts commonly used in other applications. 

173. Vital sign color coding. For example, follow medical device conventions for color 

coding vital sign related information.

174. Date and time. Present the date and time with information for which aging is a relevant 

factor, such laboratory reports and vital signs. Present time in the conventional, 

regional format, which might employ a 12-hour clock (whereby mid-afternoon would be 

3:00 pm) or a 24-hour clock (whereby mid-afternoon would be 15:00). Ideally, present 

the date in a manner that explicitly distinguishes between the day and month (e.g., 12-

Jun-2013). Alternatively, present the date in the conventional, regional format, which is 

month/day/year (e.g., 12-25-15) in the USA and day/month/year (e.g., 25-12-15) in 

some European countries, for example. 
Technical Basis for User Interface Design of Health IT

77

Information Density

175. Content density. Present information and controls more densely on a single screen 

when it is more helpful to present it in one place rather than many places, eliminating 

the need for users to search for information and controls on other screens. This 

objective is particularly important when presenting information in a table, graph, or 

chart that should be viewed in its totality to identify patterns and anomalies. Even 

though about 20%-30% [1] blank space can improve information readability and a 

screen’s visual appeal, these benefits can be outweighed by the benefit of viewing 

closely-related information on a single screen.

176. Information spacing. Space information apart to make it easier to read and keep it 

from looking cluttered. For example, maintain a margin between the side of a window 

and the information contained within it, and maintain a minimum distance between 

adjacent icons. Such blank spaces, which are also called padding and gutters usually 

give a user interface a more pleasing appearance.

Internal Consistency

177. Consistent controls. Ensure that controls serving similar purposes (e.g., expanding a 

menu) have a consistent appearance and behavior throughout the EHR. 

178. Consistent cursor behavior. Ensure that cursor behaviors (e.g., cursor changes due 

to roll-overs or mouse clicks) are consistent throughout the EHR. For example, when 

the user places the cursor over a button, the cursor icon should change from an arrow 

symbol to a pointing finger symbol. 

179. Consistent layout. Ensure that different screens within the application present content 

in a consistent and appropriately similar arrangement. 

180. Consistent icons and graphics. Ensure that icons with the same meaning have an 

identical appearance. 

181. Consistent terms. Use consistent terms in all text-based content including instructions 

(i.e., prompts), screen titles, data entry field and button labels, and status messages. 

Consistent terms can reduce the burden on users to learn and recall EHR-specific 

terms and eliminate uncertainties that might arise from the use of different terms to 

describe the same thing.

182. Consistent sentence structure. Use consistent sentence structure in all text-based 

content, including instructions (i.e., prompts), screen titles, data entry field and button 

labels, and status messages.

183. Information format. Display similar information in a similar manner throughout the 

user interface.
Technical Basis for User Interface Design of Health IT

78

184. Transient elements. Display transient elements, such as pop-ups, in a consistent 

location so that users come to anticipate where they will appear and recognize their 

functions based on their locations. 

Language

185. Familiar terms. Use terms that are familiar to the intended users and in common use. 

186. Distinct terms. Avoid using terms that are synonymous and might be confused for one 

another (e.g., “Patient Encounters” and “Patient Visits”). 

187. Jargon. Avoid the use of computer science (i.e., programmer) jargon that is likely to be 

unfamiliar to the intended users. Conversely, it is acceptable to use medical jargon 

(e.g., STAT, which means immediately) that will be familiar to the intended users.

188. Invented terms. Avoid or limit the use of invented (i.e., made-up) terms because they 

can burden users with having to learn and remember them and the terms can be 

subject to misinterpretation.

189. Slang. Avoid the use of slang (e.g., “pulled chart”), which is distinctly more casual than 

medical jargon, because some users might not be familiar with it.

190. Abbreviations and acronyms. Limit the use of abbreviations and acronyms to those 

familiar to, and conventionally used by, the intended users.

191. Definition of abbreviations and acronyms. Provide users with access to definitions 

of the abbreviations and acronyms used by the EHR.

192. Truncation. Do not truncate information, such as drug names and patient names.

193. Concise wording. Write concise text passages to accelerate information acquisition by 

minimizing the amount of reading required. 

194. Names. Ensure that names, such as those used to describe laboratory tests, are 

sufficiently descriptive and distinctive so as to prevent confusion and selection errors.

195. Ambiguous status indications. Avoid using generic labels that might not clearly 

convey the intended information. For example, present the label "Order: Not delivered" 

instead of "Order: No", which might be misinterpreted by the user. 

196. Localization. Enable users to switch the EHR's language to match their preference 

among the available, regionally-appropriate options.

197. Paragraph breaks. Separate what otherwise would be large text blocks into smaller 

ones using paragraph breaks (e.g., a breaks every 3-4 sentences) to enhance text 

readability. Users are prone to only scan or skip reading long paragraphs. 
Technical Basis for User Interface Design of Health IT

79

198. Use of term “exit". Limit the use of the term “exit” to cases when the EHR will close in 

response to a control option labeled “exit.” Using the term for other purposes can raise 

concern among users that they will exit the application altogether, as opposed to 

existing a particular window, for example.

Metaphor

199. Use of metaphor. Employ metaphorical user interface features (e.g., tabbed pages, 

patient chart, calendar, address book, dashboard) when most users will have real world 

experience that makes use of a given metaphor advantageous, such as making certain 

interactions (e.g., moving to a new page) more intuitive.

200. Metaphorical consistency. Apply metaphors consistently and completely so that user 

interface behaviors (e.g., how the pages turn within a multiple page document) are 

predictable, complemented by appropriate, metaphor-compatible terminology. For 

example, it would be appropriate to open and close a drawer in conjunction with filing 

documents in a metaphorical cabinet, but it would not be appropriate to open and close 

metaphorical folder tabs.

Miscellaneous

201. Calendar - level of detail. Enable users to switch between daily, weekly, and monthly 

within calendar-type features.

202. Contact information. Provide users with a convenient means (e.g., phone number, 

email address, text message box) to communicate with other professionals (e.g., 

physician listed in a referral, administrative assistant who schedules patient visits).

203. Information retrieval time. Minimize the time the system retrieve information, thereby 

accelerating user tasks. Tolerable wait times can be as short as two seconds before 

users become impatient and possible cancel the information request.[1]

204. Patient focus. To the maximum extent possible, enable clinicians to focus attention on 

the patient instead of the EHR at key stages of a patient encounter.

Navigation

205. Calendar – return to current day. Provide a means to return immediately to the 

current day within a calendar.

206. Navigation control location. Place screen navigation controls (e.g., “X” button that 

closes an open window) in consistent locations (e.g., upper-right or lower-right 

corners).

207. Navigation control prominence. Make screen navigation controls (e.g., “X” button 

that closes an open window) prominent.
Technical Basis for User Interface Design of Health IT

80

208. Main screen. As appropriate, enable users to form an accurate mental model of EHR 

user interface, as well as rapidly access major EHR features, by establishing a “home 

screen,” which might also be called a “resting screen” or “initial display.” 

209. Returning to main screen. Provide users with a direct means to return to the top of 

the user interface structure (i.e., the home screen). For example, enable users to return 

to the home screen by clicking on an application logo in the upper left corner of the 

screen. 

210. Backing up. Enable users to go back a step except when a previous step must be 

rendered irreversible for logical reasons. Provide a clear means to return to the 

previously viewed screen (e.g., a dedicated “Go Back” button or the web browser's 

built-in back button, if the EHR is web-based). 

211. Browser back button behavior. If the EHR is accessed using a web browser, ensure 

that the browser's back button behaves as expected (i.e., navigating back to the last 

viewed screen). 

212. Menu item order. Navigational menus should be arranged in a logical order based on 

the expected task-flow and/or frequency of use of the included menu items. 

213. Link-destination labeling. Match the names of text links and destination page titles to 

facilitate user interface navigation and to enable users to form an accurate mental 

model. 

214. Screen titles. Add a meaningful, visually dominant title to every screen to help users 

recognize the nature of the displayed information and help them form a clear 

association between selected controls/options and displayed information.

215. Relative location within user interface structure. Indicate the currently viewed 

page's location within the overall user interface structure by displaying a “breadcrumb” 

or similar cue. 

216. Functional grouping of menu and content. Visually strengthen the link between 

navigation buttons and content areas (e.g., use a tab metaphor, animate the transition 

between views to emphasize that the content in the main window originates from the 

view icons).

217. Pagination. Online documents should be paginated (e.g., Page 6 of 30) so that users 

can determine their place in the documents and, in lieu of hyperlinks, find information of 

interest after reading a table of contents or index based on page number. 

218. Tabbing among data entry fields. Enable users to tab (i.e., press the tab key) to jump 

among required fields within a data entry form in a logical order. Within a form that 

generally appears to have rows and columns, highlight input fields starting at the topleft, moving to the right on the given row, and then progressing left side of the next row 
Technical Basis for User Interface Design of Health IT

81

down. Do not tab to protected or inactive input fields that are not subject to input or 

modification.

Patient Identification

219. Patient identification. Provide multiple, parallel, and salient means to correctly identify 

a patient in the system. The need for parallel means stems from the potential for 

patients to have the same name (e.g., father and son) or the same birthdates, which 

could lead users to select the wrong patient based on one variable (e.g., name). 

Possible identifiers include the patient’s name, unique identifying number, age, gender, 

weight, location, and photograph. Such information might be most conspicuous if 

placed at the top of the display or pertinent task window, for example.

220. Patient name. Place the patient’s name prominently (e.g., top-left corner) on screens 

or windows presenting information about a specific patient. .

221. Patient overview. Present a summary of patient information, in addition to the patient’s 

name, when the added information will help identify the patient and/or immediately 

bring key information (e.g., last office visit, last diagnosis, and allergy) to the user’s 

attention.

Figure 3-24: A sample patient overview layout.

222. Patient photograph. Present a patient photograph with other patient information when 

the feature will help ensure reliable patient identification or enhance bedside manner, 

for example. 

223. Linking inputted data and patients. Ensure that there is a strong association 

between data entry controls and the associated patient(s). For example, users should 

be able to clearly associate a patient name with a scheduled appointment.
Technical Basis for User Interface Design of Health IT

82

Search

224. Search availability. Enable users to search for information (e.g., a patient chart) when 

the capability is likely to make information acquisition tasks more productive. Provide 

multiple ways to search (e.g., by patient’s first name, by patient’s last name, by date-ofbirth) to help ensure a successful search.

225. Default search mode. By default, utilize an inclusive search algorithm that searches 

for any (rather than all) of the search terms entered by the user. Enable users to switch 

to an exclusive search mode (which finds only results that include all search terms 

entered by the user) by modifying the search syntax (e.g., including “and” between 

search terms) or by selecting the preferred search setting from a dropdown list. 

226. Patient search. Enable users to access patient information using multiple logical 

methods (e.g., first name, last name, patient hospital ID, admission date, date of birth).

227. Search field. Visually distinguish the search field from other fields in the application. 

For example, utilize shape coding, color coding, or labeling to help users notice and 

identify the search field. 

228. Pre-population of search boxes. Prepopulate search fields with search results to 

accelerate the search task and assist users with searches when they are unsure how 

the item sought is spelled.

229. Special characters. Ensure that search fields accept special characters (e.g., 

apostrophes, symbols, accented letters, etc.). 

230. Suggestions. Provide suggestions for similar searches (e.g., searching for a 

medication using an alternative name) or searches using different spellings (e.g., if the 

software detects that the user misspelled the search term).

231. Similar search terms. Present search results for terms that are similar to the search 

terms entered by the user (i.e., synonyms). For example, enable users to search for a 

bone density scan using the phrases "DEXA scan" or "bone density scan", and to 

search for a thyroid stimulating hormone test by searching for either "TSH" or "thyroid 

stimulating hormone.

232. Specificity. Enable users to enter different types of information into search fields, 

rather than requiring them to enter only one specific type of information. For example, 

enable users to search for different types of orders without having to first specify the 

type of order. 

233. Searched content. Enable users to search for content that exists in the EHR’s 

database, as well as in documents that are accessible through the EHR (for example, 

text files, PDF documents, and spreadsheets).

234. Number of search results. Provide a clear indication of the total number of search 

results. 
Technical Basis for User Interface Design of Health IT

83

235. Filtering. Enable users to filter search results by adjusting search settings after 

performing an initial search. 

Security

236. Screen locking. Enable users to lock screens when there is a safety or privacy-related 

risk associated with unauthorized access to the EHR. Also, consider providing a means 

to access EHR functionality in an urgent situation or emergency without entering a 

password.

237. Overrides. Enable users to override system protections when there are use cases that 

call for them to have full freedom to perform certain tasks, such as ordering a 

medication that might normally be contraindicated. In such cases, ensure that the user 

has the credentials to override the system and require the user to confirm the exception 

and enter a justification.

238. Unauthorized functions. Hide functions from users who are not authorized to use 

them, or alter their appearance in a manner that indicates that the functions are 

unavailable (e.g., display them grayed-out).

239. Privacy. Incorporate features that help to ensure the privacy of patient information, 

thereby satisfying governmental and institutional rules (e.g., HIPAA, local hospital 

policies) and user preferences. 

Status Indication

240. Status indication. Keep the user informed in a timely manner and by appropriate 

means (e.g., alerts, pop-up messages, status bar, activity tracking window) about the 

system’s status (e.g., the system’s readiness to receive inputs, the time remaining to 

complete a task, system connectivity, data transfer progress).

241. Status description. Provide unambiguous status indications. For example, regarding 

the status of a lab test order, use terms such as “pending” or “completed” rather than 

“no” and “yes.”

242. Mode indication. Conspicuously and persistently indicate the EHR's operational mode 

(or equivalent operational state) when there is more than one (e.g., adult patient mode 

versus pediatric patient mode).

243. Multi-user collaboration. If the EHR can be used by multiple users simultaneously, 

provide an indication when other users are viewing or editing the displayed information.

User Support

244. Non-reliance on memory. Provide users with the information needed to make 

decisions and take action. Prompt users to perform necessary tasks. Do not rely on 

them to recall information and to take critical actions.
Technical Basis for User Interface Design of Health IT

84

245. Procedural guidance. Guide users through unfamiliar, difficult to remember, and/or 

infrequently performed procedures (e.g., lead users through a linear sequence of 

steps).

246. Prompts. Provide detailed task prompts when there is only one or a small number of 

tasks that users may perform at a given stage of user interaction with the EHR. Provide 

a more general prompt if the task options are many and yet it will help to inform he user 

that the system is waiting for them to take action. Place prompts in a consistent location 

on the screen where users will become accustomed to looking for instruction, or in 

close proximity to the pertinent onscreen content, such as information contained in a 

window. Prompts should remain on the screen until the user takes appropriate action.

247. Contextual support. Where possible, provide guidance within the user interface itself, 

rather than requiring users to access a separate learning aid. 

248. Online help. Provide online help regarding topics for which there might be a need for 

immediate and concise guidance to complete a task. Limit online help to content that 

will help users understand basic operations and complete key tasks safely and 

effectively. Separately, provide users with access to a complete source of guidance 

(e.g., user manual) that might be necessary for users to develop a deeper 

understanding of certain EHR features of particular interest. Where possible, offer 

users context-sensitive help, taking them initially to online help content that is likely to 

be of interest given the task underway at the time the user seeks online help. Give 

users a direct means to return to a prior task after consulting the online help.

249. Access to technical support. Provide users with the information necessary (e.g., 

hotline phone number, email address) to contact technical support.

250. Tooltips. Complement icons and buttons with tooltips (or an equivalent) that explain 

the feature.

251. Clarifications. Augment screen titles, prompts, and similar affordances with even more 

clarifying information when necessary, and perhaps upon request, to ensure that users 

understand how to perform tasks.

252. Context. Provide users with a sense of the task at hand by various means, such as the 

series of recent selections (i.e., a “bread crumb” trail or action history) or a checklist 

showing the steps completed versus remaining.

253. Failure indications. Indicate when the EHR has failed or its functional capabilities 

have compromised.

254. Links to external resources. Indicate when a control action will take the user outside 

of the application, such as to a separate website that provides background information 

about a medical condition. In addition, provide a clear means for returning to the 

application from the external resources. 
Technical Basis for User Interface Design of Health IT

85

255. Meaningful text links. Use meaningful text as links (aka hyperlinks) so that users 

understand where they will go (i.e., what they will see at the destination point) when 

they click on the link.

256. User feedback. Provide users with the means to provide feedback to the EHR system

administrator (or equivalent) regarding what they judge to be hazardous and/or 

ineffective EHR characteristics and software “bugs.”

257. Diagnosis code search. When appropriate, provide clinicians with diagnosis code 

suggestions based on the patient's problem list and order placed. For example, if a 

clinician creates an order for Metformin, suggest diabetes-related ICD codes. 

Visual Design - Color

258. Use of color. Use color in a meaningful way, such as to code certain information (e.g., 

red = abnormal lab value) and to draw attention (e.g., display alert information as black 

text on a light orange background). Color code misinterpretations are more likely when 

there are more than eight colors with coded meanings that users must recall.[1]

259. Accommodating color blindness. Do not rely on color alone to draw attention to or 

visually differentiate critical information, particularly because some users might have 

impaired color vision (e.g., Deuteranope, which makes red and green objects look 

similarly gray). For example, not only display abnormal test result in red text and 

numbers, but also display them in reverse video (e.g., white numbers against a red 

background).

260. Use of conventional colors. Use colors in a manner that matches user population 

conventions (e.g., use red in the USA to indicate a dangerous situation or condition).

261. Use of alarm-related colors. Use alarm-related colors (e.g., red and yellow) only for 

critical, urgent indications. Ensure that the color use matches applicable standards for 

alarms and medical applications. 

262. Color saturation. Avoid using highly saturated (pure hues rather than colors that 

include some amount of gray) color backgrounds except where they serve a definitive 

purpose, such as drawing the user’s attention to safety-critical information.

263. Visual contrast. Ensure that onscreen content (e.g., text, numbers, icons, lines) 

contrast appropriately with their backgrounds. For example, very dark content (e.g., 

dark blue or black text) contrasts well with a light background (e.g., white or light gray 

data entry field). Medium brightness content (e.g., text, numbers, waveforms) and their 

backgrounds do not afford good contrast with each other, even when the colors vary. 

Contrast between foreground contents and their backgrounds should be at least 6:1 

and ideally closer to 10:1. 

264. Highlighting. Highlight important information (e.g., make it bigger, color it, separate it 

from other information) so that it draws the user’s attention. Lacking such highlighting, 
Technical Basis for User Interface Design of Health IT

86

users might overlook important information that is embedded within less important 

information.

265. Highlighting changes. Visually highlight recent changes to information sets, such as 

medication orders, diagnoses, and appointments.

Visual Design - General

266. Aesthetics. Follow fundamental rules of design pertaining to screen layout, proportion, 

color, typography, and other visual design attributes to produce an aesthetically 

pleasing user interface. Note that appropriately aesthetic solutions tend to be more 

usable than those that look unappealing, and can increase user satisfaction with an 

EHR. However, do not compromise the safety and effectiveness of the user interface 

design for the sake of enhanced aesthetics.

267. Unnecessary decoration. Do not add decorative visual features and effects (static or 

dynamic) that could compromise the EHR's use-safety, utility, and usability. 

268. Functional grouping. Visually demarcate functionally related information (e.g., 

separate one block of related information from another using a borderline or blank 

space).

269. Information alignment. Place information in a format that facilitates rapid scanning. 

For example, left-justify the labels in one column (or right-justify them if the label string 

lengths vary substantially) and left-justify the associated information in an adjacent 

column. Avoid arranging labeled information (e.g., Patient name: Jones, Thomas 

Weight: 185 lbs. Height: 74 inches) in what appears to be a paragraph with several 

chunks of text and numbers.

270. Screen layout. Present critical information in the most prominent location in the most 

prominent location on the screen. 

271. View simplification. Give users the opportunity to temporarily dismiss or hide 

distracting and/or unnecessary information, but only if it does not contain essential 

information and controls.

272. Label appearance. Make labels visually subordinate to the related information (i.e., 

make the information stand out more). For example, presuming a light gray 

background, make label text medium-dark blue and associated parameter values black.

273. Menus. Display all menu options in a single view, excepting cases in which secondary 

(i.e., cascading, branching, multi-level) options may be shown or hidden (i.e., 

collapsed). Place the menu options in a logical order based on function, frequency of 

use, or (lastly) name (i.e., place in alphabetical order). Ensure that all options logically 

belong in a given menu so that misplaced option does not disrupt the users’ mental 

model of the menu structure or frustrate a user’s search for it in other locations. 
Technical Basis for User Interface Design of Health IT

87

274. Menu selection. Utilize a distinct visual styling to distinguish the currently selected 

menu option from the unselected menu options.

275. Disabled functions. Visually differentiate functions that are available from those that 

are unavailable. For example, if certain controls appear “grayed out,” no other onscreen 

elements, and particularly no active functions, should have the same grayed-out 

appearance or similar appearance.

276. Active links. Present active links using a single, distinct, and exclusive visual style. 

Avoid using this same visual style for presenting static text. 

277. Tabs. Give tabs an appearance that is distinct from adjacent and similar objects (e.g., 

buttons).

278. Table cell sizing. Avoid making table cells unnecessarily tall or wide such that a large 

table requires extensive scrolling. In browser applications, limit the degree to which 

column widths will expand for no purpose, for example. Conversely, ensure that table 

cells are sufficiently large to display complete entries rather than truncate them.

279. Table columns. Ensure that all table columns are visible when possible. If a column 

cannot be displayed due to space constraints, provide a conspicuous indication that 

additional information is available outside the visible area.

280. Table rows. Make table rows visually distinct (e.g., color or shade every other row) to 

help users keep their place within the table.

281. Table sorting. Enable users to sort tabular data per the contents in particular columns, 

in ascending or descending order. For example, enable users to sort a table by patient 

name by clicking on the name column. 

282. Browser window size. Do not allow users to shrink windows beyond the point that 

essential information remains visible.

283. Unit placement. Place units of measures near the associated parameter value. 

Common placements are to the immediate right or below the values. However, they 

may also be placed in parentheses to the right or below the parameter title, which itself 

may ideally be placed above the numerical values. Each of these placements helps to 

ensure that users will properly associate the values and units of measure. However, 

make sure to include sufficient space between the unit of measure and the associated 

parameter value to avoid reading errors due to the visual interference that can arise 

due to overly close spacing. 

284. Overlapping layers. Do not overlap information except in cases where overlapping 

reinforces a desirable visual effect (e.g., stacked pages/windows); in which case there 

should be a strong overlap effect (e.g., distinct boundary line, drop shadow). 
Technical Basis for User Interface Design of Health IT

88

285. Window transparency. Avoid making overlapping layers (e.g., windows, pop-ups) 

transparent to the point that it significantly reduces the legibility of content on the top 

layer.

286. Window background. When displaying pop-up windows, consider “graying-out” or 

darkening the background content to make the pop-up window's content more 

prominent.

287. Distinguishing different screens. Incorporate visual design differences to distinguish 

between screens that serve significantly different functions. For example, color code 

patient-related screens with a light blue background and scheduling-related screens 

with a light green background. 

288. Headings and titles. Distinguish screen headings and titles from other on-screen 

content using color, bolded typefaces, or large font sizes. 

289. Differentiation from browser. Visually distinguish the EHR user interface and 

particularly its associated toolbars from the enclosing browser or operating system 

controls. 

290. Scroll bar visibility. Do not "hide" scroll bars or otherwise require users to discover 

them.

Visual Design - Graphics (i.e., icons, symbols, charts)

291. Symbols with conventional meaning. Use symbols (e.g., icons) that have a 

conventional meaning (e.g., magnifying glass representing a search capability) to 

convey only those meanings and not others. Otherwise, users might experience 

negative transfer, leading them to assign the conventional meaning to an icon that the 

given EHR uses to convey a different meaning. 

292. Icon appearance. Size icons so that the salient details that are important to correct 

interpretation are legible from the maximum, intended viewing distance. 

293. Icon composition. Compose individual icons from as many common elements as 

possible to minimize the number of visual details users must recognize or learn (i.e., 

limit the visual vocabulary), while also ensuring sufficient distinctiveness among the 

icons.

294. Icon design. Harmonize the appearance of icons rather than presenting users with 

variously styled icons. Design variables subject to harmonization include size, aspect 

(height to width ratio), degree of abstraction, level of detail, use or color, line style, and 

2D versus 3D appearance. Generally, representative (i.e., realistic) icons are superior 

to abstract ones because users are more likely to assign correct meanings to 

representational ones, while they might have to guess at the meaning of abstract ones 

other than those already in common use (e.g., red octagon meaning “stop”). 
Technical Basis for User Interface Design of Health IT

89

295. Icon dissimilarity. Make icons sufficiently dissimilar looking so that one will not be 

confused with another. Significant differences help users tell icons apart (i.e., 

disambiguate). 

296. Icon size. Make icons sufficiently large to ensure that their content is legible and 

understandable.

297. Icon style. Harmonize the appearance of functionally related icons (e.g., open 

window/close window, adult patient/pediatric patient). Visually harmonious icons may 

have the same size, degree of simplification (i.e., abstraction), level of detail, line width, 

and color saturation, for example.

298. Complementary text labels. Complement icons with text labels or tooltips that clarify 

the icon's meaning. 

299. Branding. Keep vendor brand content from having a negative effect on the EHR's 

safety, effectiveness and usability. For example, while a login window might be heavily 

branded, including the vendor’s logo; other pages might only employ a colored frame 

linked to the vendor brand and eliminate other branding details (e.g., logos, tag lines) in 

favor of leaving more space for useful content.

300. Data visualization. Present data in graphical formats (e.g., parameter value vs. time) 

when it will communicate essential information (e.g., trends, overall conditions) faster 

than a table of numbers, for example.

301. Graph axes. Display a graph’s axes labels, including units of measure and graduation 

marks as appropriate, at all times.

302. Graph axis range. If graph axes ranges are set automatically by the EHR, ensure that 

the ranges are set to realistic values for the displayed parameter. For example, an axis 

on a graph of body mass index (BMI) values should range from 5 (the minimum likely 

value) to 60 (extremely obese) containing normal range hard axis lines at BMI 15 and 

BMI 30.

303. Graph color coding. When presenting multiple trends on a single graph, avoid relying 

only on color coding to distinguish between the different trends. Utilize distinct symbols 

as data points (e.g., square, circle, triangle) to differentiate between the different 

trends. 

304. Graph information. Augment graphs with helpful information including meaningful 

titles, axes labels, symbol keys, and other supplemental information that will facilitate 

information acquisition and decision-making. 

305. Graph options. Enable users to graph selected parameters when this capability is 

necessary to support clinical analysis and decisions.
Technical Basis for User Interface Design of Health IT

90

306. Graph size. Ensure that graphs are sufficiently large, or can be viewed at different 

resolutions for example, so that users can extract the necessary data, such as the 

value of a vital sign at a certain point in time. Do not reduce the size of graphs to the 

point that they become unreadable, except when the graph will serve simply as a 

thumbnail suitable for enlargement to a readable size.

307. Legend. Where appropriate, provide a legend (aka key) that defines the meaning of 

icons and other symbols used in the EHR. 

308. Normal range(s) on graphs. Indicate the normal range for the data shown on graphs.

309. Precise values of plotted data. Give users the means to determine the precise value 

of plotted data points, such as hovering over a particular data point to produce a popup presenting the value.

310. Time frames of graphs. Display graphs at a default scale that is optimal for data 

analysis. For example, an adult patient’s weight might be best displayed on a graph 

showing weight change over many years whereas a child’s weight graph might be best 

displayed on a graph showing weight change over many weeks or even days.

311. Toggle ambiguity. Take steps to avoid toggle ambiguities; cases in which there is a 

choice of two settings (i.e., states) and it is difficult to determine which one is selected 

based on the appearance of the settings. Ambiguity often arises because users cannot 

determine if a highlight option is already selected or available for selection. One 

solution is to add visual detail (e.g., checkmark) to indicate the selected (i.e., currently 

active) option. 

312. Trends. Display (or give users the option to display) trends among appropriate 

parameters when projections can be helpful. Clearly differentiate actual and projected 

values.

313. Icon conventions. Use icons in a manner that is consistent with established 

conventions (i.e., avoid using familiar icons to represent concepts or actions that they 

do not typically represent). For example, do not use an icon of an envelope to 

represent a search function, because users will likely associate the envelope icon with 

a messaging-related functionality.

314. Charting by exception. Enable users to “chart by exception,” whereby they can 

information update a data set by recording only the values that have changed since the 

last update. This approach should reduce clinicians’ workload, reduce the chance of 

data entry errors, and enable users to focus on correctly entering fewer values.

315. Consistent scales. In cases where users might be comparing trends across multiple 

charts (e.g., comparing multiple children's growth curves), present the different charts 

using a consistent scale and axes to facilitate an accurate comparison between the 

graphs.
Technical Basis for User Interface Design of Health IT

91

Visual Design - Typography

316. Information distinctiveness. Present specific types (i.e., categories) of information in 

distinctive forms so users more readily recognize their purposes. For example, present 

interaction instructions and clinical information in different forms. Possible ways to 

differentiate text, for example, include font (i.e., typeface), size, color, background, and 

paragraph width. 

317. Text and number sizes. Ensure that text and numbers are legible from the expected 

viewing distance (e.g., 18 inches away from a display). They should subtend a visual 

angle of at least 16 minutes of arc and optimally 20-24 minutes of arc from the 

maximum expected viewing distance to be accommodated. Note that some EHR 

content might be viewed at an arm’s reach from the computer monitor while other 

content might be viewed from the opposite side of a hospital bed.

318. Text formatting. Utilize text formatting (e.g., bold, large, or colorful text) to highlight 

critical details and important information. 

319. Text style. Limit variations in text style (e.g., font, boldness, italics, underlining) to a 

minimum. Generally, use a sans-serif typeface (e.g., Arial, Futura, Helvetica, Verdana) 

to avoid legibility issues that might arise with the use of typefaces with embellishments, 

which usually take the form of short lines extending from the ends of the lines that form 

the letters. Be sure that the text style ensures clear distinction between all letters and 

numbers. For example, there should be distinct difference in the appearance of the 

numbers “1” and “7.”

320. Capitalization. Indicate how text entries should be capitalized when capitalization is 

important. Otherwise, do not require users to use a specific type of capitalization when 

entering data. Also, limit the use of capitalization to highlighting information, for 

example, because reading time can increase when the words in sentences are fully 

capitalized.

321. Decimal point. Format decimal points to ensure they are highly visible. Formatting 

options include oversizing the decimal (e.g., make it many times larger than the dot on 

a similarly sized letter “i”) 

322. TALLman letters. Where helpful at differentiating similar looking drug names, Use 

TALLman letter that highlight in capitals letterforms the distinctive letters within the 

name (e.g., chlorproPAMIDE, chlorproMAZINE).

323. Line spacing. Ensure that the descenders (i.e., the bottom parts of lowercase letters 

such as “g”) from one line of text are separated from top of the letter in underlying text 

by enough space to ensure text legibility.

324. Anti-aliasing. Ensure that all text has a “crisp” anti-aliased setting to prevent the 

appearance of blurred text that users might struggle to read. 
Technical Basis for User Interface Design of Health IT

92

325. Bitmapped fonts. Avoid using bitmapped fonts, which tend to have a pixelated and 

less legible appearance than vector-based fonts. 

326. Data labels. Format data (either static or in input fields) such that it is more prominent 

than the accompanying labels. For example, when displaying a patient's blood 

pressure, utilize a larger and/or bolder font for the current blood pressure value (e.g., 

"120/80 mmHg") than for the accompanying label ("Blood pressure:").

327. Decimal point alignment. Display columnar numerical data in decimal point alignment 

(i.e., with decimal points placed in the same vertical line).

328. Horizontal spacing. Incorporate sufficient horizontal space around displayed text so 

that individual words do not span multiple lines (i.e., hyphenated across multiple lines).

Workflow

329. Workflow. Organize EHR content so that it facilitates a safe, effective, and efficient 

workflows.

330. Consistency with clinical workflow. Explore opportunities to maximize consistency 

between the EHR's workflow and established clinical workflows with which users are 

likely to be familiar. 

331. Role-related workflows. Present workflows that match the user's role (e.g., nurse, 

physician, administrative user) by organizing content and functions to match the 

particular user type’s typical tasks. For example, present nurses with common nursingrelated EHR tasks (e.g., entering patient vital signs) immediately on the EHR’s home 

screen. 

332. Flexibility. Enable users to perform certain tasks in different manners based on their 

preference and/or experience. 

333. Prerequisite actions. Notify the user about prerequisite actions before allowing them 

to start a task. 

334. Task progression. Provide users with the next logical content when they are 

progressing through a multi-step procedure rather than requiring them to return to a 

starting point and then navigating to the next logical content.
Technical Basis for User Interface Design of Health IT

93

335. Procedural steps. Divide lengthy procedures into discrete “chunks” that follow a 

natural workflow. Avoid creating overly minor steps (e.g., separate steps to enter birth 

date and then driver’s license) when a single step could include multiple sub-steps 

(e.g., entering data into several fields on a single window). Indicate progress on a given 

procedure (e.g., checkmark the completed steps in a summary of all required steps 

displayed adjacent to a current task window or in a status bar).

Figure 3-25: An example of procedural steps that give the user an indication of their 

progress through the application.

336. Procedural step numbering. Number procedural steps that should be performed in a 

particular order. Numbering has the added benefit of helping users keep their place in a 

procedure and differentiating procedural information from other types of information.

337. Accelerators. Provide experienced users with the means to accelerate frequent tasks, 

just as long as the accelerators do not complicate tasks for inexperienced users. In 

other words give experienced users shortcuts. Common accelerators are function keys 

and top-level links to frequently selected options (e.g., frequently ordered laboratory 

tests).

338. Reminders. Provide helpful reminders to perform task that might be overlooked, such 

as providing patients with educational materials.

339. Multi-tasking. Enable multi-tasking (e.g., opening two patient charts at a time) where it 

is necessary to complement a safe and effective workflow.

340. Modal windows. Require users to complete tasks presented within a window, such as 

confirming an inputted value, before they can interact with other windows.

341. Multi-user communication. Enable communications (e.g., chatting, email messages) 

with other staff members, or groups of staff members, who use the EHR, and possibly 

those using other systems, as necessary to facilitate effective medical practice. 
Technical Basis for User Interface Design of Health IT

94

342. Printing. Enable users to readily print selected information from various parts of the 

EHR. 

343. Use of external systems. Minimize the need for users to access external systems and 

tools (e.g., web sites, other applications) in the course of EHR use. Seek opportunities 

to incorporate external functionality into the EHR to simplify the user's workflow. 
Technical Basis for User Interface Design of Health IT

95

4 Appendix A: Additional details 

about project activities

4.1 Usability testing of EHRs

In the course of this data collection effort, the research team conducted comprehensive usability 

tests of five EHRs. 

Researchers adopted a formative evaluation test approach given that it would enable a rich flow 

of information about the test participants’ experiences using the selected EHRs while they 

performed the same basic tasks. The testing goal was not to validate the EHRs’ user interfaces, 

but rather to identify their interactive strengths and shortcomings, which could then support the 

development of user interface guidance to optimize an EHR’s user interface.

In 2012, five EHR developers volunteered their EHRs for usability testing in response to a NIST 

announcement that appeared in the Federal Register on February 14, 2012 (Vol. 77, No. 30).

Coincidentally, each of these EHRs was intended primarily for use in outpatient medical 

practices, such as those used in outpatient clinics and physicians’ offices. 

The EHR developers provided access to realistically configured EHRs, supported production of a 

15-35 minute training video, and provided technical support. They had no input into test planning, 

testing, or data analysis. Moreover, none of the developers received data resulting from the test 

of their particular EHR.

Each usability test session lasted approximately two hours; enabling participants to perform up to

of 15 separate, predefined tasks (see listing in section 6.1 – Usability testing tasks). There were a 

total of 15 test sessions per EHR, resulting in a total of 63 participants, including the following:

• Providers (n = 31) 

• Nurses (n = 21)

• Medical assistants (n = 11)

Several two-person teams, each including a test administrator and a data analyst (i.e., data 

logger), conducted the five EHR tests. All test sessions took place in usability test facilities that 

included a test room and adjacent observation room. All test sessions were video recorded. 

Spreadsheets containing the raw usability test data were delivered to NIST. 

Test data included use errors, close calls, difficulties, anecdotal comments about EHR 

interactions and quantitative ratings of the EHR according to a novel scoring system (see section

4.2 – EHR usability scoring system). All test data was de-identified to protect the identities of the 

test participants, EHRs, and test locations. The EHRs were de-identified because the research 

focus was not on the usability of the five sample EHRs, but rather on collecting evidence of EHR 
Technical Basis for User Interface Design of Health IT

96

user interface features that contribute to an application’s use safety and effectiveness, as well as 

usability by extension.

After documenting the test results in standalone documents, researchers “coded” the test data 

according to the methods described in section 4.3 – Qualitative analysis methods. This activity 

produced 777 coded findings that served as an input to the user interface design principles

development effort.

4.2 EHR usability scoring system

As part of the EHR usability testing effort (see section 4.1 – Usability testing of EHRs), the 

research team administered an experimental user experience quality scoring exercise that 

focused on use safety, effectiveness, and usability. 

Readers might be familiar with multiple scoring systems that developers have used for years to 

evaluate the usability of various types of software applications. Perhaps the most widely used 

system is the System Usability Scale (SUS)11, which calls upon respondents to agree or disagree 

to various degrees with the following statements:

• I think that I would like to use this system frequently.

• I found the system unnecessarily complex.

• I thought the system was easy to use.

• I think that I would need the support of a technical person to be able to use this system.

• I found the various functions in this system were well integrated.

• I thought there was too much inconsistency in this system.

• I would imagine that most people would learn to use this system very quickly.

• I found the system very cumbersome to use.

• I felt very confident using the system.

• I needed to learn a lot of things before I could get going with this system.

SUS and other scoring systems inspired the development of an EHR-specific scoring system. 

Initially, researchers wrote 30 statements (10 safety-related), some derived in part from other 

scoring system statements, which could be used to assess an EHR’s interactive quality. Next, 

they drew upon their professional judgment to reduce the list to an arguably more manageable 15

statements (see section 4.2.1 – EHRUS usability scoring system development).

 11 See http://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html
Technical Basis for User Interface Design of Health IT

97

Working within IRB-related restrictions placed on the research, the research team further 

narrowed the list down to the following 11 statements that constituted just a sample of the kinds 

of statements that might be proven to be effective indicators of an EHR’s usability:

• The EHR uses familiar terms, symbols, and units. 

• The EHR makes important information stand out.

• The EHR’s workflows match my expectations. 

• The EHR makes it easy to detect and correct mistakes.

• The EHR gives me a comprehensive view of a patient’s health. 

• The EHR will prevent harmful mistakes.

• The EHR makes it easy to share information with other healthcare professionals. 

• I can use the EHR effectively while working under pressure.

• The EHR is easy to learn to use. 

• I am confident that I can use the EHR to perform tasks correctly.

These statements were not yet evaluated in terms of their construct validity and inter-rater 

reliability. Rather, they were considered suitable for use in the experimental exercise to produce a 

general sense for the value of an EHR-specific scoring system. In view of these limits, the 

researchers administered the exercise to the 62 EHR usability test participants.12

Each usability test participant interacted with one of the five evaluated EHRs, referred heretofore 

as EHRs A, B, C, D, and E. The 5-point rating scale allowed the following levels of agreement 

with each of the statements: 

• 1= strongly disagree

• 2 = disagree

• 3 = neither agree nor disagree

• 4 = agree

• 5 = strong agree

Table 4-1 presents the resulting data. 

 12 One of the 63 usability test participants did not complete the survey due to test administrator 

oversight. 
Technical Basis for User Interface Design of Health IT

98

Table 4-1 Results of EHR usability scoring exercise.

EHR Mean Rating Std. Dev. CV (Coefficient 

of Variance

n (number of 

participants)

A 3.2 1.15 0.36 15

B 2.5 0.94 0.38 15

C 2.9 1.02 0.36 15

D 2.8 1.06 0.38 15

E 3.3 1.16 0.35 15

All 2.9 1.07 0.36 75

The data should be analyzed for trends, and the repeatability of the findings for trend analysis. 

Accordingly, it is not certain that EHR E would emerge as the most usable EHR if the researchers

asked 62 additional participants to perform the scoring exercise, or if there has been a central 

tendency among raters who would give a mid-range rating even to a demonstrably superior EHR.

Notably, the coefficient of variation (ratio of the mean to the standard deviation) of the limited data 

set ranges from 0.35 to 0.38, which suggests modestly good but uncertain inter-rater reliability.

Further research will be required to determine the construct validity and inter-rater reliability of an 

EHR usability scoring system. Such research will need to compare the results of scoring 

exercises to other, credible measures of EHR usability (e.g., task times, error rates, expert 

judgments), as well as other, established usability scoring systems (e.g., SUS). Researchers

might be well served to utilize the full set of 30 statements provided in section 4.2.1 – EHRUS 

usability scoring system development and determine which statements are the best indicators of 

an EHR's true interactive quality. Further analysis might include a factor analysis of the larger set 

of 30 statements to reveal clusters of related characteristics, as a springboard for selecting an 

abbreviated set of statements. 

4.2.1 EHRUS usability scoring system development

4.2.1.1 EHRUS Version 1 

1. The EHR gives me a comprehensive view of a patient’s health.

2. The EHR makes it easy to find information.

3. I am confident that I can use the EHR to perform tasks correctly.

4. The EHR's content is poorly organized.

5. The EHR will prevent time-wasting mistakes.
Technical Basis for User Interface Design of Health IT

99

6. The EHR makes it easy to share information with other healthcare professionals.

7. The EHR will help me deliver higher-quality patient care.

8. I will not remember how to perform infrequent tasks with this EHR.

9. The EHR makes it easy to detect and correct mistakes.

10. The EHR’s workflows match my expectations.

11. I will eventually master the EHR’s advanced features.

12. The EHR indicates progress on multi-step tasks.

13. The EHR makes it clear what to do next.

14. The EHR’s various parts are not well integrated.

15. The EHR provides the information necessary to make good decisions.

16. Using this EHR will increase my workload.

17. The EHR makes important information stand out.

18. The EHR is easy to learn to use.

19. The EHR will prevent harmful mistakes.

20. It takes too long to enter data into the EHR.

21. It will be easy to help co-workers learn to use the EHR.

22. The EHR does not follow consistent rules on how to use it.

23. The EHR makes it clear why it is recommending certain actions.

24. Using the EHR will not improve patient safety.

25. The EHR uses familiar terms, symbols, and units.

26. The EHR includes only necessary and useful features.

27. I can use the EHR effectively while working under pressure.

28. The EHR requires me to enter the same information too many times.

29. The EHR makes it easy to share information.

30. The EHR is poorly designed for people who do my job.
Technical Basis for User Interface Design of Health IT

100

The following statements (a subset of above list) are particularly use-safety related:

31. The EHR gives me a comprehensive view of a patient’s health.

32. The EHR makes it easy to find information.

33. I am confident that I can use the EHR to perform tasks correctly.

34. The EHR makes it easy to share information with other healthcare professionals.

35. The EHR will help me deliver higher-quality patient care.

36. The EHR makes it easy to detect and correct mistakes.

37. The EHR provides the information necessary to make good decisions.

38. The EHR will prevent harmful mistakes.

39. The EHR makes it clear why it is recommending certain actions.

40. Using the EHR will not improve patient safety.

41. The EHR uses familiar terms, symbols, and units.

4.2.1.2 EHRUS Version 2

42. The EHR uses familiar terms, symbols, and units.

43. The EHR makes it easy to share information.

44. The EHR makes important information stand out.

45. The EHR indicates progress on multi-step tasks.

46. The EHR’s workflows match my expectations.

47. The EHR makes it easy to detect and correct mistakes.

48. The EHR gives me a comprehensive view of a patient’s health.

49. The EHR makes it easy to find information.

50. The EHR will prevent harmful mistakes.

51. The EHR makes it easy to share information with other healthcare professionals.

52. I can use the EHR effectively while working under pressure.
Technical Basis for User Interface Design of Health IT

101

53. The EHR’s various features and functions are well integrated.

54. The EHR includes only necessary and useful features.

55. The EHR is easy to learn to use.

56. I am confident that I can use the EHR to perform tasks correctly.

4.3 Qualitative analysis methods

Each of the EHR user interface principles presented in this document are linked to one or more 

project research findings; the product of an intensive qualitative data analysis. 

The qualitative analysis approach involved the following steps:

• Determine units of analysis – Analysts reviewed the research data and determined the 

appropriate unit of analysis for each data source, as follows:

o Web survey – survey respondents’ answers to two questions posed in the Webbased survey (“What EHR characteristics make it particularly easy to use?” and 

“What EHR characteristics make it particularly difficult to use?”)

o Site visit interviews – answers to questions posed to clinical and administrative 

interviewees during site visits

o Site visit observations – field researchers’ observation notes that comprised a 

finding focused on a particular usability issue, safety concern or task step

o Usability testing – use errors, close calls (cases when a user almost commits a 

use error), difficulties, instances of test administrator assistance, and subjective 

feedback (i.e., anecdotal usability test participant comments provided during a 

task or follow-up interviews)

o Expert reviews – a specific finding (i.e., user interface design strength or 

weakness), accompanied by potential benefits or consequences and potential 

design improvements

• Determine finding codes – Analysts reviewed the 15 expert review categories (see 

section 4.4.1 – Expert review categories) and, drawing on professional judgment and an 

initial review of the findings from the other research activities, expanded the number to 25 

to cover a wide range of user interface design topics. During the coding process, four 

additional categories (“Billing”, “Interoperability”, “Staff Communication”, and “Patient 

Education/Communication”) emerged as necessary to enable sufficiently specific data 

coding and were added to the list of 25 categories, thereby resulting in a total of 29 

categories (see section 4.4.2 – Complete list of categories).
Technical Basis for User Interface Design of Health IT

102

• Train analysts to ensure consistent coding – A lead researcher trained three analysts 

to code the research findings to ensure consistency. The researcher described each of 

the coding categories individually and provided examples of associated findings from 

various data sources and then selected and coded a set of 30 findings selected at 

random from the site visit data and asked each of the three analysts to code these 

findings independently. The researcher then led a discussion during which each analyst 

reported their codes for each finding, and the researcher provided clarification and led a 

discussion to resolve discrepancies between raters. Additionally, the lead researcher was 

available to discuss any questions that arise throughout the entire coding process. 

• Code the findings – The lead researcher and three analysts reviewed all of the data in 

raw or processed form and coded each finding (i.e., unit of analysis, as described above) 

with one or two categories: a primary code, capturing the main aspect of interest for the 

finding, and potentially a secondary code, capturing any additional relevant information. 

Importantly, each data source was coded by two or more individuals to limit potential bias 

resulting from a particular analyst’s perspective on a particular data source. 

For example, the following usability test finding was coded as “Clinical Decision 

Support”(primary code) and “Visual Design” (secondary code): 

“One provider suggested displaying abnormal lab results, or those that require 

follow-up, in red to help users to distinguish between critical and non-critical 

results” 

Ultimately, the analysts coded over 3,400 findings. Some findings were coded as “N/A” if 

they were not relevant to design guidance, were not technically compelling, or were 

insufficiently detailed to support a principle. 

Table 4-2 lists the number of findings generated from each data source.

Table 4-2: Number of findings generated from each data source.

EHR Number of findings

Number of coded 

findings leading to 

principles

Usability testing 806 777

Site visit interviews and 

observations 1,389 927

Expert reviews 665 665

Web survey 592 350

Total 3,452 2,719
Technical Basis for User Interface Design of Health IT

103

• Ensure coding quality control – The three analysts marked findings about which they 

were uncertain about the tentatively assigned codes. The lead analyst reviewed and 

adjusted the codes assigned to these findings, and also performed spot checks on 

randomly selected findings as an additional coding quality check. 

• Synthesize principles – Analysts and two principal researchers reviewed the coded 

findings by category (e.g., “Alerts”) or multiple categories (e.g., “Workflow” and 

“Efficiency”) and formulated principles where they judged there to be sufficient evidence 

to support them. Ultimately, the analysts wrote over 380 principles, many of which were 

based on multiple findings. Multiple findings pertaining to the same topic was considered 

a strong indicator that a principle was warranted.

• Review prinicples – Multiple analysts judged the integrity of the principles, by crosscomparing them to principles from other authoritative sources and their professional 

expertise. This review led to some principle deletions as well as to editorial adjustments 

to increase clarity and conciseness. This step reduced the number of principles from 380

to 343.

• Link principles to codes – Analysts produced a spreadsheet that links the 343 EHR 

user interface design principles to the coded research findings. Analysts reviewed each 

finding for its potential to support a particular principle, and also reviewed principles to 

determine which additional findings further supported them. 

4.4 Usability finding categories

4.4.1 Expert review categories

This section lists the 15 categories used to structure and categorize the expert review findings. 

This list was created based on the collective expert judgment of UL-Wiklund and its collaborators, 

as well as a review of Nielsen’s 10 heuristics for user interface design (Nielsen, 2005)13, 

Shneiderman’s 8 Golden Rules of Interface Design (Shneiderman, 1992)14, and 14 usability 

heuristics developed for the medical industry that were later incorporated into the TURF 

framework (Zhang, 2003; Zhang & Walji, 2011)15. 

Content Organization

Clarification: Pertains both to content on a single screen and the distribution of contents among 

multiple screens.

 13 Nielsen, J. (2005). Ten usability heuristics. 14 Shneiderman, B. (1992). Designing the user interface: strategies for effective human-computer 

interaction (Vol. 3). Reading, MA: Addison-Wesley. 15 Zhang, J., & Walji, M. F. (2011). TURF: Toward a unified framework of EHR usability. Journal 

of biomedical informatics, 44(6), 1056-1067. Chicago; Zhang, J., Johnson, T. R., Patel, V. L., 

Paige, D. L., & Kubose, T. (2003). Using usability heuristics to evaluate patient safety of medical 

devices. Journal of biomedical informatics, 36(1), 23-30.
Technical Basis for User Interface Design of Health IT

104

The configuration (physical arrangement, order of presentation) of information (e.g., text, 

graphics, charts, tables) within a screen and the degree to which it facilitates information 

acquisition, data entry, and control tasks. 

Navigation 

Clarification: Pertains to movement among multiple screens. 

The clarity and efficiency of movement among an application’s various screens. 

Nomenclature

The use of familiar terms for the intended users. 

Visual Design 

The use of graphics, color, typography, layout, and other visual elements to facilitate information 

acquisition, draw attention to important information, and optimize the aesthetic appeal of 

onscreen content.

Error Prevention 

Design characteristics that protect users from committing use and/or safety errors. 

Error Recovery

Design characteristics that help users detect and recover from use and/or safety errors, giving 

users a chance to check their actions and make necessary corrections before the error becomes 

consequential. 

Feedback

Indications that a user action is required, and/or information that a user action has been 

accepted/submitted, or otherwise is in progress. Feedback from an EHR may take visual and/or 

auditory forms.

Status Indication 

Information about system processes and progress (e.g., search is being undertaken, document is 

being downloaded, print job is being sent to printer), or clinical processes and progress (e.g., 

order status, pending tasks). 

Internal Consistency

The EHR employs a common set of design rules and behaviors that enable users to apply 

lessons learned about performing a given task with the EHR to other tasks within the EHR. 

External Consistency
Technical Basis for User Interface Design of Health IT

105

An EHR employs a set of design rules and behaviors that are consistent with EHRs and other 

EHRs and software products with which a user might be familiar, such as business applications, 

websites, medical devices, and consumer products.

User Support

The use of user interface features such as headings, prompts, alerts, tool-tips, reminders, and 

online help to guide users’ interactions with the EHR. 

Support for clinical decision making 

The EHR provides information necessary to make proper medical decisions and choices at the 

right time. 

Affordances 

Clarification: Pertains to user interface design characteristics that are intrinsic (e.g., large text that 

increases legibility, a drop shadow on a button that distinguishes the button from a text field, a 

button that has both an icon and text label) rather than elements normally regarded to be forms of 

user support. 

Information contained within the design element informs actions that can be undertaken with the 

element (e.g., “buttons” that afford pushing, accordion chevrons that afford expanding and 

collapsing).

Customizability

Opportunities for users to adjust certain EHR characteristics (e.g., available functions, information 

configurations, degree of prompting) to suit their personal needs and preferences.

Workflow

Clarification: Pertains to EHR-related tasks in the context of preferred clinical practices. 

The efficiency with which users can perform overall EHR-related tasks, which may occur in 

parallel or in series with interactions involving other equipment and personnel, and the degree to 

which it matches users’ preferred task order and established mental models.

4.4.2 Complete list of categories

This appendix lists the 29 categories used to categorize the research findings from all data 

sources. Note that the categories pertain to either user interface design principles (i.e., “Content 

Organization”) or particular EHR-specific tasks and aspects (i.e., “Patient Identification.”). 

Emergent categories (i.e., that arose organically from themes discovered during the coding 

process) are marked with a star. 

• Affordances
Technical Basis for User Interface Design of Health IT

106

• Clinical Decision Support

• Conceptual Model

• Content Organization

• Information density

• Customizability

• Data Entry

• Internal Consistency

• External Consistency

• Efficiency

• Workflow

• Error Prevention, Detection, and Recovery

• Alerts

• Feedback

• Language

• Navigation

• Patient Identification

• Status Indication

• Search

• User Support

• Visual Design

• Typography

• Graphics

• Color

• Metaphor

• Billing*

• Interoperability*

• Patient Education/Communication*

• Staff Communication* 
Technical Basis for User Interface Design of Health IT

107

5 Appendix B: EHR development best 

practices

Research team members conducted an interview with Dr. Raj Ratwani, Scientific Director at 

MedStar’s National Center for Human Factors in Healthcare, regarding recent research the center 

conducted about EHR vendors’ user-centered design (UCD) processes.16 Dr. Ratwani and a 

team of human factors experts interviewed eleven EHR vendors determine current vendor UCD 

practices and develop an appreciation for the difficulties vendors face incorporating UCD into 

EHR design and development processes. 

Based on the interview with Dr. Ratwani, the research team developed a set of EHR usability 

engineering best practices regarding the incorporation of UCD into EHR design and development. 

Each best practice describes its associated benefits, current EHR vendor practices, and 

recommendations for implementing the practice.

5.1 Promote usability at the leadership level 

Strong leadership support for usability engineering helps build an organizational culture 

that values and prioritizes user-centered design activities. 

Current practices: Leadership support for UCD varies among EHR vendors, from 

knowledgeable and supportive leadership who view EHR usability as a market differentiator to 

generally unsupportive or un-knowledgeable leadership who have an overly limited view of 

usability engineering (e.g., mistakenly considering post-market feedback solicitation as a 

complete usability engineering program). 

Recommendations: EHR vendor leadership should ensure they are well-informed regarding 

basic user-centered design principles and their effect on EHR usability, use safety, and 

commercial success. Additionally, leadership should champion UCD processes and usability both 

at internal meetings and by allocating sufficient financial and scheduling resources for UCD 

activity and dedicated human factors expertise, either in-house or via a consulting practice. 

Finally, human factors and usability engineering staff should inform colleagues about the value of 

user-centered design, including calculating or estimating the potential return benefits and 

demonstrating how particular user feedback. 

5.2 Establish and maintain a diverse user base

A diverse user network enables vendors to obtain rapid feedback throughout the design 

and development process.

 16 Ratwani, R. M., Fairbanks, R. J., Hettinger, A. Z., & Benda, N. C. (2015). Electronic health record usability: analysis of 

the user-centered design processes of eleven electronic health record vendors. Journal of the American Medical 

Informatics Association.
Technical Basis for User Interface Design of Health IT

108

Current practices: Current practices vary widely. Some vendors run usability tests at their 

annual conference, which is likely to be attended by many of their customers, while others have a 

network of users they can contact throughout the year. 

Recommendations: Engage the user base to participate in regular user research activities. 

Consider identifying a core group of users representing diverse demographic characteristics and 

clinical specialties. This core clinician network will enable rapid recruitment of usability test 

participants and the collection of user feedback throughout the design and development process. 

Vendors can increase clinicians’ motivation to participate in such a network by emphasizing their 

impact on the product design and showing participants examples of how their feedback led to 

design changes. 

5.3 Conduct a variety of user-centered design activities 

Conducting a variety of user-centered design activities helps developers form a multifaceted understanding of user interactions with the product. Plan user-centered design 

activities to provide relevant and appropriate input during particular phases of the design 

and development process. 

Current practices: Vendors with established UCD procedures tend to conduct a mix of activities, 

with the most common ones being development of use cases and user profiles or personas to 

guide the development process and the conduct of formative and/or summative usability tests. 

Some developers also conduct field observations in the initial design phase. Vendors without an 

established UCD program tend to conduct a limited subset of UCD activities, typically at only one 

or two points throughout the EHR development process. 

Recommendations: Plan to conduct a range of UCD activities to provide appropriate input to the 

design and development process. Incorporate activities such as focus groups, card sorting, use 

case scenario development, interviews, and observations early in the process and transition to 

formative and finally summative usability testing later in the process.

5.4 Conduct formative usability tests early and often

Conducting multiple formative tests in the early stages of the design process, and using 

test findings to inform product development, facilitates safe and usable EHR design. 

Current practices: Some developers skip formative testing based on the false premise that it is 

an optional step in the UCD process. As a result, developers who skip formative testing are more 

likely to encounter significant usability and use safety related shortcomings during summative 

usability testing. 

Recommendations: Allocate resources to formative usability testing throughout the product 

development lifecycle, focusing on phases in which study findings can still inform the EHR design 

and design changes are less costly (i.e., relative to later-stage testing). 
Technical Basis for User Interface Design of Health IT

109

5.5 Invest in professional usability expertise and 

encourage frequent interaction between usability 

experts and development teams 

A collaborative, open dialogue between the development team and dedicated usability 

experts promotes the integration of user-centered design into the development process. 

Current practices: Vendors with dedicated UCD teams typically follow one of two models. In one 

model, individual UCD team member work within a particular development team. In the other 

model, the UCD team serves in an advisory position, training developers and engaging with the 

development team at key junctures during the development process. Both models have proven to 

be effective.

Recommendations: Hire dedicated in-house usability professionals or maintains an ongoing 

relationship with a usability consulting organization. Encourage an ongoing dialogue between 

usability experts and the development team, within a team-based or advisory framework (see 

above). 

5.6 Integrate user-centered design into the 

development process 

Plan for usability testing and improvements from start of the development process to 

ensure time to address use-safety and usability issues.

Current practices: Vendor organizations typically prioritize a timely, on-schedule product launch. 

Organizations with well-developed UCD incorporate and plan for usability testing and design 

improvements in their development timelines.

Recommendations: Put a rigorous UCD process in place from the beginning of the development 

process that spans the entire product life-cycle, including post-market introduction. Human factors 

professionals should integrate themselves into the regular software development process without 

slowing down the development time line. Usability professionals should clearly communicate 

desired design modifications, explaining the benefits of implementation (vs. costs of nonimplementation) and prioritizing those design modifications that are likely to have the biggest 

impact in terms of usability and use-safety.

5.7 Infuse design and evaluation with clinical expertise 

Considering typical and optimal user workflows and clinician’s mental models of frequent, 

urgent and critical tasks will increase product efficiency, usability, and user satisfaction. 

Current practices: Some vendors work with clinical consultants; others hire staff with a clinical 

background. Some vendors invest several hundred hours observing and interviewing clinicians 

on-site in lieu of the advisory or in-house model. 
Technical Basis for User Interface Design of Health IT

110

Recommendations: Develop user profiles and use cases to better understand representative 

users. Investigate users’ typical workflow and develop an understanding of the cognitive 

requirements of particular tasks (i.e., through cognitive task analysis), users’ mental model of 

particular tasks, and the nature of user collaboration and interaction. Finally, obtain feedback from 

trusted clinicians regarding the development of appropriate and technically correct formative and 

summative test tasks and scenarios. 

5.8 Develop a use-related risk management process

A use-related risk management process details and analyzes use-related risks, ensuring 

that the product does not enable users to commit a safety-related use error or that the risk 

is mitigated to the greatest possible extent. 

Current practices: Few vendors have dedicated patient safety or risk groups that work closely 

with the usability and development teams. 

Recommendations: Incorporate risk analysis into the development cycle. Convene a dedicated 

multidisciplinary team (e.g., software developers, clinicians, etc.) to determine actions users can 

take within the EHR that might introduce patient harm. After producing an exhaustive list of such 

actions, assess each action’s likelihood of occurrence, related clinical harm(s), severity of harm, 

and mitigations currently in place to address said risk. Then, determine additional steps 

developers can take to reduce or eliminate the risk. After implementing the newly introduced 

mitigation, again assess the likelihood of occurrence and severity of harm based on the new 

mitigation. 
Technical Basis for User Interface Design of Health IT

111

6 Appendix C: Sample documents

6.1 Usability testing tasks

The research team selected tasks that would be realistic and representative of the kinds of 

activities a user might perform with this EHR, tailored to each of the three user groups. Tasks 

were developed collaboratively among members of the research team with human factors and 

clinical expertise. Tasks represent both common and safety-critical EHR functions. 

To increase task realism, tasks were integrated into scenarios, which were 1-3 short paragraphs 

describing a particular patient and clinical need. These scenarios also served to provide clinical 

context for the tasks. 

Table 6-1 lists tasks available to be performed by medical assistant participants.

Table 6-1: Medical assistant tasks.

Scenario Task

1

1 - Reschedule appointment

2 - Update patient address

2

3 - Find appointment request

4 - Schedule follow-up appointment

3

5 - Modify location of x-ray order

6 - Print chest x-ray order

7 - Document location change

4

8 - Fax CT scan order

9 - Document order fax

5 10 - Create new patient record

Table 6-2 lists tasks available to be performed by nurse participants.

Table 6-2: Nurse Tasks.

Scenario Task

1 1 - Enter vital signs
Technical Basis for User Interface Design of Health IT

112

2 - Order rapid flu test

3 - Schedule follow-up appointment

2 4 - Order flu shot

3

5 - Locate cholesterol lab result

6 - Document patient education

4

7 - Locate current orders

8 - Document test completions

5

9 – Review growth chart

10 - Fax chest x-ray order

11 - Cancel hematocrit order

6

12 - Enter CBC results

13 - Reschedule appointment

14 - Document phone call

7 15 - Reconcile medications

Table 6-3 lists tasks available to be performed by provider participants

Table 6-3: Provider tasks.

Scenario Task

1

1 - Review patient information

2 - Order referral

3 - Order tests

2

4 - Check for and place order

5 - Order vaccine

3

6 - Cancel referral

7 - Modify location of bone density scan

4

8 - Place multiple orders

9 - Order abdominal x-ray
Technical Basis for User Interface Design of Health IT

113

10 - Schedule follow-up appointment

5

11 - Add diagnosis

12 - Reconcile medications

13 - Adjust dose

14 - Prescribe medications

15 - Print prescriptions

6.2 Sample cognitive task analysis

6.2.1 Introduction

Developers can develop a deeper understanding of user interactions with an EHR by performing 

a cognitive task analysis of user tasks, focusing on those ensuring use safety and effectiveness. 

Cognitive task analysis might sound complex since the term “cognitive” suggests a need for 

extensive training in psychology or cognitive science. However, a cognitive tasks analysis can be 

a reasonably straightforward and practical process

Applied Cognitive Task Analysis (ACTA) is a streamlined cognitive task analysis methodology 

that focuses on efficiently identifying what users and need to know to accomplish a task and, 

accordingly, the factors developers must take into account to design effective systems.17 One 

form of ACTA, a cognitive demands table, calls upon analysts to determine what is mentally 

difficult about a task, why it is difficult, what errors the difficulty might induce, and coping 

strategies that help individuals overcome the difficulty. Note that the focus is on difficulties in this 

case, but a cognitive task analysis can be approached in a more neutral manner, identifying 

aspects of various tasks that are easy, neither easy or difficult, or difficult. 

This appendix presents the results of a cursory cognitive analysis (pertaining to a hypothetical 

EHR) that of five difficult and common EHR tasks. It focuses on the following five tasks, which are 

a small subset of the dozens of tasks that people might perform using a given EHR: 

• Prescribe medication

• Order procedure

• Manage problem list

• Enter vital signs

• Schedule appointment

 17 Militello, L. G., & Hutton, R. J. (1998). Applied Cognitive Task Analysis (ACTA): A practitioner's toolkit for 

understanding cognitive task demands. Ergonomics, 41(11), 1618-1641.
Technical Basis for User Interface Design of Health IT

114

The results of such an analysis, or analyses of a similar nature, can be a rich source of inspiration 

for user interface designers who seek to streamline tasks by making cognitive tasks easier to 

perform correctly. Possible user interface design solutions linked to the sample cognitive task 

analysis findings are presented below as a demonstration of the potential value of such an 

analysis.

Table 6-4: Cognitive task analysis insights and resulting design solutions.

Task Challenge Potential UI Design Solutions

Open patient 

chart

Clinicians might open the wrong 

patient’s chart because they have 

multiple patient charts open at once 

Persistently and conspicuously 

present key patient information (e.g., 

name, date of birth, photograph) in 

the patient chart and accompanying 

controls (e.g., tab used to select the 

patient chart). 

Prescribe 

medication 

Clinicians might confuse medications

with similar spellings or purposes 

Present medication name using a 

large font (e.g., greater than 18 point 

font size). 

Utilize TALLman lettering to highlight 

spelling differences between 

similarly named medications. 

Require users to confirm they 

selected the correct medication. 

Prescribe 

medication 

When ordering prescriptions, 

clinicians must recall and consider 

patient diagnoses, which might not be 

presented alongside medication 

ordering module

Present relevant patient details (e.g., 

allergies, currently prescribed 

medications) in a persistent manner, 

such that they are visible on all 

ordering screens. 

Utilize algorithms to automatically 

detect any conflicts between patient 

and medication characteristics. If a 

potential conflict is detected, present 

an alert message to the user. 

Prescribe 

medication 

Some EHRs present an extensive list 

of potential interactions but do not 

indicate severity, thereby requiring 

clinicians to prioritize among contraindications

Utilize visual design attributes (e.g., 

ordering, color-coding, flashing) to 

indicate the relative priority of 

displayed interactions and contraindications. 

Search for 

procedure 

Clinicians might not distinguish 

between inclusive (i.e., result must 

include all search terms) and 

exclusive search, thereby potentially 

over-specifying the search term such 

that the desired procedure does not 

appear in the search results 

Present a prompt that explains the 

syntax used for inclusive vs. 

exclusive searches. 

When presenting search results, 

provide a prompt explaining the 

search method used based on the 

user’s search string. 
Technical Basis for User Interface Design of Health IT

115

Task Challenge Potential UI Design Solutions

Add diagnosis 

code (s)

Clinicians might not know which ICD 

codes will be accepted by the 

patient’s insurance

Enable users to select diagnosis 

codes from a list of available codes. 

Enable users to search for a code by 

entering associated terms. 

Audit problem 

list 

Multiple clinicians can edit a patient’s 

problem list, potentially leading to 

duplicate entries. Clinicians might 

disagree regarding the contents of the 

patient’s active problem list

Use a software algorithm to 

automatically identify duplicate 

entries and inform the user of their 

presence. 

Indicate when a patient chart is 

being edited simultaneously by 

multiple users. Also, indicate which 

edits are being made by other users. 

Audit problem 

list 

Clinicians might delete rather than deactivate an entry, thereby removing 

important information from the 

patient’s medical history

Do not enable users to permanently 

delete information from a patient 

profile (e.g., only enable users to deactivate information). 

Provide a clear indication or warning 

informing the user that deleted 

information cannot be recovered. 

Require users to actively confirm that 

they intend to delete the patient 

profile (e.g., by entering their EHR 

account password to confirm their 

intention to delete the profile). 

Enter vital 

signs with 

units

Clinicians might measure patient’s 

vital signs in an order that does not 

match the vital sign data fields’ order , 

thereby leading to data entry errors

Include prominent, conspicuous 

labels for each vital sign, to minimize 

potential that users will overlook the 

label. 

Provide alerts regarding abnormal 

(or impossible) vital sign ranges or 

potential data entry errors and, if 

necessary, modify vital sign fields.

Enable hospital administrators to 

modify the order of vital sign fields so 

that it matches the hospital’s 

established order forms. 
Technical Basis for User Interface Design of Health IT

116

Task Challenge Potential UI Design Solutions

Enter vital 

signs with 

units

Several vital signs (e.g., height, 

temperature) may be recorded in 

either English or metric units. 

Clinicians might select incorrect units 

or neglect to modify default units, 

Provide a conspicuous indication of 

the currently selected unit. 

Automatically calculate and display 

the vital sign in its secondary unit 

next to the primary unit.

Provide alerts regarding abnormal 

(or impossible) vital sign ranges or 

potential data entry errors and 

modify vital sign fields if necessary 

Enter vital 

signs with 

units

Clinicians might enter vital sign 

measurements incorrectly (e.g., 

misplacing a decimal point, omitting 

digits, entering one vital sign in 

another vital sign’s data field)

Provide alerts regarding abnormal 

(or impossible) vital sign ranges or 

potential data entry errors and 

modify vital sign fields if necessary 
Technical Basis for User Interface Design of Health IT

117

6.2.2 Prescribe medication 

Task Challenge Performance shaping factors Potential use errors Risk reduction strategies 

Open patient 

chart

Select correct 

patient

• Clinicians see many patients (perhaps 

≥10) in a single day

• Clinicians might wish to keep multiple 

patient charts open at once 

• Some patients might have identical or 

similar names 

• Open wrong patient chart

• Confuse one patient’s chart for 

another 

• Confirm patient identity by reviewing at 

least two patient identifiers (e.g., 

D.O.B., full name, photo)

• Constrain the number of patient charts 

that might remain open at once 

Access 

prescription

ordering 

module

Locate ordering 

module

• The patient chart’s home screen 

features relatively high information 

density 

• Exposure to other EHR content 

organization schemes can lead to 

negative transfer 

• Providers might have multiple patient 

chart and medication prescription 

windows open simultaneously 

• Open wrong module due to 

confusing nomenclature or content 

organization (e.g., open procedure 

ordering module rather than 

prescription ordering module)

• Open wrong patient’s prescription 

ordering module

• Interpret navigation cues by utilizing 

icon tooltips

• Verify name on patient ordering 

module

Search for 

medication

Search for correct 

medication 

• Clinicians might confuse medications 

with similar spellings or purposes 

• Medications might be listed under 

unexpected names (e.g., generic 

instead of brand name)

• Medication names can be complex, 

have multiple forms, and can change as 

similar medications or generic versions 

are developed

• Search results might be extensive 

• Type medication name into search 

field incorrectly

• Select a medication that appears to 

be correct in the medication list, but 

is incorrect due to: similar 

name/spelling, generic alternatives, 

wrong dosage, concentration, or 

form of medication (e.g., liquid form 

instead of tablets) 

• Inadvertently click on wrong 

medication (i.e., selection accuracy) 

• Add medication to wrong patient's 

chart (i.e., if wrong patient chart 

selected previously)

• Verify medication spelling by referring 

to an external website or resource 

• Confirm medication name and details 

are appropriate after selection 
Technical Basis for User Interface Design of Health IT

118

Task Challenge Performance shaping factors Potential use errors Risk reduction strategies 

Specify 

prescription 

details 

Specify correct 

prescription details 

(e.g., dosage, 

concentration, and 

brand)

• Some medications are available in a 

relatively high number of dosages, 

concentrations, and forms 

• Inadvertently select incorrect 

medication concentration (i.e., 

selection accuracy)

• Review all prescription details prior to 

finalizing order 

Review any 

contraindications 

or alerts

Review contraindications and 

alerts

• Patients might have many medications 

on their list, such that prescribing a 

particular medication might require 

modifying the mediation list overall 

• Clinicians must recall and consider 

patient diagnoses and allergies, which 

might not be presented alongside 

medication ordering module 

• Some EHRs present an extensive list of 

potential interactions but do not indicate 

severity, thereby requiring clinicians to 

prioritize among contra-indications 

• Ignore critical drug interaction alerts 

due to alert fatigue and rapid clicking 

pace 

• Order wrong medication (i.e., a noneffective treatment that is not 

indicated for the patient’s disorder)

• Order a medication with harmful 

drug interactions 

• Review drug interaction information 

and alerts 

• Access external websites that provide 

dedicated and detailed information on 

drug interactions 

Send 

prescription 

to pharmacy 

to be filled

Confirm that 

prescription has 

been sent to 

pharmacy 

• Patient’s preferred pharmacy might not 

be listed in EHR

• EHR might contain incorrect contact 

information for patient’s preferred 

pharmacy 

• EHR might not confirm that prescription 

was submitted to pharmacy 

• Place duplicate orders, due to 

double-clicking on submit button 

• Send order to incorrect pharmacy 

• Finalize order but fail to send order 

to pharmacy

• Verbally confirm pharmacy with patient

• Confirm that prescription was 

submitted to pharmacy 
Technical Basis for User Interface Design of Health IT

119

6.2.3 Order procedure 

Task Challenge Performance shaping factors Potential use errors Risk reduction strategies 

Open patient 

chart

Select correct patient • Clinicians see many patients 

(perhaps ≥10) in a single day

• Clinicians might wish to keep multiple 

patient charts open at once 

• Some patients might have identical or 

similar names

• Open wrong patient chart

• Confuse one patient’s chart for 

another

• Confirm patient identity by 

reviewing at least two patient 

identifiers (e.g., D.O.B., full name, 

photo)

• Constrain the number of patient 

charts that might remain open at 

once

Access ordering 

module

Locate ordering module • The patient chart’s home screen 

features relatively high information 

density 

• Exposure to other EHR content 

organization schemes can lead to 

negative transfer 

• Providers might have multiple patient 

chart and order windows open 

simultaneously 

• Open wrong module due to 

confusing nomenclature or 

content organization (e.g., 

opening prescription ordering 

module rather than procedure 

ordering module)

• Open wrong patient’s procedure 

ordering module

• Interpret navigation cues by 

utilizing icon tooltips

• Verify name on patient ordering 

module

•

Search for 

procedure

Search for correct 

procedure

• Clinicians might confuse procedures 

with similar names, spellings or 

descriptions (i.e., TSH vs. TSI test)

• Procedures might be listed under 

different name than expected due to 

multiple or overlapping clinical 

terminology 

• Procedures might be listed as 

unfamiliar abbreviations 

• Procedure names and descriptions 

might be long, complex and can 

change over time (i.e., due to 

innovation)

• Clinicians might not distinguish 

between inclusive (i.e., result must 

• Type procedure name into search 

field incorrectly

• Select an incorrect procedure due 

to similar name, spelling, or 

description 

• Inadvertently click on wrong 

procedure (i.e., selection 

accuracy) 

• Order procedure for wrong patient 

(i.e., if wrong patient chart 

selected previously) 

• Search for unfamiliar terms and 

abbreviations by referring to an 

external website or resource 

• Confirm procedure name and 

details are appropriate after 

selection
Technical Basis for User Interface Design of Health IT

120

include all search terms) and 

exclusive search, thereby potentially 

over-specifying the search term such 

that the desired procedure does not 

appear in the search results 

Add diagnosis 

code(s) 

Select correct diagnosis 

code(s) 

• Clinicians might not know which ICD 

codes will be accepted by the 

patient’s insurance 

• Similar diagnoses might not be welldistinguished in ICD code list or 

database 

• Available ICD-9 codes might not be 

sufficiently specific 

• The ICD-9 database is comprised of 

over 14,000 diagnosis codes, and the 

ICD-10 database is comprised of over 

68,000 diagnosis codes 

• Patient’s diagnosis list might not be 

up-to-date 

• Procedure was ordered to determine 

diagnosis (i.e., rapid flu test), so 

clinician does not know which 

diagnosis code is appropriate 

• Enter an incorrect, unrelated, or 

non-billable diagnosis code

• Incorrectly enter diagnosis name 

when diagnosis code field calls for 

ICD code, or vice versa 

• Inadvertently click on wrong 

diagnosis code (i.e., selection 

accuracy)

• Rely on previously memorized 

ICD codes 

• Search for unfamiliar diagnoses or 

ICD codes by referring to an 

external website or application

• Verify diagnosis code after 

selection

Submit 

procedure order 

Confirm that order has 

been submitted 

• Submit button might be relatively 

inconspicuous due to location

• Submit button might not seem to 

afford clicking 

• Submit button might not be clearly 

labelled 

• EHR might not provide feedback 

confirming order submission 

• Exit order before submitting order 

• Save order details but failing to 

submit order 

• Submit order for wrong patient 

(i.e., if wrong patient chart 

selected previously) 

• Place two duplicate orders, due to 

double-clicking on submit button 

• Scan available buttons for 

“submit” or synonymous terms

• Scan screen for confirmation 

message after submitting order

• Check patient’s chart to verify that 

order appears in pending order list
Technical Basis for User Interface Design of Health IT

121

6.2.4 Manage problem list

Task Challenge Performance shaping factors Potential use errors Risk reduction strategies 

Open patient chart Select correct patient • Clinicians see many patients 

(perhaps ≥10) in a single day

• Clinicians might wish to keep 

multiple patient charts open at 

once 

• Some patients might have 

identical or similar names

• Open wrong patient chart

• Confuse one patient’s chart for another

• Confirm patient identity 

by reviewing at least two 

patient identifiers (e.g., 

D.O.B., full name, photo)

• Constrain the number of 

patient charts that might 

remain open at once 

Access problem 

list

Locate problem list • The patient chart’s home screen 

features relatively high 

information density 

• Exposure to other EHR content 

organization schemes can lead to 

negative transfer 

• Multiple providers might try to 

open the same patient chart 

problem list at the same time 

• Open wrong module due to confusing 

nomenclature or content organization 

• Interpret navigation cues 

by utilizing icon tooltips

• Verify patient name on 

module heading

•

Add diagnosis 

code(s) 

Select correct diagnosis 

code(s) 

• Clinicians might not know which 

ICD codes will be accepted by 

the patient’s insurance 

• Similar diagnoses might not be 

well-distinguished in ICD code 

list or database 

• Available ICD-9 codes might not 

be sufficiently specific 

• The ICD-9 database is comprised 

of over 14,000 diagnosis codes, 

and the ICD-10 database is 

comprised of over 68,000 

diagnosis codes 

• Patient’s diagnosis list might not 

be up-to-date 

• Clinicians might not know which 

diagnosis code is appropriate 

because the procedure was 

ordered to determine diagnosis 

• Enter an incorrect, unrelated, or non-billable 

diagnosis code

• Incorrectly enter diagnosis name when 

diagnosis code field calls for ICD code, or 

vice versa 

• Inadvertently click on wrong diagnosis code 

(i.e., selection accuracy) 

• Rely on previously 

memorized ICD codes 

• Search for unfamiliar 

diagnoses or ICD codes 

by referring to an 

external website or 

application

• Verify diagnosis code 

after selection 
Technical Basis for User Interface Design of Health IT

122

(i.e., rapid flu test)

Audit problem list Maintain comprehensive 

problem list

• Multiple clinicians can edit a 

patient’s problem list, potentially 

leading to duplicate entries

• Clinicians might disagree 

regarding the contents of the 

patient’s active problem list

• Problem lists might be unreliable 

due to inconsistent or sporadic 

updates

• Delete rather than de-activate an entry, 

thereby removing important information 

from the patient’s medical history

• Neglect to update the patient’s problem list 

• Inadvertently inactivate or re-activate 

entries 

• Refer to organizational 

policies regarding 

problem list content

• Review and update 

problem list with patient 

at the beginning or end 

of each encounter 

• Annotate problem list 

entries 

Save changes to 

problem list 

Confirm that problem list 

has been updated 

• Save button might be relatively 

inconspicuous due to location

• Save button might not seem to 

afford clicking 

• Save button might not be clearly 

labelled 

• EHR might not provide feedback 

confirming problem list update

• Exit problem list before saving changes 

• Update wrong patient’s problem list (i.e., if 

wrong patient chart selected previously) 

• Rely on internal 

consistency in EHR to 

guide user to save 

problem list

• Scan available buttons 

for “save” or synonymous 

terms 

• Scan screen for 

confirmation message 

after updating problem 

list

• Check patient chart after 

saving to verify that 

problem list was updated
Technical Basis for User Interface Design of Health IT

123

6.2.5 Enter vital signs

Task Challenge Performance shaping factors Potential use errors Risk reduction strategies 

Open patient chart Select correct patient • Clinicians see many patients 

(perhaps ≥10) in a single day

• Clinicians might wish to keep 

multiple patient charts open at 

once 

• Some patients might have 

identical or similar names

• Open wrong patient chart

• Confuse one patient’s chart for another

• Confirm patient identity 

by reviewing at least two 

patient identifiers (e.g., 

D.O.B., full name, photo)

• Constrain the number of 

patient charts that might 

remain open at once 

Access vital signs 

module

Locate vital signs 

module

• The patient chart’s home screen 

features relatively high 

information density 

• Exposure to other EHR content 

organization schemes can lead to 

negative transfer 

• Providers might have multiple 

patient chart and vital signs 

windows open simultaneously

• Open wrong module due to confusing 

nomenclature or content organization (e.g., 

opening prescription ordering module rather 

than procedure ordering module)

• Open wrong patient’s procedure ordering 

module

• Interpret navigation cues 

by utilizing icon tooltips

• Confirm patient name on 

vital signs module 

Enter vital signs 

with units

Enter accurate vital sign 

values and units

• Clinicians might measure patient’s 

vital signs in an order that does 

not t match the vital sign data 

fields’ order 

• Clinical workflow typically requires 

that vital signs are entered quickly

• Several vital signs (e.g., height, 

temperature) might be recorded in 

either English or metric units

• Order of vital sign data fields 

varies among EHRs

• Blood pressure field presentation 

varies among EHRs (i.e., one vs. 

two fields for systolic and diastolic 

BP)

• Incorrectly enter vital sign measurements 

(e.g., misplace a decimal point, omit digits, 

enter one vital sign in another vital sign’s 

data field)

• Enter incorrect units

• Select incorrect units or neglect to modify 

default units

• Omit one or more vital signs fields

• Confirm vital sign 

measurements and units 

seem appropriate in 

context

• Compare vital sign 

entries to past results and 

normal ranges to ensure 

results are written 

correctly and in range (if 

EHR does not do so 

automatically)

• Review alerts regarding 

abnormal (or impossible) 

vital sign ranges or 

potential data entry errors 
Technical Basis for User Interface Design of Health IT

124

and modify vital sign 

fields if necessary

Save vital signs Confirm that vital signs 

have been updated 

• Save button might be relatively 

inconspicuous due to location

• Save button might not seem to 

afford clicking 

• Save button might not be clearly 

labelled 

• EHR might not provide feedback 

confirming that vital signs were 

saved to patient’s chart 

• Exit vital signs module before saving 

changes 

• Save vital signs to wrong patient’s chart 

(i.e., if wrong patient chart selected 

previously) 

• Rely on internal 

consistency in EHR to 

guide user to save vital 

sign entries

• Scan available buttons 

for “save” or synonymous 

terms 

• Scan screen for 

confirmation message 

after adding vital signs

• Review patient chart after 

saving to verify that vital 

signs were updated
Technical Basis for User Interface Design of Health IT

125

6.2.6 Schedule appointment

Task Challenge Performance shaping factors Potential use errors Risk reduction strategies 

Open calendar Access calendar or 

scheduling module 

• EHRs vary as to whether clinician 

or patient calendars are the 

organizing structure for scheduling 

• Clinicians or medical assistants 

might wish to open multiple 

patient charts and/or calendars 

simultaneously 

• Open wrong provider’s calendar 

• Confuse one provider’s calendar for 

another 

• Confirm provider name 

upon opening calendar

• If scheduling in patient 

calendar, confirm patient 

identify by reviewing at 

least two patient identifiers 

(e.g., D.O.B., full name, 

photo)

• Constrain the number of 

patient charts that might 

remain open at once

Search for 

available 

appointments

Locate a mutually 

convenient appointment 

• EHR might not have straightforward or comprehensive 

appointment search features 

• Appointments must fit within the 

patient’s schedule as well as the 

clinician’s schedule and criteria 

(e.g., appointment length, 

appointment type, timeframe, etc.)

• EHR might not clearly indicate 

whether an appointment search 

yielded no results (i.e., as 

opposed to loading issues or 

incorrectly spelled patient or 

clinician name) 

• Search for appointments in the wrong 

patient’s calendar

• Incorrectly enter appointment search 

parameters (e.g., misspell patient or 

clinician names, search for wrong year or 

date) 

• When appointment search yields no 

results, incorrectly assume no 

appointments are available rather than 

confirming that appointment search 

parameters are correct 

• Verify appointment criteria 

using notes from clinician 

and patient input

• Visually scan calendar for 

available appointments 

matching appointment 

criteria
Technical Basis for User Interface Design of Health IT

126

Select appointment 

time and date

Recall appointment 

criteria

• Appointment selection is subject 

to multiple criteria, including 

appointment length, appointment 

type, and timeframe 

• Search results might be relatively 

extensive and presented in a 

visually overwhelming manner 

hindering efficient visual scanning 

• Inadvertently click on wrong time slot (i.e., 

selection accuracy) 

• Schedule appointment for correct time on 

incorrect date 

• Schedule appointment for correct time 

and date but incorrect year

• Schedule a patient for the wrong 

appointment type (e.g., follow-up instead 

of new patient appointment)

• Inadvertently schedule multiple 

appointments for a patient

• Read and confirm selected 

appointment with patient

• Compare selected 

appointment time and date 

to appointment criteria 

provided to ensure selected 

time is appropriate 

• Review alerts regarding 

abnormal (or impossible) 

appointment options

Link appointment 

to patient record

Select correct patient • Clinicians or support staff might 

have multiple patient charts open 

simultaneously 

• Some patients have identical or 

similar names 

• EHR might provide insufficient 

feedback regarding whether 

patient record has been 

successfully linked to appointment 

• Link appointment to an incorrect patient

• Confuse one patient for another

• Incorrectly assume that patient’s 

appointment was successfully linked to 

patient record (i.e., if patient’s name was 

entered into a data field but not 

recognized by the system) 

• Confirm patient identify by 

reviewing at least two 

patient identifiers (e.g.,

D.O.B., full name, 

photo)Scan screen for 

implicit or explicit cues that 

patient record has been 

successfully linked to 

patient’s appointment

Save appointment Confirm that 

appointment was saved 

• Save button might be relatively 

inconspicuous due to location

• Save button might not seem to 

afford clicking 

• Save button might not be clearly 

labelled 

• EHR might not provide feedback 

confirming that appointment was 

successfully scheduled 

• Exit appointment creation window or 

schedule before saving changes 

• Schedule an appointment for the wrong 

patient (i.e., if wrong patient chart selected 

previously) 

• Scan available buttons for 

“save” or synonymous 

terms

• Scan screen for 

confirmation message after 

saving appointment

• Check patient or provider 

schedule after saving to 

verify that appointment was 

scheduled

• Compare newly scheduled 

appointment’s appearance 

to previously scheduled 

appointments
Technical Basis for User Interface Design of Health IT

127

6.3 Sample expert review findings

Expert review findings are typically categorized as strengths or problems (i.e., opportunities for 

improvement), augmented by potential design improvements. This appendix presents several 

examples of expert review findings created in the context of the research study. 

Shortcoming: Placement of referral function

Finding category: Content Organization

Issue: The referral placement (i.e., Referrals) function is categorized under the Demographics

tab. 

Potential consequences: Users might not find the Referral function because it does not seem 

related to Demographics.

Potential design improvement: Add a new tab titled Referral.

Figure 6-1: Referral function located under Demographics.

Shortcoming: Use of ellipses 

Finding category: Affordances 

Issue: The use of ellipses to indicate that the user can access more details about patient 

Allergies might not draw the user’s attention because the symbol is neither informative nor 

conspicuous. Moreover, some users might not recognize whether the presence of ellipses is a 

positive indication that the patient has allergies or not; the symbol is ambiguous. The user should 

not have to navigate to a list of Allergies to determine that the patient has none.

Potential consequences: A user might overlook the fact that the patient has an allergy that has 

bearing on a diagnosis and/or treatment.

Potential design improvement: Replace the ellipses with an informative term, such as Yes that 

links to a list of Allergies.
Technical Basis for User Interface Design of Health IT

128

Figure 6-2: Indication of allergies is subtle.

Figure 6-3: Clicking on “...” leads to list of allergies or none.

Strength: Allergy Alerts 

Finding category: Content Organization

Finding: The application alerts the HCP that the patient is allergic to pollen. Pollen is highlighted 

in red text to draw the user’s attention.

Potential benefits: The HCP will be aware of ongoing health issues that might have bearing on 

patient diagnosis and treatment.

Figure 6-4: Clinical reminders.
Technical Basis for User Interface Design of Health IT

129

7 Appendix D: User Profiles of 10 

EHR Users

This section presents 10 sample user profiles for individuals who might interact with Electronic 

Health Records (EHRs). The samples cover the following occupational titles:

• Medical Assistant

• Medical Record and Health Information Technician

• Technologist and Technician

• Nurse

• Advanced Practice Registered Nurse

• Physician Assistant

• Anesthesia Care Provider

• Physician

• Surgeon

• Pharmacist

Note that the user profiles are samples (i.e., exemplars) and should not necessarily be used 

directly by EHR developers. Rather, an EHR developer should either (1) create original user 

profiles, perhaps guided by the format and general contents of the exemplars, or (2) at least 

adapt the exemplars based on its own research findings.

Also note that the 10 samples do not comprise a complete set. Depending on the EHR, there 

might be other types of users warranting their own user profiles. For example, there might be a 

need to develop user profiles matching the following occupational titles:

• Administrative assistants

• Billing specialists

• Emergency medical technicians

• Office managers

• Paramedics

• Therapists
Technical Basis for User Interface Design of Health IT

130

The user profiles describe characteristics deemed common among many individuals, but not 

necessarily all individuals sharing the same occupational title or belonging to what an EHR 

development team might describe as a distinct user group. The information categories included in 

the sample user profiles are the following: 

• Occupational description

• Demographics (USA)

• Education

• Licensure/Certification

• Electronic Health Record (EHR) Use Environment(s)

• Experience using computers

• Sample EHR tasks

• Performance-shaping factors

Ultimately, EHR developers should include within user profiles the information that will be most 

useful to defining user interface requirements based on user needs and preferences and 

selecting participants for formative and summative evaluations (e.g., usability tests). The 

information might come from development project-specific research (e.g., user observations, user 

interviews), corporate knowledge about the users, findings from pertinent literature, and other 

possible sources.

While the following user profiles are 2-7 pages in length, a given profile might be considerably 

shorter or longer depending on the amount of pertinent information there is to share with readers.

7.1 Medical Assistant

7.1.1 Occupational description

Medical assistants (MAs) might carry out clinical as well as administrative tasks. Their duties vary 

depending on the location, specialty, and size of the practice.18 In larger practices or hospitals, 

MAs can specialize in either administrative or clinical work.

Some MAs specialize according to the type of office in which they work. 

• Administrative MAs. Tasks include filling out insurance forms, coding patient medical 

information, answering telephone calls, and scheduling patient appointments. 

 18 What Medical Assistants Do, http://www.bls.gov/ooh/healthcare/medical-assistants.htm
Technical Basis for User Interface Design of Health IT

131

• Clinical MAs. Duties vary depending on the state in which they work and the individual’s 

training or certification. Tasks can include preparing patients for x-rays, drawing blood, 

assisting with activities of daily living (e.g., bathing, ambulation), obtaining basic medical 

information (e.g., why the patient is visiting the doctor), obtaining vital signs, and 

instructing patients about treatment plans. 

7.1.2 Demographics (USA)

• Age: 37 years of age19

• Sex: Approximately 88% are female and 12% are male20

• Population: As of 2012, there were around 560,800 MAs21

7.1.3 Education

Most states lack formal educational requirements for becoming a medical assistant. MAs can 

graduate from post-secondary (i.e., after high school graduation) education programs or start 

medical assisting through on-the-job training. Although MAs are not required to graduate from 

post-secondary programs, most employers prefer to hire MAs who have completed such 

programs. 

Programs for MAs span approximately one or two years, although some are considerably shorter 

(e.g., 6 weeks), and usually lead to a certificate, diploma, or associate degree. They are available 

at community and junior colleges, vocational schools, technical schools, and universities. 

Programs consist of both classroom and laboratory education with lessons in anatomy and 

medical terminology. Several states require MAs to graduate from an accredited program and/or 

pass an exam to do more advanced tasks, such as take x-rays and give injections.

In contrast, some MAs have a high school diploma (or the equivalent) and learn through on-thejob training. On-the-job training might include learning medical terminology and how to record 

information in and code electronic health records (EHRs).

7.1.3.1 Licensure, certifications, and registrations

Although MAs are not required to be certified, many employers prefer to hire certified assistants.

Several organizations offer certification that either requires the MA to pass an exam or graduate 

from an accredited program.

The National Commission for Certifying Agencies, part of the Institute for Credentialing 

Excellence, accredits five certifications for medical assistants:

• Certified Clinical Medical Assistant (CCMA) from the National Healthcareer Association

 19 Page 30 Figure 3-1. Page 31 first paragraph. EMS Workforce for the 21st Century: A National Assessment 30. 

http://www.ems.gov/pdf/emsworkforcereport_june2008.pdf

20 Page 21, http://bhpr.hrsa.gov/healthworkforce/supplydemand/usworkforce/chartbook/chartbook3.pdf 21 Work Environment, http://www.bls.gov/ooh/healthcare/medical-assistants.htm
Technical Basis for User Interface Design of Health IT

132

• Certified Medical Administrative Assistant (CMAA) from the National Healthcareer 

Association

• Certified Medical Assistant (CMA) from the American Association of Medical 

Assistants (AAMA)

• National Certified Medical Assistant (NCMA) from the National Center for Competency 

Testing

• Registered Medical Assistant (RMA) from American Medical Technologists

7.1.4 Electronic Health Record (EHR) Use environment(s)

More than half of all MAs work in physician offices.22 According to a limited data collection effort 

in 2008, the majority (62%) of MAs worked in physician offices while small percentages of MAs 

worked in settings such as hospitals (13%) and the offices of non-physician providers (11%).23

Credentialed medical assistants are able to enter (i.e., transcribe) medication, radiology, and 

laboratory orders into the EHR in accordance with clinicians’ orders. Their entry counts toward 

meeting the requirements for meaningful use for the Medicare and Medicaid EHR Incentive 

Programs.24

Medical assistants interacting with EHRs.25

7.1.5 Experience using computers

An MA’s comfort level with computers might vary based on prior computer use and overall 

education. 

Due to computer use starting in childhood, younger MAs are more likely to have experience with 

and be comfortable participating in computer-based training. MAs who used computers 

 22 Work environment, http://www.bls.gov/ooh/healthcare/medical-assistants.htm#tab-3 23 http://www.cuny.edu/about/administration/offices/hhs/CUNY.MAReport.2.6.12.pdf, page 3. 24 Assessment-Based Recognition in Order Entry (ABR-OE), http://www.aama-ntl.org/medical-assisting/abr 25 Photo sources: http://uminsideview.org/wp-content/uploads/2014/04/Corl.jpg, http://www.globeuniversity.edu/blogs/wpcontent/uploads/2014/10/bigstock-nurse-and-patient-conversing-a-56375318.jpg, http://www.pro-medtech.com/images/Medical_Assistant_Training.jpg
Technical Basis for User Interface Design of Health IT

133

throughout their schooling are generally more inclined to explore unfamiliar functions and perform 

tasks with high efficiency. 

Often, younger MAs might also have a clearer mental model of computer-based data 

management, including uploading and downloading data and using computers to access other 

data sources. Those MAs that did not use computers during schooling are generally less 

comfortable exploring computer functions and in some cases perform tasks with less efficiency 

than younger MAs.

Typing speed is not necessarily a function of age. While younger MAs might have used 

computers since childhood and have become proficient typists, older MAs might have taken 

typing classes, which were more common in years past, and also become fast at data entry tasks 

due to their own cumulative years of interacting with computers.

7.1.6 Sample EHR tasks

• Create new patient records

• Add patient information to existing records, including demographic, billing and insurance 

information 

• Schedule, reschedule, and cancel appointments

• Schedule referral appointments

• Print, fax, and electronically send provider signed orders for laboratory tests and 

procedures

• Document communication with other facilities (e.g., that an order has been faxed)

• Follow up with patients regarding upcoming appointments or follow-up care

• Document patient communication (e.g., a patient phone call)

• Locate clinician appointment and other follow-up care requests in patient records

• Enter vital signs (clinical MAs)

• Enter intake and output (clinical MAs) (e.g., oral fluid intake, urine output)

7.1.7 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, could be expected to influence MAs’ interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading users to seek shortcuts and workarounds to complete required tasks 

in time available
Technical Basis for User Interface Design of Health IT

134

• Little time between patients. Lacking time between patients can make MAs more likely 

to delay entering data into the EHR. This would require them to rely more on memory to 

correctly recall and associate information and observations with the correct patient

• Working with multiple patients simultaneously. This requires MAs to rely more on 

memory to correctly recall and associate information and observations with the correct 

patient

• Need for clinician input. Confirming details or consulting with nurses and other 

healthcare professionals might delay work

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material (e.g., user 

manual, quick reference guide) can lead the MA to rely on memory to recall operating 

procedures

• Interaction effect. Wearing protective equipment such as gloves might inhibit 

movement, visibility, and typing

7.2 Medical Record and Health Information Technicians 

7.2.1 Occupational description

Medical Record and Health Information Technicians manage health information and data 

gathered from electronic health records (EHRs). Data analysts work to ensure the security, 

quality, accuracy, and accessibility of health information data. 

Data analysts use various classification systems to collect, code, and categorize patient 

information. They often specialize in coding diagnoses using International Classification of 

Disease (ICD) codes and procedures using Current Procedural Terminology (CPT) codes. This 

information is imperative for insurance reimbursement, tracking specific types of diseases in 

databases and registries, and maintaining patients’ medical and treatment histories.26

7.2.2 Demographics (USA)

• Age: 48.6% of data analysts are 35-55 years old27

 26 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-records-and-health-informationtechnicians.htm#tab-4 27 Page 18, Figure 24, http://bhpr.hrsa.gov/healthworkforce/supplydemand/usworkforce/chartbook/chartbook3.pdf
Technical Basis for User Interface Design of Health IT

135

• Sex: Approximately 88.8% are female and 11.2% are male28

• Population: As of 2012, there were around 111,297 data analysts29

7.2.3 Education 

Data analysts are encouraged to begin taking courses on health, computer science, math, and 

biology while in high school. Technicians can then earn an associate degree in health information 

technology or earn postsecondary certificates. Coursework in these postsecondary programs 

emphasizes the following areas:

• Medical terminology

• Anatomy and physiology

• Health data requirements and standards

• Classification and coding systems

• Healthcare reimbursement methods

• Healthcare statistics

• Computer systems30

7.2.3.1 Certification

Employers prefer to hire data analysts who have earned a professional certification. There are 

numerous certifications offered by several organizations in the field of health information. 

Common certifications include Registered Health Information Technician (RHIT), Registered 

Health Information Administrator (RHIA), and Certified Tumor Registrar (CTR).31 Some 

organizations base certification on passing an exam while others require graduation from an 

accredited program. 

7.2.4 Electronic Health Record (EHR) Use environment(s)

Healthcare information technicians work primarily in hospitals, but also in office-based practices, 

long-term care facilities, and public health agencies. Additionally, facilities that use patient data or 

health information, such as pharmaceutical companies, insurance firms and health product 

vendors, might also need data analysts.32

 28 Page 18, Figure 24, http://bhpr.hrsa.gov/healthworkforce/supplydemand/usworkforce/chartbook/chartbook3.pdf 29 Page 16, Figure 24, http://bhpr.hrsa.gov/healthworkforce/supplydemand/usworkforce/chartbook/chartbook3.pdf 30 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-records-and-health-informationtechnicians.htm#tab-4 31 http://www.bls.gov/ooh/healthcare/medical-records-and-health-information-technicians.htm#tab-4 32 Adapted from text found at http://www.ahima.org/certification/RHIT
Technical Basis for User Interface Design of Health IT

136

 

Health Information Technicians interacting with EHRs.33

7.2.5 Experience using computers

Data analysts work with computers all day long. Thus, they typically have a high comfort level 

with computers and are more likely to have a clear mental model of computer-based data 

management, including uploading and downloading data and using computers to access other 

data sources. Those data analysts who did not use computers during schooling might be less 

comfortable exploring computer functions might perform some tasks with less efficiency.

7.2.6 Sample EHR tasks

• Retrieve patient records for medical personnel

• Work as a liaison between the health clinician and billing offices

• Review patient information for preexisting conditions

• Ensure patient records and reports are accurate and complete

• Assign correct classification codes (e.g., ICD-10 codes) to represent diagnosis and 

treatment

• Analyze and compile patient information for cancer registries and research purposes

 33 Photo sources: http://www.academyofmedicalprofessions.com/hospitalbillingandcoding.asp, 

http://inside.akronchildrens.org/2013/05/22/a-day-in-the-life-medical-coders/, 

http://inside.akronchildrens.org/2013/05/22/a-day-in-the-life-medical-coders/
Technical Basis for User Interface Design of Health IT

137

• Maintain facility, regional, and national databases of patients

• Ensure diagnoses and procedures are coded correctly and submitted for billing

• Track patient outcomes for quality assessment

• Communicate with providers to clarify diagnoses confirm accuracy of records

7.2.7 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, are just some of those that can influence technicians’ interactions with EHRs:

• Repetitive Tasks. Facing repetitive tasks and alerts can drive users to seek 

workarounds and ignore pop-ups

• Need for clinician input. Confirming details or consulting with clinicians with intensive 

schedules might delay work 

• Staring at computer screens. Staring at computer screens for long periods of time 

reviewing information and, therefore, might use shortcuts and overlook key details

• Continually changing environments. Continually changing environments make it 

challenging to keep up – shifting from acquiring information and documenting on paper to 

using a software-based solution, as well as switching from ICD-9 codes to ICD-10 codes 

(mandatory after October 1, 2015)

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material forces the data 

analyst to rely on memory to recall procedures and instructions

7.3 Technologists and Technicians

7.3.1 Occupational description

A technologist or technician’s occupational responsibility is based on his/her specialty and the 

environment in which s/he works. Technicians often perform routine tests, while technologists 

carry out more complicated tasks and supervise technicians. Technologists and technicians in 

large laboratories are inclined to specialize, while technologists and technicians in small 

laboratories perform a variety of tasks and procedures.
Technical Basis for User Interface Design of Health IT

138

We focus on the following types of specialized technologists in this profile:

• Medical laboratory technologists and medical laboratory technicians collect samples and 

perform medical laboratory tests on body fluids and tissues34

• Radiologic technologists use imaging techniques to perform medical imaging exams and 

administer radiation therapy treatments35

7.3.2 Demographics (USA)

• Age: Average in the USA is 43 years for technologists36,37

• Sex: Approximately 72% are female, 28% are male (as of 2010)38

• Population: 325,800 medical and clinical laboratory technologists and technicians (as of 

2012)39 and 229,300 radiologic and magnetic resonance imaging technologists (as of 

2012)40

7.3.3 Education

There are numerous pathways to become a technologist or a technician. Specific specialties have 

varying requirements for training. Outlined below are examples of ways that one might become a 

technologist or technician. 

7.3.4 Technologists

Typically, entry-level medical technologists need to earn a bachelor’s degree in life sciences or 

medical technology. An accredited bachelor’s program in medical laboratory technology focuses 

on chemistry, biology, mathematics, and statistics, as well as laboratory skills and management.41

Many states require radiologic technologists to complete a postsecondary education program 

accredited by the Joint Review Committee on Education in Radiologic Technology in radiography 

or MRI to earn a license. Graduates of such postsecondary programs can leave with graduate 

certificates, associate degrees, or bachelor’s degrees. Associate degree programs that include 

both classroom and clinical training are the most common.42

7.3.5 Technicians

Medical laboratory technicians must complete an associate degree program in clinical laboratory 

science or a related field. Technicians can enter the field by earning certificates through the 

 34 http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-and-technicians.htm 35 Adapted from text found at http://money.usnews.com/careers/best-jobs/radiologic-technologist 36 http://www.asrt.org/docs/default-source/research/r13_wagesalarysurvey.pdf?sfvrsn=2 and 37 http://www.ascp.org/pdf/MedicalLaboratoryPersonnelShortage.aspx 38 http://www.asrt.org/docs/default-source/research/r13_wagesalarysurvey.pdf?sfvrsn=2 39 http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-and-technicians.htm#tab-1 40 http://www.bls.gov/ooh/healthcare/radiologic-technologists.htm#tab-1 41 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-andtechnicians.htm#tab-4 42 Adapted from text found at http://www.bls.gov/ooh/healthcare/radiologic-technologists.htm#tab-4
Technical Basis for User Interface Design of Health IT

139

armed forces, vocational or technical schools, or hospitals programs. Expedited certificate 

programs exist for those who already have a degree in a related field, such as nursing.43

7.3.6 Licensure, certifications, and registrations

Licensure, certification, and registration requirements vary by state, specialty, and employer. To 

earn a license, a technologist or technician often needs to have graduated from an accredited 

program and passed an exam.

44 The American Society for Clinical Pathology Board of 

Certification provides certification for laboratory personnel, including medical laboratory scientists 

(MLS) and medical laboratory technicians (MLT).

7.3.7 Electronic Records (EHR) Use environment(s)

More than half of all technologists and technicians work in medical and surgical hospitals. Other 

sites of employment include physician offices, medical and diagnostic laboratories, and outpatient 

care centers.

Medical and clinical laboratory technologists and technicians often wear protective masks, gloves, 

and eye protection when working with infectious specimens or flammable materials.45 Radiologic 

technologists minimize the risk of radiation hazards by using lead aprons, gloves, and other 

shielding devices, while also monitoring exposure to radiation.46

 Medical, clinical, and radiologic technicians and technologists interacting with electronic health 

records (EHRs).47

7.3.8 Experience using computers

In general, technicians and technologists are bimodal in their use of computers and EHRs. This 

largely depends on whether the technician or technologist used computers during his/her 

 43 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-andtechnicians.htm#tab-4 44 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-andtechnicians.htm#tab-4 45 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-andtechnicians.htm#tab-3 46 Adapted from text found at http://www.bls.gov/ooh/healthcare/radiologic-technologists.htm#tab-3 47 Photo sources: http://aphealthrecords.com/portfolio_ibusiness/laboratory/,

http://inside.akronchildrens.org/2013/04/23/a-day-in-the-life-medical-lab-technician/, 

http://www.amberusa.com/dmxreadyv2/blogmanager/blogmanager.asp?category=37&pageindex=7
Technical Basis for User Interface Design of Health IT

140

education. Thus, older technicians or technologists are generally less comfortable with computers 

and EHRs.

Due to computer use starting in childhood, younger technicians or technologists are more likely to 

have experience with and be comfortable participating in computer-based training. Technicians or

technologists who used computers throughout their schooling are generally more inclined to 

explore unfamiliar functions and perform tasks with high efficiency. 

Younger technicians or technologists might also have a clearer mental model of computer-based 

data management, including uploading and downloading data and using computers to access 

other data sources. Those who did not use computers during schooling are generally less 

comfortable exploring computer functions and in some cases perform tasks with less efficiency.

Typing speed is not necessarily a function of age. While younger technicians or technologists 

might have used computers since childhood and have become proficient typists, older technicians

or technologists might have taken typing classes, which were more common in years past, and 

also become fast at data entry tasks due to their own cumulative years of interacting with 

computers.

7.3.9 Sample EHR tasks

• Read and carry out orders for diagnostic tests or procedures

• Prepare patients for procedures (e.g., record medical history)

• Document care, such as administering a test or procedure

• Communicate with physicians to evaluate the images or samples

• Print, fax, and send orders and results for laboratory tests and procedures

• Document communication with other facilities (e.g., that an order has been faxed)

• Record data from medical tests and enter results into a patient’s record48

7.3.10 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, could be expected to influence technicians’ and technologists’ interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading technicians and technologists to seek shortcuts and workarounds to 

complete required tasks in time available

• Production pressures. Technicians and technologists can face significant production 

pressure in their daily work. For example, insufficient time between patients to perform 

 48 Adapted from text found at http://www.bls.gov/ooh/healthcare/medical-and-clinical-laboratory-technologists-andtechnicians.htm#tab-2
Technical Basis for User Interface Design of Health IT

141

tests or procedures can make technicians and technologists more likely to avoid seeking 

information, to delay entering data into the EHR or to enter less information than they 

would otherwise. Such behaviors could require them to rely more on memory to correctly 

recall and associate information and observations about a patient

• Need for clinician input. Confirming details or consulting with physicians or nurses who 

are difficult to reach might delay work and contribute to production pressure

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Developing alarm fatigue. Developing alarm fatigue can lead to ignored or missed 

audible alarms, as well as a disdain for onscreen warnings

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference materials can make

technicians and technologists rely on memory to recall procedures and instructions

• Interaction effect. Wearing protective equipment such as gloves can inhibit movement, 

visibility, and typing

• Stress of dealing with difficult patients or situations. Under stressful conditions, 

technicians and technologists might be more likely to take shortcuts, miss relevant cues, 

or to become frustrated when presented with obstacles to achieving their clinical goals 

while using the EHR 

7.4 Nurse

7.4.1 Occupational description

A nurse’s role is based on his/her professional scope of practice (licensure), specialty field, 

experience, the environment in which s/he works, and the patients s/he serves. Nurses, including 

registered nurses (RNs), licensed practical nurses (LPNs), and licensed vocational nurses 

(LVNs), most often work as part of a team that includes physicians, other nurses, ancillary staff 

(e.g., respiratory therapists, physical therapists), and medical assistants. Some RNs oversee the 

work of other nurses, nursing assistants, and home health aides. An increasing number of RNs 

now work in roles outside the traditional direct patient care role, such as health systems 

management, research, and informatics. This profile specifically excludes advanced practice 

nurses (APN) such as nurse anesthetists, nurse midwives, and nurse practitioners (all of whom 

must first be RNs).

A nurse’s work might focus on one or more of the following specific fields:
Technical Basis for User Interface Design of Health IT

142

• A health condition, such as diabetes

• A body part, such as the skin

• A group of people, such as the elderly 

• A workplace, such as an emergency department in a hospital

Some nursing tasks common to most nurses are the following:

• Consult with doctors and other healthcare professionals

• Record patients' medical histories, symptoms, and vital signs

• Administer patients’ medicines and treatments

• Contribute to plans for patient care

• Coordinate patient care in collaboration with other healthcare professionals

• Observe patients and record observations

• Operate medical equipment

• Help perform diagnostic tests and analyze results

• Serve as an interface and resource between patients and their families, and healthcare 

providers and other elements of the healthcare system 

• Teach patients and their families how to manage illnesses or injuries

RNs provide a more advanced level of professional nursing care than do LVNs or LPNs. RNs 

structure their work around the nursing process, which involves assessing a wide range of factors 

that impact a patient’s health and well-being (e.g., physiological, psychosocial, spiritual, and 

environmental factors) and applying clinical judgment to identify a patient’s problems or potential 

problems.49 Based on this ongoing assessment and nursing diagnosis process, RNs develop and 

implement a nursing plan of care to address the individual patient’s needs and evaluate patient 

outcomes.

7.4.2 Demographics (USA)

• Age: Average ages are 44.6 years for RNs and 43.6 years for LPNs50

• Sex: Approximately 91% of nurses are female (as of 2011)51

• Population: 3,063,163 RNs as of 200852 and 738,400 LPNs and LVNs as of 201253

 49 http://www.nursingworld.org/EspeciallyForYou/What-is-Nursing/Tools-You-Need/Thenursingprocess.html 50 HRSA analysis of the ACS 2008-2010 three-year file; HRSA analysis of the ACS 2008-2010 three-year file 51 HRSA analysis of the ACS 2008-2010 three-year file; HRSA analysis of the ACS 2008-2010 three-year file
Technical Basis for User Interface Design of Health IT

143

7.4.3 Education

There are numerous pathways to becoming a nurse. Becoming an RN requires the completion of 

a post-secondary education program and earning an associate or bachelor's degree. Very few 

hospitals still have teaching/training programs that offer diplomas. Aspiring nurses learn about a 

wide breadth of topics, including anatomy and human development, and gain clinical experience 

through progressive, supervised practice.

7.4.3.1 LPNs and LVNs

LPNs and LVNs provide basic or routine nursing care under the clinical supervision of an RN, 

APN, or MD. LPNs and LVNs require a certificate or diploma from programs typically found in 

technical schools and community colleges. The programs span a year or more and include 

coursework and supervised clinical experiences. Common courses include:

• Pharmacology 

• Nursing

• Biology

7.4.3.2 Associate Degree in Nursing

Many RNs enter the profession after earning an Associate Degree in Nursing (ADN) or Associate 

of Science in Nursing (ASN). Associate degree programs typically span 2-3 years and are 

available at community and vocational colleges. The programs include classroom instruction to 

prepare nurses for generalist practice, as well as hands-on training in hospitals, clinics, or other 

healthcare settings. 

Common courses include: 

• Adult and family health 

• Psychiatric nursing 

• Pharmacology 

• Human development 

• Anatomy and physiology 

According to the U.S. Bureau of Labor Statistics (BLS), nurses who have earned associate 

degrees or diplomas often pursue bachelor's degrees later in their careers.

7.4.3.3 Bachelor of Science in Nursing

 52 http://bhpr.hrsa.gov/healthworkforce/rnsurveys/rnsurveyinitial2008.pdf 53 http://bhpr.hrsa.gov/healthworkforce/reports/nursingworkforce/nursingworkforcefullreport.pdf
Technical Basis for User Interface Design of Health IT

144

RNs can take a more comprehensive educational path by earning a Bachelor of Science in 

Nursing (BSN). Colleges and universities offer BSN programs that typically span four years. 

However, students already licensed as RNs or possessing a bachelor’s degree in another field 

might complete accelerated programs. 

BSN programs concentrate on more advanced nursing practices and clinical training than lowerlevel degree programs. They provide students with the administrative and critical thinking skills 

necessary for advanced positions in the field. 

Common courses include: 

• Community health 

• Leadership in nursing 

• Healthcare management 

• Nursing research 

• Health assessment 

• Professional issues in nursing54

7.4.3.4 Licensure

To practice in a specific state, all nurses must earn and maintain a nursing license in that state or 

in a state participating in the multistate Nursing Licensure Compact. While licensure requirements 

vary by state, nurses must complete a state-approved training program and pass examinations by 

the National Council of State Boards of Nursing. Passing the National Council Licensure 

Examination for Registered Nurses (NCLEX-RN) is a requirement to work as an RN. The NCLEXRN covers topics like psychosocial and physiological integrity, health promotion, and infection 

control. All states require LPNs and LVNs to pass the National Council Licensure Examination 

(NCLEX-PN). Depending on the state, nurses might be required to meet additional licensure 

requirements.

7.4.4 Electronic Health Record (EHR) Use Environment(s)

Nurses work in a wide variety of environments, including hospitals, clinics, physicians' offices, 

home healthcare service organizations, nursing care facilities, schools, correctional facilities, and 

military healthcare settings.

55 In almost all of these settings, nurses document patient information, 

clinical assessments, and patient interactions in EHR systems. 

 54 Adapted from text found at 

http://study.com/articles/Registered_Nurse_RN_Educational_Requirements_for_Registered_Nurses.html; internal 

reference to www.bls.gov and www.ncsbn.org and 55 Adapted from text found at http://www.bls.gov/ooh/healthcare/registered-nurses.htm
Technical Basis for User Interface Design of Health IT

145

7.4.5 LPNs and LVNs

Licensed practical vocational nurses often work in nursing homes, long-term care facilities, 

hospitals, physician offices, and private homes. The following table outlines the work locations for 

these nurses in 2012. 

Employment settings56 %57

Nursing care facilities 29

Hospitals 20

Offices of physicians 12

Home health care services

Residential care facilities

11

 8

7.4.6 Registered Nurses

The following table provides the distribution of registered nurses working in various hospital 

settings. Note that nurses work in many more settings that those listed and that some work in 

more than one setting.

Hospital settings58 %

General or specialty inpatient unit 38

Critical or intensive care unit 21

Perioperative (OR, pre- or post-op care unit) 19

Step down-transitional-progressive-telemetry 12

Emergency department 11

The following table provides the distribution of RNs working in various non-hospital settings.

Again, note that RNs work in many more settings that those listed and that some work in multiple 

settings.

 56 Data Source: http://www.bls.gov/ooh/healthcare/licensed-practical-and-licensed-vocational-nurses.htm#tab-3 57 Note: Table taken from the Bureau of Labor and Statistics. Values add up to 80% which likely excludes other work 

environments or non-responses from BLS report. 58 Data source: 2008 National Sample Survey of Registered Nurses 
Technical Basis for User Interface Design of Health IT

146

Non-hospital settings59 %

Ambulatory care 24

Home health 16

Long-term care/skilled nursing facility 14

Business/administration/review 14

Public/community health 12

Education 12

General or specialty inpatient 11

Nurses using an EHR at a central station (left, center) and in a post-anesthesia unit (right).

60

7.4.7 Experience using computers

In general, nurses are bimodal in their use of computers and EHRs. This largely depends on 

whether the nurse used computers during his/her education. Thus, older nurses are generally 

less comfortable with computers and EHRs.

Due to computer use starting in childhood, younger nurses are more likely to have experience 

with and be comfortable participating in computer-based training. Nurses who used computers 

throughout their schooling are generally more inclined to explore unfamiliar functions and perform 

tasks with high efficiency. 

Younger nurses might also have a clearer mental model of computer-based data management, 

including uploading and downloading data and using computers to access other data sources. 

Those who did not use computers during schooling are generally less comfortable exploring 

computer functions and in some cases perform tasks with less efficiency.

Typing speed is not necessarily a function of age. While younger nurses might have used 

computers since childhood and have become proficient typists, older nurses might have taken 

 59 Data source: 2008 National Sample Survey of Registered Nurses 60 Photo sources: http://www.lecontemedicalcenter.com/upload/images/APaletz-LeConte/ICU_Hall_08.jpg, 

http://static01.nyt.com/images/2014/05/29/nyregion/LINCOLNweb3/LINCOLNweb3-articleLarge.jpg, 

http://2.bp.blogspot.com/-KlJrj9BzDEc/U6pqK0TtCeI/AAAAAAAAABc/I472v8aHLUU/s1600/Jim+West+

photo+for+RN+documentation+article.jpg
Technical Basis for User Interface Design of Health IT

147

typing classes, which were more common in years past, and have also become efficient at data 

entry tasks due to their own cumulative years of interacting with computers.

7.4.8 Sample EHR tasks by nurses

• Enter patient medical history 

• Enter vital signs (e.g., heart rate, blood pressure, oxygen saturation) into patient chart

• View patient lab and test results (e.g., cholesterol, liver function tests, x-ray)

• View patient history

• View physician’s notes

• Review patient medication list

• Review pediatric patients’ growth charts 

• Access and print educational materials for patients

• Enter verbal/phone orders for lab tests (e.g., rapid flu test, CT scan, CBC), vaccines, and 

procedures on behalf of the MD

• Order referrals (e.g., for specialists, ancillary care) on behalf of the MD.

• Print, fax, or electronically send orders to other healthcare facilities

• Barcode scan medications and document administration

• Document a patient’s physical assessment

• Document pain scores and interventions

• Document patient intake and output (e.g., intravenous fluid volumes, fluid taken orally, 

urinary output)

• Document care, such as administering a vaccine or providing patient education

• Document nursing plan of care

• Document patient communication (e.g., a patient phone call)

• Schedule appointments 

• Add new patient information into the system

• Review physicians’ schedules
Technical Basis for User Interface Design of Health IT

148

• Perform patient admission assessments 

• Perform patient discharge and transfer assessments

• Communicate with patients via secure email regarding follow-up inquiries

• Communicate with office staff and other clinicians

7.4.9 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, could be expected to influence nurses’ interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading users to seek shortcuts and workarounds to complete required tasks 

in time available

• Little time between patients. Lacking time between patients can make nurses more 

likely to delay entering data into the EHR. This would require them to rely more on 

memory to correctly recall and associate information and observations with the correct 

patient

• Working with multiple patients simultaneously. This requires nurses to rely more on 

memory to correctly recall and associate information and observations with the correct 

patient

• Need for clinician input. Confirming details or consulting with clinicians with intensive 

schedules might delay work

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Developing alarm fatigue. Developing alarm fatigue can lead to ignored or missed 

audible alarms, as well as a disdain for on-screen warnings

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material (e.g., user 

manual, quick reference guide) can lead the nurse to rely on memory to recall operating 

procedures

• Interaction effect. Wearing protective equipment such as gloves might inhibit 

movement, visibility, and typing
Technical Basis for User Interface Design of Health IT

149

7.5 Advanced Practice Registered Nurse

7.5.1 Occupational description

Advance Practice Registered Nurses (APRN) increase access to health care by providing primary 

and secondary care services. APRN are registered nurses with additional graduate level 

education and national certification. There are four main APRN roles:

• Nurse Practitioners (NP) – serve in primary and specialty care settings within the hospital 

and outpatient care

• Nurse Anesthetists (CRNA) – primarily work in hospitals providing care and delivery of 

anesthesia for surgical, diagnostic and therapeutic procedures (see User Profile #10, 

Anesthesia Care Providers)

• Nurse-midwives (CNM) – provide primary care for a wide range of women’s health 

services (e.g., gynecological, prenatal, labor and delivery, postpartum)

• Clinical Nurse Specialists (CNS) – provide patient care and expertise in a specialty area 

based on a patient population, care setting, or disease process (e.g., diabetes, wounds)

The scope of practice for APRNs varies by state and specialty, and is determined by individual 

state laws and regulations. Many APRN can diagnose and treat acute, episodic, or chronic 

illnesses, as part of a healthcare team and increasingly, independently, depending on the state. 

Nurse practitioners may prescribe medicine as well as order, perform, or interpret diagnostic 

tests, independently or under the supervision of a physician depending on the state.61 We will 

focus primarily on NPs throughout this paper.

An APRN’s occupational responsibility often depends on the work site and patient population. 

APRNs may work under physician supervision, in collaboration with a team of physicians and 

other healthcare professionals, but an increasing number of states allow APRNs to work 

autonomously. The table below shows a breakdown of specialties for NPs involved in patient 

care.62

Practice Specialty for NPs63 %

Primary Care 48

Other 20

Internal Medicine Subspecialties 13

Surgical Specialties 9

Psychiatry/Mental Health 6

Pediatric Subspecialties 3

 61 Adapted from text found at http://www.bls.gov/oes/current/oes291171.htm 62 Adapted from text found at 2012 National Sample Survey of Nurse Practitioners 63 Data source: 2012 National Sample Survey of Nurse Practitioners
Technical Basis for User Interface Design of Health IT

150

No Specialty 1

7.5.2 Demographics (USA)

• Age: 48 years on average for NPs64

• Sex: Approximately 93% of NPs are female65

• Population: As of 2014, there are around 205,000 NPs66

7.5.3 Education

All APRNs have additional education and clinical training beyond their training as a Registered 

Nurse. An APRN must earn a bachelor’s degree in nursing, a registered nurse license, a 

graduate nursing degree (either a masters in nursing or a doctor of nursing practice degree), 

national board certification, and state licensure and registration.67

7.5.3.1 Licensure

After achieving board certification by passing a national examination, APRNs can earn additional 

credentials at the state and federal level.

68 All APRNs must complete continuing education (CE) 

and/or pass recertification exams throughout their career, as well as fulfill minimum practice time 

requirements, to maintain an APRN license. CE requirements vary by state and professional 

organization but share the goal of ensuring APRNs’ knowledge and skills remain abreast of 

modern technological advances and medical discoveries.

7.5.4 Electronic Health Record (EHR) Use environment(s)

APRNs work and use EHRs in a wide variety of environments, including inpatient and outpatient 

hospital units, retail-based clinics, federal clinics, long-term care facilities, private physician or NP 

offices, home healthcare service organizations, nursing care facilities, schools, correctional 

facilities,

69 and military healthcare70 settings.

The following table provides the distribution of NPs working in various environments. Note that 

NPs work in many more settings than those listed and some work in multiple settings.

Primary Work Settings71 %

Ambulatory 57

Hospital 31

Long-Term and Elder Care 5

 64 2012 National Sample Survey of Nurse Practitioners 65 2012 National Sample Survey of Nurse Practitioners 66 AANP National NP Database, 2014 67 Adapted from text found at http://www.aanp.org/images/about-nps/npgraphic.pdf 68 Adapted from text found at http://www.nursepractitionerschools.com/faq/np-vs-physician-assistant 69 Adapted from text found at 

http://bhpr.hrsa.gov/healthworkforce/supplydemand/nursing/nursepractitionersurvey/npsurveyhighlights.pdf

70 http://www.airforce.com/careers/detail/nurse-practitioner/ 71 Data source: 2012 National Sample Survey of Nurse Practitioners
Technical Basis for User Interface Design of Health IT

151

Other Setting 5

Public or Community Health 2

Advanced Practice Nurses interacting with EHRs.72

7.5.5 Experience using computers

In general, APRNs are bimodal in their use of computers and EHRs. This largely depends on 

whether the APRN used computers during his/her education. Thus, older APRNs are generally 

less comfortable with computers and EHRs.

Due to computer use starting in childhood, younger APRNs are more likely to have experience 

with and be comfortable participating in computer-based training. APRNs who used computers 

throughout their schooling are generally more inclined to explore unfamiliar functions and perform 

tasks with high efficiency. 

Younger APRNs might also have a clearer mental model of computer-based data management, 

including uploading and downloading data and using computers to access other data sources. 

Those who did not use computers during schooling are generally less comfortable exploring 

computer functions and in some cases perform tasks with less efficiency.

Typing speed is not necessarily a function of age. While younger APRNs might have used 

computers since childhood and have become proficient typists, older APRNs might have taken 

typing classes, which were more common in years past, and also become fast at data entry tasks 

due to their own cumulative years of interacting with computers.

7.5.6 Representative EHR tasks

• Enter, edit, and view key patient information and reminders (e.g., allergies, problems,

physician notes including assessment and plan)

• Reconcile the patient’s medication list

 72 Photo sources: http://newoldage.blogs.nytimes.com/2013/08/22/a-surgical-center-for-older-patients/?_r=0, 

http://www.newsworks.org/index.php/local/healthscience/79826-pa-bill-would-allow-nurse-practitioners-to-workindependent-from-doctors, http://www.usatoday.com/story/news/nation/2014/08/18/nurse-practitioner-independencelaws/13470733/
Technical Basis for User Interface Design of Health IT

152

• Review diverse clinical materials to obtain a picture of the patient’s current status, to

make diagnoses, and to initiate or modify a care plan (e.g., review pediatric patients’ 

growth charts and prior notes to assess the effects of prior treatment(s))

• Create or update a problem list, allergies, or other patient summary information.

• Initiate patient referrals to physicians and other clinicians (e.g., consultation with a 

specialist or assessment/intervention by another healthcare providers such as a dietician 

or speech therapist)

• Prescribe and transmit prescriptions electronically (outpatient or discharge)

• Enter medication orders (inpatient)

• Enter orders for vaccines, laboratory or diagnostic tests, and procedures (inpatient or 

outpatient)

• Modify or discontinue orders

• Receive, view, and acknowledge a patient’s lab results (e.g., cholesterol, liver function 

tests)

• Communicate with colleagues about patient status or care plan issues.

• View patient data and other information in a chronological order to assess care trajectory

• Access and print patient educational materials

• Order or request follow-up appointments

• Communicate securely with patients electronically regarding inquiries

7.5.7 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, are just some of those that can influence an NP’s interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading users to seek shortcuts and workarounds to complete required tasks 

in time available

• Production Pressures. APRNs can face significant production pressure in their daily 

work. For example, insufficient time to see patients or between patients can make

APRNs more likely to avoid seeking information, to delay entering data into the EHR or to 

enter less information than they would otherwise. Such behaviors could require them to

rely more on memory to correctly recall and associate information and observations 

about a patient
Technical Basis for User Interface Design of Health IT

153

• Working with multiple patients simultaneously. This requires APRNs to rely more on 

memory to correctly recall and associate information and observations with the correct 

patient

• Need for clinician input. Confirming details or consulting with physicians with intensive 

schedules might delay work 

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Developing alarm fatigue. Developing alarm fatigue can lead to ignored or missed 

audible alarms, as well as a disdain for onscreen warnings

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference materials can make

APRNs rely on memory to recall procedures and instructions

• Interaction effect. Wearing protective equipment such as gloves can inhibit movement, 

visibility, and typing

• Stress of dealing with difficult patients or situations. Under stressful conditions, 

APRNs might be more likely to take shortcuts, miss relevant cues, or to become 

frustrated when presented with obstacles to achieving their clinical goals while using the 

EHR

• Fatigue and Sleep Deprivation. APRNs can sometimes work long hours or can be 

working under the effects of acute and chronic sleep loss. This can lead to inattention, 

haste, a lower likelihood of detecting information presented in an EHR (thus suggesting a 

need to make critical information more salient), and a higher likelihood of ignoring 

prompts

7.6 Physician Assistant

7.6.1 Occupational description

Physician Assistants (PAs) increase patient access to healthcare by providing primary and 

secondary care services under the direct supervision of a physician. PAs scope of practice varies 

by state law, facility policies, and individual education and experience. PAs typically perform a 

wide range of tasks delegated by a physician as part of a healthcare team including diagnose and 

treat acute, episodic, or chronic illnesses; prescribe medications; order, perform, or interpret test 

results, and even assist in the conduct of surgical procedures. Thus, PAs often function in a 

manner similar to nurses or even advanced practice nurses.
Technical Basis for User Interface Design of Health IT

154

A PA’s occupational responsibility and title often depend on specialty, work environment and 

patient population served. PAs must work with physician oversight, although the extent of 

oversight varies by state and specialty. The following table lists the distribution of PAs across 

common specialties:

Practice Specialty for PAs %73

Primary Care 32

Surgical Subspecialties 27

Other Specialties 19

Emergency Medicine 11

Internal Medicine Subspecialties 10

Pediatric Subspecialties 2

7.6.2 Demographics (USA)

• Age: 37 years on average74

• Sex: Approximately 67% are female and 33% are male for clinically practicing PAs75

• Population: As of 2015, there are around 91,935 PAs76

7.6.3 Education

Before entering an accredited PA program, PAs must hold a bachelor’s degree and have 

approximately three years of hands-on patient care experience. A typical PA program is three 

years long and includes classroom instruction and 2,000 hours of clinical rotations. PA students 

study several subjects including anatomy, physiology, physical diagnosis, pathophysiology, and 

medical ethics. 

The PA’s clinical rotations include generalist primary care in ambulatory clinics, physician offices, 

and long-term care facilities. In more advanced rotations, the PA might focus on one or more of 

the following: family medicine, internal medicine, obstetrics and gynecology, pediatrics, general 

surgery, emergency medicine, and psychiatry.77

7.6.3.1 Licensure

A PA program graduate earns a master’s degree and is eligible to take the Physician Assistant 

National Certifying Exam (PANCE), which is an exam administered by the National Commission 

 73 Note: Table taken from the 2013 AAPA Annual Survey Data Tables. Values add up to 101% which is likely due to 

rounding errors.

Data source: https://www.aapa.org/WorkArea/DownloadAsset.aspx?id=2902

74 2013 AAPA Annual Survey Report https://www.aapa.org/WorkArea/DownloadAsset.aspx?id=2902 75 2013 AAPA Annual Survey Report https://www.aapa.org/WorkArea/DownloadAsset.aspx?id=2902 76 http://kff.org/other/state-indicator/total-physician-assistants/ 77 Adapted from https://www.aapa.org/Become-a-PA/
Technical Basis for User Interface Design of Health IT

155

on Certification of Physician Assistants (NCCPA).78 All PAs must pass the PANCE and meet all 

state-specific requirements to obtain a license to see patients as a PA. 

All PAs must complete continuing medical education (CME) and take recertification exams 

throughout their career to maintain a PA license. CME requirements vary by state and 

professional organization but share the goal of ensuring that PA’s knowledge and skills remain 

abreast of modern technological advances and medical discoveries.

7.6.4 Electronic Health Record (EHR) Use environment(s)

PAs work in a wide variety of environments, including inpatient and outpatient hospital units, 

retail-based clinics, federal clinics, long-term care facilities, private physician offices, home 

healthcare service organizations, nursing care facilities, schools, correctional facilities, and

military healthcare settings.

79 The following table provides the distribution of PAs working in 

various settings.

PAs interacting with EHRs.

81

7.6.5 Experience using computers

In general, PAs are bimodal in their use of computers and EHRs. This largely depends on 

whether the PA used computers during his/her education. Thus, older PAs are generally less 

comfortable with computers and EHRs.

 78 Adapted from https://www.aapa.org/Become-a-PA/ 79 https://www.aapa.org/WorkArea/DownloadAsset.aspx?id=898 80 Data source: http://www.bls.gov/ooh/healthcare/physician-assistants.htm#tab-3 81 Photo sources: http://www.cepamerica.com/news-resources/perspectives-on-the-acute-care-continuum/2015-january/3-

barriers-(and-1-solution)-to-successful-ehr-adop, http://www.northshore.org/physicians/epic-training/, 

http://www.usatoday.com/story/news/nation/2015/05/25/athenahealth-epic-safety-reliability-electronic-healthrecords/27499877/

Primary Work Settings80 %

Physician’s offices 58

Hospital 23

Outpatient care centers 7

Government 4

Educational services 3
Technical Basis for User Interface Design of Health IT

156

Due to computer use starting in childhood, younger PAs are more likely to have experience with 

and be comfortable participating in computer-based training. PAs who used computers 

throughout their schooling are generally more inclined to explore unfamiliar functions and perform 

tasks with high efficiency. 

Younger PAs might also have a clearer mental model of computer-based data management, 

including uploading and downloading data and using computers to access other data sources. 

Those who did not use computers during schooling are generally less comfortable exploring 

computer functions and in some cases perform tasks with less efficiency.

Typing speed is not necessarily a function of age. While younger PAs might have used 

computers since childhood and have become proficient typists, older PAs might have taken 

typing classes, which were more common in years past, and also become fast at data entry tasks 

due to their own cumulative years of interacting with computers.

7.6.6 Sample EHR tasks

• Enter, edit, and view key patient information and reminders (e.g., allergies, problems,

physician notes including assessment and plan)

• Reconcile the patient’s medication list

• Review diverse clinical materials to obtain a picture of the patient’s current status, to 

make diagnoses, and to initiate or modify a care plan (e.g., review pediatric patients’ 

growth charts and prior notes to assess the effects of prior treatment(s))

• Create or update a problem list, allergies, or other patient summary information

• Initiate patient referrals to other physicians and other clinicians (e.g., consultation with a 

specialist or assessment/intervention by another healthcare providers such as a dietician 

or speech therapist)

• Prescribe and transmit prescriptions electronically (outpatient or discharge)

• Enter medication orders (inpatient)

• Enter orders for vaccines, laboratory or diagnostic tests, and procedures (inpatient or 

outpatient)

• Modify or discontinue orders

• Receive, view, and acknowledge a patient’s lab results (e.g., cholesterol, liver function 

tests)

• Communicate with colleagues about patient status or care plan issues.

• View patient data and other information in a chronological order to assess care trajectory
Technical Basis for User Interface Design of Health IT

157

• Access and print patient educational materials

• Order or request follow-up appointments

• Communicate securely with patients electronically regarding inquiries

7.6.7 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, are just some of those that can influence PA’s interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading PAs to seek shortcuts and workarounds to complete required tasks 

in time available

• Production Pressures. PAs can face significant production pressure in their daily work. 

For example, insufficient time to see patients or between patients can make PAs more 

likely to avoid seeking information, to delay entering data into the EHR or to enter less 

information than they would otherwise. Such behaviors could require them to rely more 

on memory to correctly recall and associate information and observations about a patient

• Working with multiple patients simultaneously. This requires PAs to rely more on 

memory to correctly recall and associate information and observations with the correct 

patient

• Need for clinician input. Confirming details or consulting with physicians with intensive 

schedules might delay work 

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Developing alarm fatigue. Developing alarm fatigue can lead to ignored or missed 

audible alarms, as well as a disdain for onscreen warnings

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference materials can make

PAs rely on memory to recall procedures and instructions

• Interaction effect. Wearing protective equipment such as gloves can inhibit movement, 

visibility, and typing
Technical Basis for User Interface Design of Health IT

158

• Stress of dealing with difficult patients or situations. Under stressful conditions, PAs 

might be more likely to take shortcuts, miss relevant cues, or to become frustrated when 

presented with obstacles to achieving their clinical goals while using the EHR

• Fatigue and Sleep Deprivation. PAs might sometimes work long hours or can be 

working under the effects of acute and chronic sleep loss. This can lead to inattention, 

haste, a lower likelihood of detecting information presented in an EHR (thus suggesting a 

need to make critical information more salient), and a higher likelihood of ignoring 

prompts

7.7 Anesthesia Care Providers

7.7.1 Occupational description

Anesthesia care providers (ACPs) include anesthesiologists, certified registered nurse 

anesthetists (CRNAs), and anesthesia assistants. ACPs provide pre-, intra-, and post-operative 

care of surgical patients as well as patients undergoing other invasive procedures requiring 

anesthesia care (e.g., gastroenteroscopy, interventional cardiology and radiology, pediatric 

diagnostic radiology and radiation oncology). In addition to their pre- and post-operative uses of 

EHRs, which is similar to that of surgeons and advanced practice nurses, ACPs have a relatively 

unique use for EHRs in the intraoperative period. During this time, ACPs contemporaneously 

document all aspects of anesthesia care provided to a single patient. While similar to that of an 

intensive care unit nurse caring for a high-acuity patient, intraoperative anesthesia record keeping 

is more intensive and time-critical. 

ACPs work as part of a team that includes an interventionalist physician (especially surgeons), 

several perioperative nurses, and other healthcare professionals. Most CRNAs and all anesthesia 

assistants are directed or supervised by anesthesiologists. 

• Anesthesiologists are physicians with the training and expertise to provide perioperative 

patient care including anesthesiology, critical care, acute and chronic pain management, 

and resuscitation. 

• There are more than 40,000 anesthesiologists in the US, representing just over 5% of all 

physicians. However, after excluding primary care and generalist physicians (internists 

and pediatricians), anesthesiology is one of the most common specialties. 

7.7.2 Demographics (USA)82

• Age: Almost 46% of anesthesiologists are over 55 years old (as of December 2008)

• Sex: Approximately 79% of anesthesiologists are male (as of December 2008)83 although 

the percentage of women entering surgery is increasing dramatically (38% of surgical 

residents were female in 2009). In fact, the gender misdistribution of ACPs is much 

greater if one excludes obstetricians/gynecologists where 46% are female (and a 

 82 Average age data are not available for ACPs. 83 http://www.acshpri.org/documents/ACSHPRI_Surgical_Workforce_in_US_apr2010.pdf
Technical Basis for User Interface Design of Health IT

159

preponderance of new Ob/Gyn residents are female). Only about 5-6% of all urologists, 

thoracic ACPs, and orthopedic ACPs are female.

7.7.3 Education

Anesthesiologists must complete four years of undergraduate school, four years of medical 

school, a one-year internship and 3 years of anesthesiology residency. An additional 1-2 year 

fellowship is needed to specialize in cardiothoracic, pediatric, neurological, or obstetric 

anesthesiology, critical care, or pain management. Like other physicians, anesthesiologists must 

complete continuing medical education (CME) throughout their career to maintain their medical 

license and board certification. CME requirements vary by state (to maintain licensure) and 

professional organizations (for maintenance of certification) but share the goal of ensuring 

physicians’ knowledge and skills remain abreast of modern technological advances and medical 

discoveries. Maintenance of certification in anesthesiology requires additional training (e.g., 

realistic patient simulation of critical evens) and written examinations. 

CRNAs must first be a licensed RN (see User Profile #4) with critical care certification, at least 

one (but typically two) years of experience in critical care, successfully complete 3 years of nurse 

anesthesia training (leading to a MS or DNP degree), and pass a certification examination.

7.7.4 Electronic Health Record (EHR) Use environment(s)

ACPs work in a wide variety of procedural environments, from large academic medical centers to 

military surgery centers. ACPs typically work with patients on a short-term basis, due to the 

episodic nature of most procedures. ACPs work in office-based practices, stand-alone surgical 

centers, hospitals, academic medical centers, or within fully integrated healthcare organizations, 

such as the Veterans Health Administration. In larger group settings, ACPs benefit by being

better able to communicate and coordinate patient care with other healthcare providers.84

Once a patient is scheduled for a procedure that requires anesthesia, an anesthesiologist (or 

sometimes an unsupervised CRNA in rural locales) reviews the patient’s relevant information to 

ascertain the risks of receiving anesthesia, to optimize the patient prior to their procedure, and to 

develop a plan of care. The anesthesiologist may order additional diagnostic tests, request 

consultation with specialists (e.g., cardiologist, pulmonologist), and prescribe treatments prior to 

the procedure. During the anesthetic, the ACP documents in real-time each anesthesia treatment 

and patient response, and also documents (or confirms if automatically captured from the 

physiologic monitor) the patients’ vital signs. Post-operative management has similar EHR 

requirements as those of surgeons or intensivists.

 84 Adapted from text found at https://www.facs.org/education/resources/medical-students/lifestyle
Technical Basis for User Interface Design of Health IT

160

 

ACPs interacting with EHRs.85

7.7.5 Experience using computers

ACPs routinely use cutting-edge technology on a daily basis as part of their profession, including 

complex anesthesia workstations, multi-parameter computer-based vital signs monitors, infusion 

pumps, and ultrasound machines. Thus, with the exception of a small proportion of older

practitioners, ACPs are probably more comfortable using computers and technology than any 

other medical professional.

7.7.6 Sample EHR tasks

• Enter, edit, and view key patient information (e.g., vital signs), diagnostic test results, and 

prompts or reminders (e.g., compliance with evidence-based guidelines)

• Review a patient’s medications, problem list, and prior anesthesia and procedure notes

• Review diverse clinical materials to obtain a picture of the patient’s current status, to 

make diagnoses, and to initiate or modify a care plan

• Create a pre- or post-operative note about a patient.

 85 Photo sources: http://ovydizekowan.site40.net/graduate-degrees-in-nursing-informatics.php, 

https://www.quinnipiac.edu/academics/colleges-schools-and-departments/school-ofmedicine/academics/anesthesiologist-assistant-program/, http://www.asahq.org/resources/publications/newsletterarticles/2015/may-2015/electronic-health-records
Technical Basis for User Interface Design of Health IT

161

• Initiate patient referrals to other clinicians (e.g., consultation with a specialist or 

assessment/intervention by another healthcare providers such as a dietician or speech 

therapist)

• Prescribe and transmit prescriptions electronically (inpatient or outpatient)

• Enter, modify or discontinue medication orders (inpatient or outpatient)

• Enter orders for laboratory or diagnostic tests, and procedures (inpatient or outpatient)

• Communicate with colleagues about patient status or care plan issues.

• View patient data and other information in a chronological order to assess care trajectory

• Access and print patient educational materials

• Communicate securely with patients electronically regarding inquiries

7.7.7 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, could be expected to influence physicians’ interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading ACPs to seek shortcuts and workarounds to complete required tasks 

in the time available

• Production Pressures. Most ACPs face significant production pressure in their daily 

work. For example, they feel that they have insufficient time to see patients

preoperatively or to complete documentation at the end of a procedure before moving on 

to the next patient. These pressures can make the ACP more likely to avoid seeking 

information, to delay entering data into the EHR, or to enter less information than they 

would otherwise. Such behaviors could require ACPs to rely more on memory to correctly 

recall and associate information and observations about a patient

• Working with multiple patients simultaneously. When supervising the care of multiple 

patients by CRNAs or AAs, the anesthesiologist might need to rely more on memory to 

correctly recall and associate information and observations with the correct patient

• Need for clinician input. Confirming details or consulting with other clinicians with 

intensive schedules might delay cases and increase production pressure

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups
Technical Basis for User Interface Design of Health IT

162

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material can make

ACPs rely on memory to recall procedures and instructions

• Interaction effect. Routinely wearing and changing gloves can impair typing or touching 

of the user interface. The need to wear additional personal protective gear (e.g., in 

patients with antibiotic resistant infections, tuberculosis, etc.) can further inhibit 

movement and visibility

• Stress of dealing with difficult patients or situations. Under stressful conditions, 

ACPs might be more likely to take shortcuts, miss relevant cues, or to become frustrated 

when presented with obstacles to achieving their clinical goals while using the EHR

• Fatigue and Sleep Deprivation. ACPs might work extended hours and can be under the 

effects of acute and chronic sleep loss. This can lead to inattention, haste, a lower 

likelihood of detecting information presented in an EHR (thus suggesting a need to make 

critical information more salient), and a higher likelihood of ignoring prompts

7.8 Physician

7.8.1 Occupational description

A physician’s occupational responsibility is based on his/her specialty, the environment in which 

s/he works, and the patients s/he serves. Physicians typically work as part of a team that includes 

additional physicians, nurses, and other healthcare specialists. In some cases, physicians 

oversee the work of advanced practice nurses, physician assistants, registered nurses, licensed 

practical nurses, nursing assistants, and home health aides. 

A physician’s work might focus on one or more of the following specific fields:

• A health condition, such as diabetes

• A body part, such as the skin

• A group of people, such as the elderly 

• A workplace, such as an emergency department in a hospital

Physicians commonly perform the following tasks to diagnose and treat injuries or illness, and to 

maintain patient health and well-being:

• Examine patients for abnormalities

• Review medical histories

• Make clinical assessments and diagnoses
Technical Basis for User Interface Design of Health IT

163

• Order, perform, and interpret diagnostic tests

• Prescribe medications and other therapeutic interventions

• Create and modify care plans

• Communicate with other physicians, other members of the healthcare team

• Communicate with the patient and their family/caregivers about the care plan

• Counsel patients on preventative healthcare, including diet and hygiene

7.8.2 Demographics (USA)

• Age: 50% of physicians are between 40-59 years old86

• Sex: Approximately 70% are male and 29%87 are female88

• Population: As of 2010, there were 850,085 physicians89

7.8.3 Education

A physician must complete four years of undergraduate school, four years of medical school, a

one year clinical internship and between two and seven years of advanced clinical training,

residency and/or fellowship, depending on the physician’s intended specialization. Aspiring 

physicians study a wide breadth of topics, including basic sciences such as anatomy and 

pharmacology, population health, and a broad range of clinical topics from gynecology to medical 

ethics. Throughout medical school, medical students care for patients in both inpatient and 

outpatient settings with progressive responsibility under the supervision of experienced 

physicians. In their last year or two, they might begin to specialize in a particular area of 

medicine. After passing licensure board exams and obtaining licensure from the state medical 

board, physicians are fully licensed to practice in that state. There is no reciprocity between 

states although it is typically not too difficult for a physician in one state to obtain a license in 

another. While a specialist physician does not require an additional license, states and individual 

hospitals might require specialty board certification. This requires additional years of clinical 

training, and then passing certification examination(s). Thus, the typical physician does not start 

independent clinical practice until after age 30.

In the USA, 67% of physicians are allopathic physicians (i.e., medical doctors or M.D.s), 7% are 

osteopathic physicians (doctors of osteopathic medicine or D.O.s), and the remaining 26% are 

international medical school graduates (IMGs) who might have a variety of degrees. To practice 

in the United States, all IMGs, regardless of specialty, must pass a comprehensive examination 

process and complete at least one year of additional clinical training in a US residency program. 

 86 2010 A Census of Actively Licensed Physicians in the United States 87 Note: The Federation of State Medical Boards 2010 physician census gathered data related to the ratio of male to 

female physicians in the USA. The sum of the values (i.e., 70% and 29%) is 99%, which is most likely due to rounding 

errors or non-responses. 88 2010 A Census of Actively Licensed Physicians in the United States 89 2010 A Census of Actively Licensed Physicians in the United States
Technical Basis for User Interface Design of Health IT

164

IMGs with prior specialist training (e.g., cardiac surgeon) must repeat most of the same training in 

the US to be able to practice that specialty.

Although M.D.s and D.O.s are subject to similar educational requirements, D.O.s tend to 

approach patient care more holistically. Approximately 60% of D.O.s are practice in primary care 

specialties (PCPs).

90

All physicians must complete continuing medical education (CME) throughout their career, as well 

as fulfill minimum practice time requirements, to maintain a medical license. CME requirements 

vary by state (to maintain licensure) and professional organizations (for maintenance of board 

certification) but share the goal of ensuring physicians’ knowledge and skills remain abreast of 

modern technological advances and medical discoveries. Maintenance of certification 

requirements might also include additional training and even examinations. 

7.8.4 Electronic Health Record (EHR) Use environment(s)

Physicians work in a variety of environments, including hospitals, clinics, offices, home healthcare 

organizations, nursing care facilities, schools, correctional facilities, and military healthcare 

settings. 

As of 2012, 60% of doctors less than 40 years of age practiced medicine in a group setting with

other healthcare providers, such as in a hospital.91 Other group practice environments include 

specialty practices and clinics. Group settings enable physicians to collaborate with other 

providers and coordinate patient care.92 Increasingly group practices are multidisciplinary and 

might include advanced practice nurses and other healthcare workers. This is important for EHR 

use because there might be even more interchange of diverse personnel providing care to 

individual patients in these integrated group practices. 

Of the nearly 1 billion annual visits to physicians’ offices in 2010, more than 55% were to primary 

care physicians.93 While there has been a strong movement for physicians to specialize, many 

‘specialists’ provide their patients with some primary care services and about one-third of all US 

physicians identify themselves as being primary care physicians.94 Primary care physicians are 

trained in General Internal Medicine (45% of primary care practicing physicians), Family Medicine 

(42%), Pediatrics (24%) or are general practitioners (i.e., no board certification, 6%). Most 

geriatricians and internal medicine/pediatrics practitioners as well as some gynecologists provide 

primary care services for their patients.

While the exact numbers vary depending on the source of the data and the definition of an 

“active” physician, the following table provides a reasonable estimate of the distribution of 

physicians working in various specialties. This table excludes primary care oriented disciplines. 

 90 Adapted from text found at http://www.osteopathic.org/osteopathic-health/about-dos/what-is-a-do/Pages/default.aspx 91 http://www.healthecareers.com/article/most-popular-practice-setting-for-physician-employment/173573 92 Adapted from text found at http://www.bls.gov/ooh/healthcare/physicians-and-surgeons.htm 93 Source: National Ambulatory Medical Care Survey: 2010 Summary Tables, Accessed at:

http://www.cdc.gov/nchs/fastats/physician-visits.htm 94 Data source: Agency for Healthcare Research and Quality, “The Number of Practicing Primary Care Physicians in the 

United States’ Publication #12-P001-2-EF, 2010, 

http://www.ahrq.gov/research/findings/factsheets/primary/pcwork1/index.html
Technical Basis for User Interface Design of Health IT

165

Some medical and surgical specialties that deal with similar patient populations have been 

combined because their practice and information needs relevant to EHR design are similar.

Physicians interacting with EHRs.100

 95 This is 2015 data from a different data source: Special data request on State Licensing Information from Redi-Data Inc. 

March 2015. http://kff.org/other/state-indicator/physicians-by-specialty-area/ 96 Association of American Medical Colleges (AAMC). 2012 Physician Specialty Data Book, Table 1, from AMA physician 

master file. https://www.aamc.org/download/313228/data/2012physicianspecialtydatabook.pdf 97 Other internal medicine specialties include gastroenterology, pulmonary/critical care, nephrology, infectious disease, preventive 

Medicine, endocrinology/diabetes/metabolism, rheumatology, and allergy/immunology. 98 Other surgical specialties include (ordered by number of physicians): urology, otolaryngology and thoracic surgery. 99 All other specialties above include, but are not limited to: Physical medicine & rehabilitation (PMR) and Neonatology/perinatal 

medicine.

100 Photo sources: http://www.wsj.com/articles/ama-urges-overhaul-of-electronic-records-1410840063, 

http://blog.M.D.sofkansas.com/trusting-voice-recognition-and-the-ehr/, 

http://www.mc4.army.mil/story/Battalion_Surgeon_Readies_Unit_with_EMR_Garrison_Use_Exercise_Play

Specialty settings95 # 96 % of 

all 

MDs 

% of 

Specialists 

Other Internal Medicine Specialties97 67,124 9.3 15.1

Psychiatry & Child Psychiatry 45,971 6.4 10.3

Obstetrics/Gynecology 40,345 5.5 9.0

Anesthesiology 40,123 5.5 9.0

Emergency Medicine 33,984 4.7 7.6

Radiology 27,986 3.9 6.3

General Surgery 26,296 3.6 5.9

Other Surgical Specialties98 23,740 3.3 5.3

Cardiology, Cardiac and vascular 

surgery

21,819 3.0 4.9

Orthopedics 19,822 2.7 4.4

Neurology/Neurologic Surgery 17,963 2.5 4.0

Ophthalmology 17,943 2.5

Dermatology & Plastic surgery 17,642 2.4

Hematology/Oncology/Radiation 

oncology

17,202 2.4

Pathology 14,975 2.1

All Other Specialties99 12,904 1.8

TOTALS 445,839 61.6
Technical Basis for User Interface Design of Health IT

166

7.8.5 Experience using computers

In general, while most physicians are quite comfortable with computers and EHRs, some are less 

comfortable and this might be somewhat related to how much the physician used computers 

during his/her education and training (and thus correlated with physician age).

Due to computer use starting in childhood, younger physicians are more likely to have experience 

with and be comfortable participating in computer-based training. Physicians who used 

computers throughout their schooling are generally more inclined to explore unfamiliar functions 

and perform tasks with high efficiency. 

Younger physicians might have a clearer mental model of computer-based data management, 

including uploading and downloading data and using computers to access other data sources. 

Those physicians who did not use computers during schooling are generally less comfortable 

exploring computer functions and in some cases might perform computer-based tasks less 

efficiently than younger physicians.

7.8.6 Representative EHR tasks

• Enter, edit, and view key patient information and reminders (e.g., allergies, problems,

physician notes including assessment and plan)

• Reconcile the patient’s medication list

• Review diverse clinical materials to obtain a picture of the patient’s current status, to 

make diagnoses, and to initiate or modify a care plan (e.g., review pediatric patients’ 

growth charts and prior notes to assess the effects of prior treatment(s))

• Create or update a problem list, allergies, or other patient summary information.

• Initiate patient referrals to other clinicians (e.g., consultation with a specialist or 

assessment/intervention by another healthcare providers such as a dietician or speech 

therapist)

• Prescribe and transmit prescriptions electronically (outpatient or discharge)

• Enter medication orders (inpatient)

• Enter orders for vaccines, laboratory or diagnostic tests, and procedures (inpatient or 

outpatient)

• Modify or discontinue orders

• Receive, view, and acknowledge a patient’s lab results (e.g., cholesterol, liver function 

tests)

• Communicate with colleagues about patient status or care plan issues.
Technical Basis for User Interface Design of Health IT

167

• View patient data and other information in a chronological order to assess care trajectory

• Access and print patient educational materials

• Order or request follow-up appointments

• Communicate securely with patients electronically regarding inquiries

7.8.7 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, are just some of those that can influence physicians’ interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading users to seek shortcuts and workarounds to complete required tasks 

in time available

• Production Pressures. Most physicians face significant production pressure in their 

daily work. For example, insufficient time to see patients or between patients can make

physicians more likely to avoid seeking information, to delay entering data into the EHR 

or to enter less information than they would otherwise. Such behaviors could require 

them to rely more on memory to correctly recall and associate information and 

observations about a patient

• Working with multiple patients simultaneously. This requires physicians to rely more 

on memory to correctly recall and associate information and observations with the correct 

patient

• Need for clinician input. Confirming details or consulting with other clinicians with 

intensive schedules might delay work 

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Developing alarm fatigue. Developing alarm fatigue can lead to ignored or missed 

audible alarms, as well as a disdain for onscreen warnings

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material can make 

physicians rely on memory to recall procedures and instructions

• Interaction effect. Wearing protective equipment such as gloves can inhibit movement, 

visibility, and typing
Technical Basis for User Interface Design of Health IT

168

• Stress of dealing with difficult patients or situations. Under stressful conditions, 

physicians might be more likely to take shortcuts, miss relevant cues, or to become 

frustrated when presented might obstacles to achieving their clinical goals while using the 

EHR

• Fatigue and Sleep Deprivation. Physicians often work long hours and can be working 

under the effects of acute and chronic sleep loss. This can lead to inattention, haste, a 

lower likelihood of detecting information presented in an EHR (thus suggesting a need to 

make critical information more salient), and a higher likelihood of ignoring prompts

7.9 Surgeon

7.9.1 Occupational description

A surgeon’s occupational responsibilities vary based on the surgeon’s clinical setting and field of 

expertise. Surgeons typically work as part of a team that includes other physicians (especially 

anesthesiologists), nurses, and other healthcare professionals. Surgeons often oversee the work 

of fellows, residents, interns, nurse practitioners, physician assistants, registered nurses, licensed 

practical nurses. In a relatively low proportion of practices, they might also oversee the work of 

nursing assistants, and home health aides.101

Surgeons are physicians with the training and expertise to perform surgical procedures (i.e., 

operations) as well as preoperative diagnosis and postoperative patient care. Surgeons might 

focus on general surgery or specialize. General surgery traditionally includes colorectal surgery 

and trauma/burn surgery even though those areas are now subspecialties. 

Obstetrics/Gynecology (Ob/Gyn) is both a surgical and a non-surgical specialty but is included 

here for completeness. When including Ob/Gyn, surgeons represent just less than 20% of all 

physicians. While the exact numbers vary depending on the source of the data and the definition 

of an “active” physician, the following table provides a rough estimate of the distribution of 

surgeons working in various specialties. 

Surgical specialties102 # % of all 

Surgeons

Obstetrics/Gynecology 40,826 28

General surgery 25,187 17

Orthopedic surgery 19,374 13

Ophthalmology 18,317 13

Urology 9,771 7

Otolaryngology 9,320 6

Plastic surgery 6,942 5

Neurologic Surgery 5,171 4

Thoracic surgery 4,521 3

Vascular surgery 3,130 2

Pediatric surgery (estimate)103 2,700 2

 101 Anesthesiology practice is quite distinct from surgery and thus is explicitly excluded from this user profile. 102 Association of American Medical Colleges (AAMC). 2014 Physician Specialty Data Book, Table 1, from AMA physician 

master file. https://members.aamc.org/eweb/upload/Physician%20Specialty%20Databook%202014.pdf

103 http://www.acshpri.org/documents/ACSHPRI_Surgical_Workforce_in_US_apr2010.pdf
Technical Basis for User Interface Design of Health IT

169

TOTALS 145,259 100.0

7.9.2 Demographics (USA)104

• Age: Almost 46% of surgeons are over 55 years old (as of December 2008)

• Sex: Approximately 79% of surgeons are male (as of December 2008)

105 although the 

percentage of women entering surgery is increasing dramatically (38% of surgical 

residents were female in 2009). In fact, the gender misdistribution of surgeons is much 

greater if one excludes obstetricians/gynecologists where 46% are female (and a 

preponderance of new Ob/Gyn residents are female). Only about 5-6% of all urologists, 

thoracic surgeons, and orthopedic surgeons are female.

7.9.3 Education

Surgeons must complete four years of undergraduate school, four years of medical school, a 

one-year internship and between 2 and 9 years of residency and/or fellowship, depending on their 

specialty. Like other physicians (see that User Profile #8 for more information), aspiring surgeons 

study a broad range of topics, but with greater emphasis on anatomy and pathology after medical 

school. Surgeons can practice independently after earning their medical degree, passing their 

licensure exams, completing residency and fellowship training, and meeting the requirements for 

specialty (and subspecialty as appropriate) board certification. 

Like other physicians, surgeons must complete continuing medical education (CME) throughout 

their career, as well as fulfill minimum practice time requirements, to maintain their medical 

license and board certification. CME requirements vary by state (to maintain licensure) and 

professional organizations (for maintenance of certification) but share the goal of ensuring 

surgeons’ knowledge and skills remain abreast of modern technological advances and medical 

discoveries. Maintenance of certification requirements might also include additional training and 

even examinations. 

7.9.4 Practice Attributes

Surgical care includes preoperative assessment (to determine the need for and then to schedule 

surgery), preoperative preparation, intraoperative surgical care, immediate post-operative 

management, and longer-term follow up. Surgeons obtain referrals from other physicians (e.g., 

internists, primary care physicians) and also obtain consultations from various specialists 

(anesthesiologists, pain physicians, internal medicine specialists such as cardiologists). 

7.9.5 Electronic Health Record (EHR) Use environment(s)

Surgeons work in a wide variety of environments, from large academic medical centers to military 

surgery centers. Surgeons typically work with patients on a short-term basis, due to the episodic 

nature of most surgeries. Surgeons work in office-based practices, stand-alone surgical centers, 

hospitals, academic medical centers, or within fully integrated healthcare organizations such as 

 104 Average age data are not available for surgeons. 105 http://www.acshpri.org/documents/ACSHPRI_Surgical_Workforce_in_US_apr2010.pdf
Technical Basis for User Interface Design of Health IT

170

the Veterans Administration or Kaiser Permanente. In larger group settings, surgeons benefit by

being better able to communicate and coordinate patient care with other healthcare providers.106

Often, healthcare professionals refer the patient and send the patient’s relevant information to the 

surgeon. Surgeons have somewhat more specialized interactions with EHR systems than do 

other physicians such as internists. Because many surgeons dictate their notes, especially their 

operative summaries, their EHR expectations might be different from other healthcare 

professionals (e.g., more surgeons might use voice recognition products to enter notes into an 

EHR).

Surgeons interacting with EHRs.107

7.9.6 Experience using computers

Many surgeons use cutting-edge and emerging technology as part of their profession, including 

surgical robots. That said, surgeons are somewhat bimodal in their use of computers and EHRs –

older surgeons who did not use computers during their education might be more reluctant to use 

and less comfortable using EHRs.

Younger surgeons are more likely to have experience with and be comfortable participating in 

computer-based training. Surgeons who used computers throughout their schooling are generally 

more inclined to explore unfamiliar functions and perform tasks with high efficiency. These

 106 Adapted from text found at https://www.facs.org/education/resources/medical-students/lifestyle 107 Photo sources: http://www.fdbhealth.com/blog/2013/december/will-meaningful-use-of-ehrs-prove-beneficial/, 

http://www.informationweek.com/healthcare/electronic-health-records/surgeon-cuts-vendors-out-of-ehr-quest/d/did/1252732, http://www.jimenezconsulting.com/solutions/ehr/default.aspx
Technical Basis for User Interface Design of Health IT

171

younger surgeons might also have a clearer mental model of computer-based data management, 

including uploading and downloading data and using computers to access other data sources.

7.9.7 Representative EHR tasks

• Enter, edit, and view key patient information and reminders (e.g., allergies, problems,

physician notes including assessment and plan)

• Reconcile the patient’s medication list

• Review diverse clinical materials to obtain a picture of the patient’s current status, to 

make diagnoses, and to initiate or modify a care plan (e.g., review pediatric patients’ 

growth charts and prior notes to assess the effects of prior treatment)

• Dictate or write operative notes

• Create or update a problem list, allergies, or other patient summary information.

• Initiate patient referrals to other clinicians (e.g., consultation with a specialist or 

assessment/intervention by another healthcare providers such as a dietician or speech 

therapist)

• Prescribe and transmit prescriptions electronically (outpatient or discharge)

• Enter medication orders (inpatient)

• Enter orders for vaccines, laboratory or diagnostic tests, and procedures (inpatient or 

outpatient)

• Modify or discontinue orders

• Receive, view, and acknowledge a patient’s lab results (e.g., cholesterol, liver function 

tests)

• Communicate with colleagues about patient status or care plan issues.

• View patient data and other information in a chronological order to assess care trajectory

• Access and print patient educational materials

• Order or request follow-up appointments

• Communicate securely with patients electronically regarding inquiries

7.9.8 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, are just some of those that can influence surgeon’s interactions with EHRs:
Technical Basis for User Interface Design of Health IT

172

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading surgeons to seek shortcuts and workarounds to complete required 

tasks in time available

• Production Pressures. Most surgeons face significant production pressure in their daily 

work. For example, insufficient to see patients or between patients can make surgeons

more likely to avoid seeking information, to delay entering data into the EHR or to enter 

less information than they would otherwise. Such behaviors could require them to rely 

more on memory to correctly recall and associate information and observations about a 

patient

• Working with multiple patients simultaneously. This requires surgeons to rely more 

on memory to correctly recall and associate information and observations with the correct 

patient

• Need for clinician input. Confirming details or consulting with other clinicians with 

intensive schedules might delay work 

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material can make

surgeons rely on memory to recall procedures and instructions

• Interaction effect. Wearing protective equipment such as gloves can inhibit movement, 

visibility, and typing

• Stress of dealing with difficult patients or situations. Under stressful conditions, 

surgeons might be more likely to take shortcuts, miss relevant cues, or to become 

frustrated when presented with obstacles to achieving their clinical goals while using the 

EHR

• Fatigue and Sleep Deprivation. Surgeons work long hours and often work under the 

effects of acute and chronic sleep loss. This can lead to inattention, haste, a lower 

likelihood of detecting information presented in an EHR (thus suggesting a need to make 

critical information more salient), and a higher likelihood of ignoring prompts
Technical Basis for User Interface Design of Health IT

173

7.10 Pharmacist

7.10.1 Occupational description

Pharmacists distribute prescription medications and advise patients on how to safely and 

effectively use prescription medications in both the inpatient and outpatient settings. Inpatient 

pharmacists are part of a healthcare team where they are responsible for medication 

management including supply chain management. Pharmacists interact with electronic health 

records (EHRs) in pharmacies and other clinical settings. They might also administer 

immunizations, help patients manage chronic conditions, and review medication lists. 

Pharmacists often oversee the work of pharmacy technicians and provide consultation to 

physicians, nurses, APRNs, PAs, and other healthcare professionals.

7.10.2 Demographics (USA)

• Age: Average in the USA is 43 years (as of 2014)108

• Sex: Approximately 56% are female, 44% are male (as of 2013)

109

• Population: As of 2013, there were 287,420 pharmacists110

7.10.3 Education

Becoming a pharmacist requires a Pharm.D. degree, typically earned upon the completion of four 

years of undergraduate school and four years of pharmacy school. Important areas of instruction

during pharmacy school include: pharmaceutical chemistry, pharmacognosy, pharmacology, 

business management, pharmacy practice, as well as a clinical component.111 Because of the 

heavy use of computer-based procedures and documentation in modern pharmacy practice, 

pharmacists receive more informatics training than most other healthcare professionals.

Upon completion of pharmacy school, increasingly are expected to do one-year of additional 

clinical training (like a medical internship). Graduates can further pursue additional training with 

either a research focus (i.e., fellowship programs) or a clinical focus (i.e., residency programs).112

All pharmacists must complete continuing pharmacy education (CPE) throughout their career to 

maintain a pharmacist license. CPE requirements vary by state and board but share the goal of 

ensuring pharmacists’ knowledge and skills remain abreast of modern advances and medical 

discoveries.

7.10.4 Electronic Health Record (EHR) Use environment(s)

Pharmacists work in variety of environments, including retail pharmacies, hospitals, clinics, mailorder pharmacies, wholesalers, and home health agencies.113 The following table provides the 

distribution of pharmacists working in various settings. 

 108 http://dpeaflcio.org/programs-publications/issue-fact-sheets/pharmacists-and-pharmacy-technicians-facts-and-figures/ 109 http://dpeaflcio.org/programs-publications/issue-fact-sheets/pharmacists-and-pharmacy-technicians-facts-and-figures/ 110 http://dpeaflcio.org/programs-publications/issue-fact-sheets/pharmacists-and-pharmacy-technicians-facts-and-figures/ 111 http://www.aacp.org/resources/student/pharmacyforyou/documents/pharmd.pdf 112 Adapted from text found at http://www.accp.com/stunet/compass/residency.aspx
Technical Basis for User Interface Design of Health IT

174

Pharmacist settings114 %

Pharmacies and drug stores 43

Hospitals; state, local, and private 23

Grocery stores 8

Department stores 5

Other general merchandise stores 5

Clinical pharmacists can work in outpatient or inpatient settings. When in the outpatient setting 

they might work directly with patients but in either setting they typically oversee pharmacy 

technicians, and work closely with physicians and other health professionals to coordinate patient 

care. In these collaborative settings, pharmacists’ primary goal is to ensure that the medications 

prescribed for patients contribute to the best possible outcomes.115 Pharmacists may also advise 

insurance providers or healthcare facilities, or work in the pharmaceutical industry to develop 

drugs.116

Clinical pharmacists are responsible for managing their facility’s drug formulary (i.e., what 

medications will be available), ordering bulk medications for the facility, storing and organizing 

those medications, preparing, dispensing, and delivering the medications to the patient, assuring 

that dispensed medications are correctly labeled, assuring that every patient receives the correct 

medication, and generating accurate timely documentation of all of the above activities. Thus, 

clinical pharmacists, through additional training and extensive exposure to EHRs, are generally 

more familiar with computer use in their practice than are most physicians. Even older community 

pharmacists who were not exposed to computers during their training, have invariably now been 

forced to use EHRs in their practice for many years and become comfortable with their use. 

Pharmacists interacting with EHRs.

117

7.10.5 Sample EHR tasks

• Review key patient information to determine whether the prescribed medications are 

meeting the patient’s need and goals of care

 113 http://dpeaflcio.org/programs-publications/issue-fact-sheets/pharmacists-and-pharmacy-technicians-facts-and-figures/ 114 Data source: http://www.bls.gov/ooh/healthcare/pharmacists.htm#tab-3 115 Adapted from text found at http://www.bls.gov/ooh/healthcare/physicians-and-surgeons.htm 116 Adapted from text found at http://www.bls.gov/ooh/healthcare/pharmacists.htm#tab-2 117 Photo sources: http://www.ashpintersections.org/2015/01/new-ehr-improves-outcomes-at-the-university-of-kansashospital/, http://clinicalsolutionspharmacy.com/services/ehr_emr, http://healthit.gov/providers-professionals/pharmacyreview-and-process-q7
Technical Basis for User Interface Design of Health IT

175

• View patient data chronologically as flowchart showing progress over time

• Advise patients regarding prescribed medications and any potential side effects118

• Review patient prescriptions for potential drug interactions 

• Receive and verify prescriptions electronically before filling

• Access and print patient educational materials

• Add new patient information into the system

• Enter patient medical history or patient assessments 

• Review patient medication list

• View patient lab and test results (e.g., cholesterol, liver function tests, x-ray)

• View patient history and physician’s notes

• Review pediatric patients’ growth charts 

• Access and print educational materials for patients

• Send notes to patients or other healthcare professionals 

• Document care, such as administering a vaccine or providing patient education

• Communicate with patients via secure email

• Document patient communication (e.g., a patient phone call)

• Barcode scan medications and document administration

• Review nurses administration of medications

• Review physicians’ orders on single and multiple patients

• Review pharmacy technicians’ dispensing records and work

• Review, edit, document drug formularies 

• Review and approve non-formulary drug requests

• Order medications (in bulk) from pharmaceutical manufacturers

• Retrieve, review, edit, and disseminate materials about medication safety and use

 118 Adapted from text found at http://www.uwhealth.org/quality-reports/the-pharmacists-role-on-the-patient-careteam/12224
Technical Basis for User Interface Design of Health IT

176

• Support the care team’s efforts to educate patients on preventative health measures 

(e.g., vaccination)

• Recognize untreated health issues that could be corrected with medication therapy119

7.10.6 Performance-shaping factors

The following factors, related to occupational responsibility, training, and familiarity with 

computers, could be expected to influence pharmacists’ interactions with EHRs:

• Fast-paced environments. Working in fast-paced work environments can create stress 

and fatigue, leading pharmacists to seek shortcuts and workarounds to complete required 

tasks in time available

• Production Pressures. Many pharmacists face significant production pressure in their 

daily work. For example, insufficient time to prepare and label medications can make

pharmacists more likely to avoid seeking information, to delay entering data into the EHR 

or to enter less information than they would otherwise. Such behaviors could require 

them to rely more on memory to correctly recall and associate information and 

observations about a patient

• Working with multiple prescriptions simultaneously. This requires pharmacists to rely 

more on memory to correctly recall and associate information and observations with the 

correct patient

• Need for clinician input. Confirming details or consulting with physicians who are 

difficult to reach can delay work, increase production pressure, and contribute to 

interruptions.

• Alternating communication modes. Switching frequently between phone-based, paperbased, EHR-based, email, and in-person tasks and communication modes

• Excessive alerts and pop-ups. Encountering an extensive number of safety alerts and 

pop-ups might drive users to seek workarounds and ignore pop-ups

• Developing alarm fatigue. Developing alarm fatigue can lead to ignored or missed 

audible alarms, as well as a disdain for onscreen warnings

• Changing documentation modes. Shifting from documenting in paper charts to using a 

software-based solution might challenge familiar methods of documentation

• Lacking reference material. Lacking readily available reference material can make

physicians rely on memory to recall procedures and instructions

• Interaction effect. Wearing protective equipment such as gloves can inhibit movement, 

visibility, and typing

 119 Adapted from https://www.accp.com/about/clinicalpharmacists.aspx
Technical Basis for User Interface Design of Health IT

177

• Stress of dealing with difficult patients or situations. Under stressful conditions, 

pharmacists might be more likely to take shortcuts, miss relevant cues, or to become 

frustrated when presented with obstacles to achieving their clinical goals while using the 

EHR

• Fatigue and Sleep Deprivation. Pharmacists often work long hours and can be working 

under the effects of acute and chronic sleep loss. This can lead to inattention, haste, a 

lower likelihood of detecting information presented in an EHR (thus suggesting a need to 

make critical information more salient), and a higher likelihood of ignoring prompts
Technical Basis for User Interface Design of Health IT

178

8 References

Altuwaijri, M. M. (2011, October). Achieving excellence in electronic health record deployment in 

Middle East hospitals. In Biomedical Engineering and Informatics (BMEI), 2011 4th International 

Conference (Vol. 4, pp. 1919-1923). IEEE.

Armijo, D., McDonnell, C., & Werner, K. (2009). Electronic health record usability: evaluation and 

use case framework. AHRQ Publication, 9 (10).

Association for the Advancement of Medical Instrumentation. (2009). ANSI/AAMI HE75: 2009: 

Human factors engineering: Design of medical devices. Arlington, VA: Author.

Belden, J. L., Grayson, R., & Barnes, J. (2009). Defining and testing EMR usability: Principles 

and proposed methods of EMR usability evaluation and rating. Healthcare Information and 

Management Systems Society (HIMSS).

Bevan, N. (2005, July). Guidelines and standards for web usability. In Proceedings of HCI 

International (Vol. 2005).

CFR (2012). Health information technology: Standards, implementation specifications, and 

certification criteria for Electronic Health Record technology, 2014 Edition. Code of Federal 

Regulations, 77(171).

Chen, Y., & Lee, J. K. (2012, August). Analysis and evaluation about the barriers of the adoption 

and implementation of electronic health record system: A comparison study between China and 

Korea. In Information Technology in Medicine and Education (ITME), 2012 International 

Symposium on (Vol. 2, pp. 828-832). IEEE.

Christensen, C. (2012). A dashboard for OR patient safety optimization. Interview by Mark 

Hagland. Healthcare informatics: the business magazine for information and communication 

systems, 29(8), 29-31.

Connell, I. W. Full Principles Set. Set of 30 usability evaluation principles compiled by the author 

from the HCI literature, 2000.

Craig, D. (2011, May). An EHR interface for viewing and accessing patient health events from 

collaborative sources. In Collaboration Technologies and Systems (CTS), 2011 International 

Conference on (pp. 319-324). IEEE.

Davison, H. Cognitive task analysis: Current research [PowerPoint slides]. Retrieved from: 

http://web.mit.edu/16.459/www/CTA2.pdf. 

DIS, I. (2009). 9241-210: 2010. Ergonomics of human system interaction-Part 210: Humancentered design for interactive systems. International Standardization Organization (ISO). 

Switzerland.
Technical Basis for User Interface Design of Health IT

179

Dringus, L.P. and Cohen, M.S. (2005). An adaptable usability heuristic checklist for online 

courses. 35th ASEE/IEEE Frontiers in Education Conference.

Feblowitz, J. C., Wright, A., Singh, H., Samal, L., & Sittig, D. F. (2011). Summarization of clinical 

information: A conceptual model. Journal of biomedical informatics, 44(4), 688-699.

Ferreira, A., Correia,R., and Antunes, M.B.L. (2012). Usable access control policy and model for 

healthcare. 24th International Symposium on Computer-Based Medical Systems (CBMS).

Force, H. U. T. (2011). Promoting Usability in Health Organizations: initial steps and progress 

toward a healthcare usability maturity model. Health Information and Management Systems 

Society.

Ginsburg, M. (2012). Considering the visual element in clinical pediatric data management. 45th 

Hawaii International Conference on System Services.

Gocsik, T. (2012). Last man standing? Advice for engaging anesthesia clinicians when 

implementing an EMR in anesthesiology services. Healthcare informatics: the business magazine 

for information and communication systems, 29(10), 32-37.

Hagland, M. (2012). Physician documentation: Balancing clinical and administrative uses. 

Healthcare Informatics, 29(10), 30. 

Horsky, J., Schiff, G. D., Johnston, D., Mercincavage, L., Bell, D., & Middleton, B. (2012). 

Interface design principles for usable decision support: a targeted review of best practices for 

clinical prescribing interventions. Journal of biomedical informatics, 45(6), 1202-1216.

Ilie, V., Turel, O., & Witman, P. D. (2013, January). Towards a New Design Paradigm for 

Complex Electronic Medical Record Systems: Intuitive User Interfaces. In System Sciences 

(HICSS), 2013 46th Hawaii International Conference (pp. 2585-2594). IEEE.

Kannampallil, T.G., Franklin, A., Mishra, R., Almosa, K.F., Cohen, T., and Patel, V.L. (2013). 

Understanding the nature of information seeking behavior in critical care: Implications for the 

design of health information technology. Artificial Intelligence in Medicine, 57(2013), 21-29.

Kannoju, P. K., Sridhar, K. Y., & Prasad, P. S. (2010, November). A new paradigm of Electronic 

Health record for efficient implementation of healthcare delivery. In Biomedical Engineering and 

Sciences (IECBES), 2010 IEEE EMBS Conference (pp. 352-354). IEEE.

Katehakis, D. G., Sfakianakis, S. G., Kavlentakis, G., Anthoulakis, D. N., & Tsiknakis, M. (2007). 

Delivering a lifelong integrated electronic health record based on a service oriented architecture. 

Information Technology in Biomedicine: IEEE Transactions, 11(6), 639-650.

Kaye, R., & Crowley, J. (2000). Medical device use-safety: incorporating human factors 

engineering into risk management. Food and Drug Administration.
Technical Basis for User Interface Design of Health IT

180

Kimura, E., Kobayashi, S., Yoshikawa, T., and Ishihara, K. (2011). A framework for an 

authorization system with spatial reasoning capacity to improve risk management and information 

security in healthcare. IEEE/IPSJ International Symposium on Applications and the Internet.

Kobus, A. M., Harman, J. S., Do, H. D., & Garvin, R. D. (2013). Challenges to depression care 

documentation in an EHR. Fam Med, 45(4), 268-71.

Koppel, R., Metlay, J. P., Cohen, A., Abaluck, B., Localio, A. R., Kimmel, S. E., & Strom, B. L. 

(2005). Role of computerized physician order entry systems in facilitating medication errors. 

Jama, 293(10), 1197-1203.

Kume, N., Hirayama, Y., Ohboshi, N., Okamoto, K., Takemura, T., Araki, K., and Yoshihara 

(2012). The mobile environment of EHR browsing verified on tablet terminal. SCIS-ISIS.

Kuqi, K., Eveleigh, T., Holzer, T., & Sarkani, S. (2012, March). Using design structure matrix for 

improving electronic medical record usability. In Systems Conference (SysCon), 2012 IEEE 

International (pp. 1-6). IEEE.

Kwak, Y. S. (2005, June). International standards for building electronic health record (ehr). In 

Enterprise networking and Computing in Healthcare Industry, 2005. HEALTHCOM 2005. In 

Proceedings of 7th International Workshop (pp. 18-23). IEEE.

Linder, J. A., Schnipper, J. L., Tsurikova, R., Melnikas, A. J., Volk, L. A., & Middleton, B. (2006). 

Barriers to electronic health record use during patient visits. In AMIA Annual Symposium 

Proceedings (Vol. 2006, p. 499). American Medical Informatics Association.

Loranger, H., Schade, A., and Nielsen, J. (2002). Website Tools and Applications with Flash.

Retrieved from: http://www.nngroup.com/reports/website-tools-and-applications-flash/

Militello, L. G., & Hutton, R. J. (1998). Applied Cognitive Task Analysis (ACTA): A practitioner's 

toolkit for understanding cognitive task demands. Ergonomics, 41(11), 1618-1641.

Mosier, J. N., & Smith, S. L. (1986). Application of guidelines for designing user interface 

software. Behaviour & information technology, 5(1), 39-46.

Nielsen, J. (2005). Ten usability heuristics.

NISTIR 7804 (2012). Technical evaluation, testing and validation of the usability of Electronic 

Health Records. National Institute of Standards and Technology.

NISTIR 7865 (2012). A human factors guide to enhance EHR usability of critical user interactions 

when supporting pediatric patient care. National Institute of Standards and Technology.

NISTIR 7952 (2013). Toward a shared approach for ensuring patient safety with enhanced 

workflow design for Electronic Health Records: Workshop summary. National Institute of 

Standards and Technology.
Technical Basis for User Interface Design of Health IT

181

Patel, V. L., Zhang, J., Yoskowitz, N. A., Green, R., & Sayan, O. R. (2008). Translational 

cognition for decision support in critical care environments: a review. Journal of biomedical 

informatics, 41(3), 413-431.

Perna, G. (2012). Mobility in nursing: An ongoing evolution. Why providers are investing 

strategically in nurse-friendly mobile solutions. Healthcare informatics: the business magazine for 

information and communication systems, 29(7), 16.

Prestigiacomo, J. (2011). Integrating telehealth and the EHR. Organizations make progress 

remotely linking physicians and patients, but documenting the remote consult will require much 

integration work. Healthcare informatics: the business magazine for information and 

communication systems, 29(6), 60-62.

Ratwani, R. M., Fairbanks, R. J., Hettinger, A. Z., & Benda, N. C. (2015). Electronic health record 

usability: Analysis of the user-centered design processes of eleven electronic health record 

vendors. Journal of the American Medical Informatics Association, ocv050.

Ribitzky, R., Sterling, M., and Bradley, V. (2009). EHR usability pain points survey Q4-2009. 

HIMSS10: Annual Conference and Exhibition.

Rogoski, R. R. (2012). Bridging the EHR divide. Hospitals, physician practices work toward true 

interoperability. Healthcare informatics: the business magazine for information and 

communication systems, 29(10), 8-10.

Schiff, G. D., & Bates, D. W. (2010). Can electronic clinical documentation help prevent 

diagnostic errors?. New England Journal of Medicine, 362(12), 1066-1069.

Schumacher, R. M., & Lowry, S. Z. (2010). NIST guide to the processes approach for improving 

the usability of electronic health records. National Institute of Standards and Technology.

Schumacher, R. M., & Lowry, S. Z. (2011). NISTIR 7742. Customized Common Industry Format 

Template for Electronic Health Record Usability Testing.

Shneiderman, B., & Plaisant, C. (2005). Designing the user interface: strategies for effective. 

Human-Computer Interaction.

Sinha, P. K., Sunder, G., Bendale, P., Mantri, M., & Dande, A. (2012). Electronic health record: 

standards, coding systems, frameworks, and infrastructures. John Wiley & Sons.

Smith, S. L., & Mosier, J. N. (1986). Guidelines for designing user interface software. Bedford, 

MA: Mitre Corporation.

Staggers, N. (2009). A systematic review on the designs of clinical technology: Findings and 

recommendations for future research. ANS. Advances in nursing science, 32(3), 252.

System Usability Scale (SUS). Retrieved from: http://www.usability.gov/how-to-andtools/methods/system-usability-scale.html
Technical Basis for User Interface Design of Health IT

182

Tancer, J., & Varde, A. S. (2012, September). Cloud technology and EHR data management. In 

Information and Automation for Sustainability (ICIAfS), 2012 IEEE 6th International Conference 

on (pp. 112-117). IEEE.

Tarkan, S. (2013). Design Guidelines. Retrieved 

from: http://www.cs.umd.edu/hcil/sharp/resultsmanagement/mstart/guidelines.pdf. 

Tarkan, S., Franklin, L., Plaisant, C., & Shneiderman, B. (2012). Design Guidelines for Ensuring 

Timely Management of Medical Orders. HCIL, UMD, Tech. Rep, 25.

Tractinsky, N., Katz, A. S., & Ikar, D. (2000). What is beautiful is usable. Interacting with 

computers, 13(2), 127-145.

Wang, T. D., Wongsuphasawat, K., Plaisant, C., & Shneiderman, B. (2010, November). Visual 

information seeking in multiple electronic health records: design recommendations and a process 

model. In Proceedings of the 1st ACM International Health Informatics Symposium (pp. 46-55). 

ACM.

Zhang, J., & Walji, M. F. (2011). TURF: Toward a unified framework of EHR usability. Journal of 

biomedical informatics, 44(6), 1056-1067.

Zhang, J., Johnson, T. R., Patel, V. L., Paige, D. L., & Kubose, T. (2003). Using usability 

heuristics to evaluate patient safety of medical devices. Journal of biomedical informatics, 36(1), 

23-30.