Improving Clinical Workflow in Ambulatory Care: Implemented Recommendations in an Innovation Prototype for the Veteran's Health Administration.

INTRODUCTION: Human factors workflow analyses in healthcare settings prior to technology implemented are recommended to improve workflow in ambulatory care settings. In this paper we describe how insights from a workflow analysis conducted by NIST were implemented in a software prototype developed for a Veteran's Health Administration (VHA) VAi2 innovation project and associated lessons learned.
METHODS: We organize the original recommendations and associated stages and steps visualized in process maps from NIST and the VA's lessons learned from implementing the recommendations in the VAi2 prototype according to four stages: 1) before the patient visit, 2) during the visit, 3) discharge, and 4) visit documentation. NIST recommendations to improve workflow in ambulatory care (outpatient) settings and process map representations were based on reflective statements collected during one-hour discussions with three physicians. The development of the VAi2 prototype was conducted initially independently from the NIST recommendations, but at a midpoint in the process development, all of the implementation elements were compared with the NIST recommendations and lessons learned were documented.
FINDINGS: Story-based displays and templates with default preliminary order sets were used to support scheduling, time-critical notifications, drafting medication orders, and supporting a diagnosis-based workflow. These templates enabled customization to the level of diagnostic uncertainty. Functionality was designed to support cooperative work across interdisciplinary team members, including shared documentation sessions with tracking of text modifications, medication lists, and patient education features. Displays were customized to the role and included access for consultants and site-defined educator teams. DISCUSSION: Workflow, usability, and patient safety can be enhanced through clinician-centered design of electronic health records. The lessons learned from implementing NIST recommendations to improve workflow in ambulatory care using an EHR provide a first step in moving from a billing-centered perspective on how to maintain accurate, comprehensive, and up-to-date information about a group of patients to a clinician-centered perspective. These recommendations point the way towards a "patient visit management system," which incorporates broader notions of supporting workload management, supporting flexible flow of patients and tasks, enabling accountable distributed work across members of the clinical team, and supporting dynamic tracking of steps in tasks that have longer time distributions.

Introduction

The Agency for Healthcare Research and Quality (AHRQ) report titled “Incorporating Health Information Technology into Workflow Redesign”1 recommended conducting human-factors workflow analyses in health care settings prior to technology implementation. In addition, the National Institute of Standards and Technology (NIST) presented targeted recommendations from human-factors workflow methods that could be used in ambulatory (outpatient) care settings that include physician users with diverse responsibilities.2,3 In this paper we describe a subset of these recommendations, the related steps in a process map representation of the typical workflow for a returning patient in an outpatient clinic, and the lessons learned based on implementing these recommendations in a prototype. The software prototype was developed for a Veteran’s Health Administration (VHA) VA Innovation Initiative (VAi2) project.4 This prototype interfaces with the VHA’s electronic health record (EHR), the Computerized Patient Record System, and was intended to better support primary care physicians to do clinical work. This approach represents a fundamental paradigm shift in the way EHR support can be conceptualized and implemented to move from a billing-centered perspective to a more user-centered, and ideally patient-centered, perspective.

Adoption of EHR systems in hospitals and outpatient clinics has reached a tipping point.5 EHRs revolutionize the way information is stored, accessed, shared, and analyzed for patients, patient cohorts, and organizations, creating a foundation for potentially dramatic improvements in the quality of care, patient safety, public health monitoring, and research.6 At the same time, use errors from design flaws and poor EHR usability can negatively affect patient safety7 and can encourage suboptimal workarounds. Workflow issues associated with EHR implementation, which include inefficient clinical documentation, have contributed to provider frustration, particularly in ambulatory care settings.8 A survey study indicated that nearly 60 percent of ambulatory care providers report being dissatisfied with their EHR due to workflow and usability concerns.9 Similarly, a recent mixed-methods study sponsored by the American Medical Association found that poor EHR usability, time-consuming data entry, and degradation of clinician documentation were prominent sources of professional dissatisfaction for physicians.10 Finally, there remains an extensive use of paper-based workarounds, suggesting that there are functionality gaps in EHR support, including in the ambulatory care setting.11

Known workflow challenges with EHRs in ambulatory outpatient care include the following:

Having to log in to multiple systems separately;

Extensive keyboard manipulation to enter information;12

The number of clicks involved in medication ordering processes;13

Difficulty in processing orders that are not standard;

Difficulty switching between different paths and screens to enter and retrieve information;14

Problematic data presentations such as patient medication profile design,15

Cluttered order and note screens;16

Difficulty seeing patient names on the screen;17 and

Missing free text entry and other word processing functionalities.18

A number of initiatives focus on the importance of workflow analysis in relation to EHR design and implementation. For example, NIST has released guidelines to improve usability and patient safety by establishing a protocol for formal EHR summative usability evaluation. The usability evaluation begins at Step 1 with an Application Analysis that covers interactions between users and the application.19

The 2014 edition of Certified EHR Technology (CEHRT) also included a safety-enhanced design certification criterion, 170.314:(g)(3), based on a user-centered design process that depends on a human-factors analysis of users’ tasks as a foundation for application design and evaluation. The need for human-factors task and workflow analysis as foundations for application user interface design has also been reiterated by the Office of the National Coordinator (ONC)20 and the American Medical Association,21 who highlight the dynamic delegation of work to members of the care team. Workflow would also be improved by better integration of information from multiple software packages and devices,22 by facilitating universal exchange standards,23 and by organizing information in ways that support cognitive work. Finally, unique workflow needs for specialty care areas have been identified for obstetrics and gynecology and for ophthalmology.24

Despite these initiatives, there are few published examples of how recommendations from human-factors workflow analyses are implemented in practice and how these analyses are translated into EHR design. The purpose of this paper is to describe how 12 of 15 recommendations from the NIST were implemented in a prototype, and what lessons were learned from those efforts.

Methods

We organized the original recommendations and associated stages and steps visualized in process maps from NIST and the VHA’s lessons that were learned from implementing the recommendations in the VAi2 prototype according to four stages. These stages were selected based upon review of existing process maps in the published literature, on websites, and used by hospital systems. The four stages of a routine outpatient visit for a returning patient are the following: (1) before the patient visit (approximately one to three days ahead); (2) during the patient visit; (3) discharge; and 4) visit documentation.

As an overview, all of the implemented NIST recommendations, applicable stages and process steps from the process maps, and implemented functionality in the VAi2 software prototype are provided in Table 1. Next, these are each described in detail, grouped by the stages.

Table 1.

Summary of NIST Recommendations and Associated Functionality in the VAi2 Software Prototype

NO.	NIST PROCESS MAP STAGE: PROCESS	NIST RECOMMENDATION	IMPLEMENTATION ELEMENT IN VAI2 PROTOTYPE
1.1	Before: Balance workload	Scheduling support with at-a-glance overviews of patients for the day	Displayed list of brief stories for scheduled patients in a time window
2.1	During: Warm up	Identifying time-critical notifications	Story template that includes time-critical notifications
2.2	During: Initiate intent to order	Drafting predicted orders	Default preliminary order sets
2.3	During: Document	Transferring initiated tasks to another to be completed	Documentation sessions and medication lists shared with interdisciplinary team members
2.4	During: Review chart, Document	Supporting established diagnosis-based workflow	Problem-oriented templates for viewing and recording information
2.5	During: Make working diagnosis	Supporting moving from working diagnoses to formal diagnoses	Templates customized based on diagnostic certainty
3.1	Discharge: Give patient summary	One-page patient summary	Exit summary narrative with business rules that define size
3.2	Discharge: Reviews and motivates following plan	Supporting handing off patient education	Site-defined educator teams
4.1	Visit documentation: Document relevant history, physical, assessment, plan	Reducing time spent on documentation of provided care	Preliminary documentation support
4.2	Visit documentation: Document relevant history, physical, assessment, plan	Supporting different views of a progress note based upon role	Customized displays based upon role
4.3	Visit documentation: Document to support billing	Distinguishing new documentation from copied information	Text permanently marked as “copied” or “fresh”
4.4	Visit documentation: Document and send consult and follow-up letter to relevant provider	Supporting communication with specialist physicians about referrals and consultations	Consultant is a team member with full documentation access

NIST Recommendations and Process Maps: Evidence Base

Recommendations to improve workflow in ambulatory care (outpatient) settings and process map representations were based on reflective statements collected during one-hour discussions with three physicians. Each of the three physicians had experience with different EHRs, represented different specialty areas as well as primary care, and had diverse perspectives on the ideal level of integration of EHRs into routine and exceptional workflows. They included two males and one female and were ages 30 to 50 years old. Each physician met separately with the same human factors facilitator. Each physician was presented with a description of the discussion topics in advance. This description explained that the purpose of the discussion was to utilize the physicians’ expertise to better understand the workflow for a typical return patient grouped by the stages “before the visit,” “during the visit,” and “after the visit.” With guidance from the human factors facilitator, a verbal walk-through of a typical return patient visit was then discussed and physicians were asked to reflect on and highlight challenging areas with the workflow that related to interactions with their EHR. Notes were taken by the human factors expert during the discussions and were shared within 24 hours with the physicians, who had the opportunity to correct and augment the clinical information. Minor corrections were provided following the discussions, such as correcting the spelling of medical terms.

NIST Recommendations and Process Maps: Generative Process

The four stages of a typical return visit in the outpatient clinic setting were used to organize, define, and visually represent process-map steps and related recommendations based upon interpretation of the unmet needs identified from the discussions with physicians. Process maps are high-level depictions of the primary functional steps in the actual workflow. In order to generate the recommendations and the process maps, a series of three focused interdisciplinary meetings were held with the NIST-sponsored research team. One of these meetings was virtual, and two were face-to-face. Each session included five to seven human factors, informatics, and physician experts. Prior to the series of meetings, the notes taken following the separate discussions with the physicians were compiled around emerging themes. The technical report prior to publication by NIST underwent a formal peer review process with several human-factors, informatics, and physician experts.

VAi2 Software Prototype: Development and Relationship to NIST Recommendations

The development of the VAi2 prototype was initially conducted independently from the NIST recommendations, but at a midpoint in the development process, all of the implementation elements were compared with the publicly available NIST recommendations. This comparison resulted in additional augmentations to the prototype. The comparison outcomes were documented in an internal report provided to the VHA project sponsor. Lessons learned from the implementation were documented.

Lessons Learned Based on Implementing NIST Workflow Recommendations in VAi2 Prototype

In this section, we use the four stages during the return visit for a typical patient in the outpatient setting to group the NIST recommendations and place them in the context of process stages and steps, and we describe associated lessons learned from the implementation of the VAi2 software prototype.

Stage 1. Before the Patient Visit

Figure 1 presents a process map depicting the steps related to activities occurring with the EHR before the visit. Among the physicians participating in the process mapping activity, there was high variability in whether and how physicians used information from the EHR in order to schedule patients in a way that would allow adequate time for challenging- or new patients, meet quality of work-life needs (i.e., not have one or two isolated visits scheduled during a single day), or coordinate with other physicians in their practice (i.e., help out a colleague by adding a patient). All emphasized that only about 10–25 percent of the patients required extensive review of historical information. However, reviewing recent patient information prior to the visit served several purposes, including the following: to remind oneself of the last visit’s plan of care, thus facilitating continuity across episodes of care; to determine whether pre-visit tests or consultations were needed; and to determine whether the patient had seen another provider since the last visit and for what reason. Pre-visit reviews also helped to build trust and rapport, as the provider appeared to be knowledgeable about the patients when they arrived. Two of the physicians reported that they reviewed the prior history and physical exam findings for every patient, either the night before, the morning before, immediately prior to seeing the patients, or at the beginning of the in-person interaction with the patient.

Figure 1.

Process Map for Stage 1 Activities Conducted Before a Returning Patient Visit with the EHR

NIST Recommendations 1.1: Schedule support with at-a-glance overviews of patients for the day

Up to several days prior to the visit, having the ability to get the gist of the overall workload for a day can be supported by easy access to an at-a-glance overview of scheduled patients to determine whether patients are routine, new, or particularly challenging patients (e.g., complex medical case, noncompliant patient). One physician described how the size of a paper chart used to be a cue to how complex or challenging the patient was. This information is not typically displayed at the top-level view in EHRs.

In addition, the timeliness of patient care could be improved by adding unscheduled patients that day. Patients who urgently need procedures or labs done could be scheduled earlier rather than at the end of the day. Alternatively, unscheduled patients who want same-day appointments could be delayed until the next day or later if a day is particularly busy or challenging. Infection control could also be improved by reordering patients to avoid having immune-compromised patients in the waiting room at the same time as a patient with a communicable illness such as chicken pox. New or particularly complex patients could be scheduled on days with lighter schedules or in the afternoon. Patients who have a history of being late or of not showing up could be scheduled at the end of the day.

Lessons Learned from Implementation Recommendation 1.1 in VAi2: Displayed list of brief stories for scheduled patients in a time window

The prototype was designed to dynamically generate patient stories in a scenario-specific user interface with the quantitative and qualitative content determined by the clinical context and modality of data input. Actionable information was appropriately grouped to show at a glance problems linked to medications and other lists, as well as problem-specific, out of range values or flags. The number of problems, like the size of the paper chart, is a visual indicator of the patient’s relative complexity. Grouping the problems with intended medications provides at-a-glance information about the patient’s current plan as well as reconciling medications with problems. Highlighting important information also provides visual cues about urgency or severity that aids prioritization and reduces cognitive load. These design features support rapid assessments of workload, work priorities, and focus while leveraging human capabilities for rapid pattern recognition and judgment.

Stage 2. During the Patient Visit

The process steps related to activities occurring with the EHR for “during the visit” are the following:

Check in patient and obtain vital signs and chief complaint from patient;

“Warm up” and review pertinent information; and

Collect medication reconciliation data and review of systems data.

Get history, signs and symptoms, review of systems, and make a working or presumptive diagnosis;

Examine patient, physical;

Make assessment and form initial treatment plan;

Review chart and research guidelines, informal consult;

Initiate intent to order medications, procedures, labs, consults;

Verify medications and allergies;

Pick diagnostic (ICD-9-CM, ICD-10-CM) and procedure (CPT) codes, verify insurance, investigate requirement for public reporting;

Verify dosage for some medications; and

Make explicit orders: medications, procedures, labs, imaging, consults and referral.

Several of the steps described are highly similar, presumably due to influences from regulatory aspects: what occurs during the check-in process, verifying medications and allergies prior to ordering medications, verifying review of systems data, assigning a diagnosis, educating the patient, and giving the patient’s summary information. There was greater variability in terms of what workflow elements were shared across multiple roles, including primary care or specialist physicians, physician assistants, nurse practitioners, intake nurses, nurse educators, case managers, medical assistants (clerk), and the patient or family member. Variation was described in the staff member who typically does the following:

Collects the review of systems data for the appropriate body functions;

Enters the information into the EHR;

Determines the diagnostic (ICD-9-CM, ICD-10-CM) and procedure (CPT) codes;

Determines whether insurance covers particular activities;

Verifies the accuracy of relevant medication types and dosages; and

Makes changes to the schedule during the day.

The following recommendations were made and implemented with respect to these steps:

Identifying time-critical notifications;

Drafting predicted orders;

Transferring initiated tasks to another to be completed;

Supporting established diagnosis-based workflow; and

Supporting moving from working diagnoses to formal diagnoses.

NIST Recommendation 2.1: Identifying time-critical notifications

All providers described an inbox metaphor in their EHRs where time-critical information related to patient visits was grouped together with less time-critical information. However, inboxes were often unwieldy and difficult to access, making it hard to see critical information in a timely manner. In this case, the inbox information was effectively invisible to providers. The physicians described four troubling instances where information relevant to that day’s visit was not incorporated because it was viewed after the visit had been completed. The characteristics of a desired solution included the following: (1) abandoning the inbox metaphor completely; (2) reducing information sent to inboxes (e.g., sending notifications about updated labs to an area dedicated to showing lab information with highlighted new information for groups of patients); (3) segregating types of information channeled to the inbox (e.g., time-critical information for that day displayed separately from other information); and (4) eliminating, grouping, and threading messages containing redundant information or updates about the information.

Lessons Learned from Implementing Recommendation 2.1 in VAi2: Story template that includes time-critical notifications

The prototype was designed to provide a means to build the components of patient stories, generated dynamically at run-time during data-binding from several composite elements: an introductory paragraph that has general and specific information about the patient, a set of problem-specific spaces summarizing each condition, and reminders that summarize health maintenance needs and alerts. Scenario-specific story templates can be derived from abstract templates and arbitrarily nested, making it easier to include data-driven, rules-based components such as time-critical notifications. Building story templates is expected to be an interactive, collaborative process performed by clinician informaticists and evaluated by human factors specialists. The eventual goal is to enable relevancy scoring of template components to facilitate showing only what is necessary in a given workflow context for a given patient.

NIST Recommendation 2.2: Drafting predicted orders

Several providers expressed that they would like to be able to initiate and compile orders “as they go.” This would allow them to build a plan through the visit before reviewing and finalizing it at the end. The plan could also include routine orders such as lab orders for diabetic patients, colonoscopy screening, and seasonal flu and pneumonia vaccines based on patient age. Several providers mentioned that there were often changes to predictions about what orders would be made as information was obtained from the patient, such as providing a different date for the last colonoscopy than was documented in the EHR. One approach to improving efficiency would be to present “draft orders” to physicians based on patient information that are then transitioned to “actual orders” during a visit via a verification process. It would also be important to purposely delay draft orders that require additional information, such as information from a radiologist about which imaging test is best to order, information about whether a procedure is covered by the patient’s insurance, or information about which pharmacy is used by the patient prior to ordering.

Lessons Learned from Implementing Recommendation 2.2 in VAi2: Default preliminary order sets

Preliminary order sets relevant to the current patient can be displayed and can be easily selected and edited. The preliminary order sets are generated based upon patient-specific information such as problems in the problem list. Moreover, the prototype includes an experimental “general clinical reconciliation” Web service for environments, where patient clinical data may need to be aggregated from multiple EHRs at geographically dispersed sites according to a federated architecture such as is used in the VHA. This prototype is currently being modified to use HL7 Fast Healthcare Interoperability Resources (FHIR) with custom extensions as the data exchange format to aid interoperability in a federated scheme.

NIST Recommendation 2.3: Transferring initiated tasks to another to be completed

All participants believed that physicians were a bottleneck in the process flow in ambulatory care settings and that there were aspects of how the EHRs were designed that increased bottleneck time, which thus had the potential for unintended consequences for patient care. For example, less time spent interacting with the patient may lower the quality of care, patient satisfaction, and reimbursement because appointments were longer with fewer scheduled in a day. In several cases, physicians felt that paper-based charts did a superior job in supporting workflow deviations. A common theme was the ability to transfer portions of tasks under the responsibility of physicians to other team members, such as preparing for the visit by pulling together information, reviewing or modifying the schedule, reviewing of systems data collection, verifying medication reconciliation data, asking screening questions, printing vital signs, drafting progress notes, drafting orders, providing patient summaries for educational purposes, and assigning billing codes.

Lessons Learned from Implementing Recommendation 2.3 in VAi2: Documentation sessions and medication lists shared with interdisciplinary team members

Information architectures that enable formal, supportive relationships of variable complexity among disparate members of the care team can improve workflow and reduce bottlenecks. For example, a check-in nurse may review a problem list to find follow-up issues; reconcile medications; verify, edit, and flesh out scratch notes; update the review of systems; and enter billing codes. Activities conducted by multiple personnel can be incorporated into a single, seamless documentation session. In addition, any team member can proactively makes changes to the medication list information (i.e., medication reconciliation) at any point in the workflow by marking up an integrated display of medications. However, as parts of a process are handed off to other roles, it is critical that the person taking over is able to see what the initial starting state was and what has been changed in the process. For example, during medication reconciliation, a physician needs to be able to see what the original medications were and what the check-in nurse changed. The prototype is currently being enhanced to support full modeling of team-based workflows, which then drive persistent, potentially long-running documentation sessions that can be shared by a team as well as with the patient during interactive reconciliation sessions. A prototype for medical reconciliation and allergy review—in which the provider is driving a reconciliation session from a Computerized Patient Record System (CPRS) workstation and the patient is using a tablet device to participate in completing the interview in real time—is currently at the pilot stages of implementation at several VHA clinics.

NIST Recommendation 2.4: Supporting established diagnosis-based workflow

Several physicians mentioned that elements of the provider exam were predictable based upon established diagnostic information. Providers differentiated between working diagnoses (i.e., not yet confirmed), established diagnoses, and new problems. For established diagnoses, templates could be generated to guide information typed in by medical assistants that could affect where the physical assessment was focused. It is important to note that few patients have a single diagnosis; it is typical to have complex combinations of multiple diseases that can present different problems.

Lessons Learned from Implementing Recommendation 2.4 in VAi2: Problem-oriented templates for viewing and recording information

Problem-oriented templates can be used for viewing and recording information for established diagnoses and for planning a subsequent course of care. These templates are designed to be rendered to multiple modalities of data input, including paper and HTML, allowing clinicians to decide which is best under the circumstances.

NIST Recommendation 2.5 Supporting moving from working diagnoses to formal diagnoses

All physicians expressed enormous frustration that most EHRs assumed that a diagnosis was already established at a detailed level. The consensus was that problem lists were not always accurate, for the following reasons: they were based upon extensive workarounds; not all information was available at the time it was required to be entered; and it was difficult to modify an existing diagnosis once selected. To determine a new diagnosis, providers wanted to begin with a less detailed working diagnosis based on preliminary observations and to confirm or disconfirm these via a differential diagnosis process before deriving a progressively more detailed diagnosis as more information became available. For example, a patient might start symptomatically with a cough—at which time “cough” is the most appropriate diagnosis. A physical exam may suggest that the patient has pneumonia, but tuberculosis cannot be ruled out until more definitive tests results are available. While labs are being ordered to confirm or disconfirm tuberculosis, the patient might be proactively treated as if he or she has tuberculosis in order to start treatment earlier, as well as to protect other patients and the public. Once a definitive diagnosis is made, a detailed ICD-9 diagnostic code may be selected after appropriate evidence has been collected and analyzed. The failure of EHRs to support the evolving nature of diagnostic and disease processes, including writing a progress note, writing an order, and documenting to support billing was frustrating, but also potentially misleading in this situation.

Lessons Learned from Implementing Recommendation 2.5 in VAi2 Templates customized based on diagnostic certainty

The prototype is designed so that dynamically generated story templates can be customized at design time to apply to degrees of diagnostic certainty. For example, one can be customized for a set of vague signs and symptoms, one for a primary workup for a new diagnosis, and one for follow-up care for an established diagnosis.

Stage 3. Discharge

In Figure 2, the process steps related to activities occurring with the EHR during discharge are shown. Some of the explicit orders were conducted during the physician encounter, some during the time of discharge, and some later in the day when visit documentation was completed. There was branching on activities based upon whether a clinical procedure was done, whether and how much patient education was conducted, and whether a patient summary was provided to the patient.

Figure 2.

Process Map for Activities Conducted During Discharge with the EHR

Recommendations that were implemented in the discharge stage are the following:

One-page patient summary; and

Supporting handing off patient education.

NIST Recommendation 3.1: One-page patient summary

Several physicians noted that after-visit summaries for compliance purposes were about 10 pages long. This is too long for most patients to comprehend efficiently, and—at times—elements included in the after-visit summary were inappropriate. For example, infants are not likely to need to attend a tobacco cessation program, yet reminders like this are sometimes required to be included in a printed summary in order to be compliant with requirements from accrediting organizations. In addition, required terms can be confusing to patients who had diagnoses previously explained to them in terms tailored to the health literacy level of the patient or caregiver. For example, a patient might have been told that, “A young and healthy kidney has 80–100 mL of cleaning capacity, yours is now 42 mL, and dialysis will be required at 15 mL, normally by age 60.” Then on the after-visit summary, this information is documented as “ICD-9-CM 585.3 Chronic Kidney Disease Stage III (moderate),” which patients might have difficulty recognizing as the diagnosis as previously explained to them. Although there was variation in specific information requirements, generally all providers agreed that a one-page summary with the required information attached would be an improvement. Suggestions for what information to include in a one-page summary are the following: (1) what needs to be done today; (2) what was ordered; (3) what medications are new or changed, including what has been stopped and what to continue taking at home; (4) information about when the next appointment is scheduled; (5) testing and referrals between now and the next appointment; and (6) instructions, including what to bring to the next appointment.

Lessons Learned from Implementing Recommendation 3.1 in VAi2: Exit summary narrative with business rules that define size

The prototype was designed to provide automated document-assembly functionality that converts entered data into a variety of narratives including exit summaries for patients. The content will be dynamically and intelligently generated based on document templates and context-aware business rules, which allows the defining of the size and content of the narrative for particular situations.

NIST Recommendation 3.2: Supporting handing off patient education

Patient education can be initiated by the physician and then handed off to others, such as the intake nurse, case manager, physician assistant, or nurse practitioner. In some cases, there are specialized roles, such as a diabetic nurse educator, for specific educational purposes. The current means of supporting this handoff such as clinical reminders that are required for all diabetic patients are not entirely effective at capturing patient-specific information. Some paper-based mechanisms are still usefully employed, such as handing education packets of brochures on particular topics with handwritten notes at the top for the person who accepts the handoff. Supporting this process with less reliance on the patient and paper-based mechanisms via the EHR would be useful if sufficient usability were achieved. Understanding what motivates the patient to invest energy into improving health is a particularly important aspect of patient education, and supporting physicians sharing this information—such as the patient wanting to be able to spend time with grandchildren without being intubated due to overexertion—would be helpful in making education more patient centered.

Lessons Learned from Implementing Recommendation 3.2 in VAi2: Site-defined educator teams

The “team” is defined locally at each site. Teams can include patient educators and the patient, with each member having their own tailored display with role-specific content. For example, the patient’s display source could be a digital paper form, a computer kiosk, or a Web page. The educator’s display could be a paper form or a browser-based application to record services provided and comprehension level. An important design goal of the system is to allow different team members choices in these modalities of input, rather than force every member to operate in the same way. What is important is that the same knowledge gaps are being filled in based on the same patient story, not whether one member prefers a particular way of working (i.e., paper versus electronic devices).

Stage 4. Documentation

In Figure 3, the process steps related to activities occurring with the EHR during documentation are shown. In order to support clinical work, the physicians document the relevant history, physical assessment, and plan. A required activity was to document information in the note to support billing requirements. Similarly, there was documentation associated with the expectations of reconciling medications and other documentation to meet Meaningful Use requirements as well as documentation to support objectives of other stakeholders for legal, research, and quality improvement purposes. Where specialist referrals were needed, there was associated documentation for that purpose.

Figure 3.

Process Map for Activities Conducted During Documentation with the EHR

Recommendations that were implemented in the documentation stage are the following:

Reducing time spent on documentation of provided care;

Supporting different views of a progress note based upon role;

Distinguishing new documentation from copied information; and

Supporting communication with specialist physicians about referrals and consultations.

NIST Recommendation 4.1: Reducing time spent on documentation of provided care

All physicians reported immense frustration, reduced productivity (fewer patients scheduled in a day), and reduced personal time due to increased time being given to document care. One physician changed organizations in the hopes of having more time with patients with a more efficient EHR and different documentation policies. There was consensus that a positive feature of the EHR was an increased ability to document progress notes from home or other locations. The risks of failing to return a patient’s chart in a timely fashion if brought home were considered too great with a paper-based system, and therefore most physicians chose to stay in the office to do post-visit documentation. With the introduction of the EHR, all reported being able to leave the office earlier, but more time was spent doing documentation from home at night.

Lessons Learned from Implementing Recommendation 4.1 in VAi2: Preliminary documentation support

The prototype has a number of strategies to reduce documentation time; special attention is given to the “preliminary documentation” approach. The goal is to ensure that all knowledge gaps, including clinical findings and orders, are resolved at the point of care, at least in draft form. This is accomplished in a dedicated, scenario-specific display that is different from the one used in the exam room. The solution uses a workstation, and the editing screen is coupled to the unique activities of the current visit. Scratch notes, check marks, and other marks are automatically converted to editable text, and this information is extended via typing or real-time voice transcription. The architecture supports access to commercial services for voice transcription and coding so that this functionality can be integrated. Typically, orders are validated against a complex set of EHR business rules, and then require a final signature. In addition, the prototype obtains computable information from scratch notes, marked up charts and diagrams, check boxes, and voice annotations.

NIST Recommendation 4.2: Supporting different views of a progress note based upon role

One potential design opportunity would be to change the view of the progress note based upon a particular role. For example, the progress note for a primary care physician would have a different view from a specialist such as a urologist physician, who might not need to see all of the information that is displayed to the primary care physician.

Lessons Learned from Implementing Recommendation 4.2 in VAi2: Customized displays based upon role

Customized data views include notes and stories. In other words, the narrative is synthetic. For medico-legal, quality assurance, and research purposes, the prototype is designed to take a snapshot of what the users actually see when the narrative is presented during the workflow and to record, for analytics purposes, all changes to the data during the session. The synthetic narrative is generated at run time via automatic document-assembly technology based on templates and business rules. The business rules take into account the user’s role as well as the context. For example, the story viewed by a primary care physician differs if a patient is seen on a weekly basis versus an annual basis.

NIST Recommendation 4.3: Distinguishing new documentation from copied information

A well-known and frequent workaround with all EHRs is to copy and paste information. There are three known variations: (1) to copy from one progress note from a prior visit for the current visit, which serves as a first draft that is then revised to increase the efficiency of documentation, increase coverage, and reduce the likelihood of having contradictory information across notes; (2) to copy information into a temporary repository, such as Notepad, in order to view it in parallel with another tab, system, or period in order to remember information; or (3) to copy information from one patient with a similar diagnosis to another, in order to have a working draft that is then revised to increase the efficiency of documentation and provide a template of what to include. A concern with this type of workaround is that billing should be done only for procedures that were done in that visit, therefore it is important for coding and billing personnel to distinguish between old (copied) and new (typed) information.

Lessons Learned from Implementing Recommendation 4.3 in VAi2: Text permanently marked as “copied” or “fresh

In its default configuration, the prototype strongly discourages the use of the copy and paste workaround during a documentation session. From the end user’s perspective, it is easier to carry most information forward and just concentrate on documenting new findings. When a knowledge gap is filled in, metadata associated with that instance of the recorded information is permanently marked as “copied text” or “fresh text.”

NIST Recommendation 4.4: Supporting communication with specialist physicians about referrals and consultations

Providers raised what they considered to be a critically important patient-safety issue resulting from changes in documentation practices associated with changes from paper-based referrals to EHR-based referrals to specialist physicians. The pattern is to have much sparser to no documentation or communication at all following a consultation by a specialist physician.

Lessons Learned from Implementing Recommendation 4.4 in VAi2: Consultant is a team member with full documentation access

With the prototype, a consult request and response can be included in the workflow that governs a specific documentation session. In other words, the consultant is included in the documentation team and is directly tied to the overarching documentation session for the encounter, including access to the complete story. In this manner, multiple documentation sessions across practices can be linked and the documentation activities of disparate clinical teams can be aggregated as part of the entire patient narrative.

Discussion and Conclusion

Overall, the lessons learned from implementing 12 of the 15 NIST recommendations to improve workflow in ambulatory care using an EHR provide a first step in moving from a billing-centered perspective on how to maintain accurate, comprehensive, and up-to-date information about a group of patients to a clinician-centered perspective. This perspective more centrally revolves around the needs of primary care providers—including physicians, physician assistants, and nurse practitioners. These recommendations point the way toward a “patient visit management system,” which incorporates broader notions of supporting workload management, supporting a flexible flow of patients and tasks, enabling accountable work to be distributed across members of the clinical team, and supporting dynamic tracking of steps in tasks that have longer time distributions. For example, the concept of “ordering a medication” involves concepts of anticipating potential orders, updating order expectations with input from patients regarding their priorities and new information, revising the details of orders in order to meet reimbursement and other requirements, and tracking the status of tasks done by others prior to a patient receiving the medication. In our opinion, the most important and innovative solutions implemented in the prototype pertain to maintaining the centrality of the patient narrative for clinicians to use in dynamic decision-making, and to ensuring that planned actions are conducted by providing reminders and scenario-specific checklists during the visit. These combined solutions support clinicians in employing notes for moving from working to final diagnoses and also for moving from tentative plans for orders to final executable orders.

Workflow, usability, and patient safety can be enhanced through clinician-centered design of EHRs. In this case study, innovative technologies were employed to also reduce the burden of data entry and tailor the interface to specific scenarios.