2 Workflow and Process Analysis and Redesign for HIE and Other HIT

Section2.3 Plan

Section 2 Plan—Workflow and Process Analysis and Redesign for HIE and Other HIT - 1

Workflow and Process Analysis Redesign for HIE and Other HIT

Understand workflow and process analysis and redesign, as well as how to set expectations to achieve goals, initiate change management, and use process mapping as a means to manage change.

Time needed: 40 – 80 hours
Suggested other tools: NA

Introduction

You have most likely seen articles about unintended consequences of electronic health records (EHR) or other health information technology (HIT). However, two key factors recognized in many of the articles about HIT are:

1.Workflow and process changes must be understood and managed. For example, one article describes increased mortality at a children’s hospital that had implemented a commercial provider order entry system. Its deaths were largely due to overdoses of drugs as a result of inadequate calibration of dosing for pediatric services. Sadly, the hospital had not adjusted its system to the differences between children’s needs and what was provided in its commercial product that is normally used in an adult setting. Workflow and process changes should be made to maximize the effectiveness of HIT. The changes point out control points that must be present or should be added to HIT for optimal results.

2.Professional judgment must be applied when using any tool, including all forms of HIT. Computers can crunch data tirelessly and remind humans who may be forgetful in the rush of their everyday lives. The massive volume of data they are able to process at one time aids in decision making within complex environments. However, they are not substitutes for the experience of trained workers.

Process Mapping as a Means to Manage Change

Process improvement experts suggest that the best way to help potential new users of information systems overcome resistance to change and appreciate their role is to demonstrate the efficiencies and safety of information systems and to engage users in making their own changes.

When all individuals take a critical look at the processes they currently perform, bottlenecks, delays, duplication of effort, and other issues become clear—and powerful motivators for change. While some vendors may suggest that mapping current processes is not necessary because their product will introduce appropriate changes, experts counter that mapping current processes and workflows encourages process improvement initiatives to begin early and continue throughout the duration of the HIT project for several reasons:

Starting to understand current processes and how they may be improved with HIE and other HIT before new systems are selected can help users contribute ideas about what functions they would like to see in HIT, thus aiding the vendor selection process.
Correcting broken processes where possible in advance of HIT helps keep these processes from being replicated in the HIT environment.
Having well-defined maps of current and redesigned processes can enhance implementation activities. Opportunities for improvement will have been identified early and will not need further explanation. Implementers get a jump start in knowing what elements of current processes will be changed by the HIT and this can speed up implementation.
Initiating process improvement early helps prevent users from feeling as though they are being forced to accept someone else’s changes. During implementation, process changes should be tweaked and compromises should be made between what is desired and what is feasible or recommended by the vendor’s product.

Workflow and Process Mapping

Process mapping is a fairly well-defined science, with a number of tools and techniques that can be deployed to understand current workflows and processes as well as identify opportunities for improvement. Process redesign is not a new concept. Process mapping for processes performed by knowledge workers is difficult because the processes are performed mentally, professionals rarely want to spend time mapping processes, and a consultant who might do process mapping for them can’t see their mental processes.

Mapping Current Workflow and Processes

The following steps should be used to map current workflow and processes:

1.Identify processes to be mapped—those that will be impacted by the HIE and other HIT being acquired.

2.Use mappers who actually perform the process; they know it best and they need to own the impending change.

3.Instruct participants about process mapping—why it is being done and how it is done.

4.Map current processes, sometimes referred to as the “as is” processes.

Ensure that all workarounds and other issues incumbent in the process today are included. Mapping only what you think the process should be can cause critical controls built into the current processes to be overlooked.
Avoid jumping to proposing changes until the current process is fully mapped. Some aspects of the process can be overlooked if participants start to map the future state too early.

5.Validate maps to ensure they reflect current processes, all variations, and all the information collected and processed (the “information payload”). Because this mapping is being performed to support adoption of information technology, how you currently use information should be the focus. Avoid getting detailed on aspects of a process that cannot be automated.

6.Collect all forms and reports that are part of processes to be automated; they will help you review data input and output requirements.

7.Collect baseline data or obtain benchmark data to define expectations for change and for use in goal setting and benefits realization studies.

Workflow and Process Mapping Tools

There are several tools that may be used to document workflows and processes:

Systems flowcharts (most commonly used for documenting HIT processes)
Swim lane process chart (especially useful where there are multiple people or organizations involved in a process, such as for HIE)
Flow process chart (a more narrative approach that is often more comfortable for those new to HIT, although less supportive of documenting decision points or alternative flows)

Systems Flowchart

The systems flowchart is the most popular tool used to map current and proposed workflows and processes. There are many symbols that can be used to illustrate special functions, however, most find the following basic symbols not only easy to understand but easy to use. (Systems flowcharts can also be created using sticky notes put on a wall, where they can be easily viewed. The horizontal placement of a sticky note designates a process and the tilted view designates a decision point.) The flowchart on the right describes the “rules” for how to use these two symbols, plus ovals to designate boundaries.

Ovals designate boundaries: where the process begins and ends for each path through the workflow
Rectangles explain the process steps:
Who (by credential)
Does (action verb)
What (with data)

Diamonds denote variations and decisions:
What choices? What alternatives?
What information is needed to make the decision?
Must have at least two branches, can have three or more.
Label all branches (yes/no, 1/2/3, < = >, etc.) to explain why there is more than one path through the workflow

See below an example of how these symbols are used to map workflow. The process is for a social service agency (SS) obtaining clinical information from a physician’s office. The D symbol has been added to illustrate where there are delays. You can insert the amount of time (hours/days) consumed by the delay if that information is available.

This map could be extended to illustrate how the fax the agency receives from the physician’s office is processed internally—such as a receptionist having notifying a staff member, holding the fax at the receptionist’s desk, filing it if the staff member is not present that day, not being able to find the fax later, etc. Once the fax is received by the staff member, there could also be delays in processing, misplacement of the fax, having to request it be refaxed, etc. Finally, once action is taken, you can map filing of the fax, others needing access, misplacement, archiving, destruction, etc. A seemingly simple process can become fairly complex—and offer many opportunities for improvement. Note that the map is detailed and reflects true reality. Without this level of detail,opportunities for improvement would not be as easy to identify.

Example of Systems Flowchart for Mapping Current Request for and Obtaining Clinical Information from a Provider

Swim Lane Process Chart

The swim lane process chart (shown below) is an excellent tool to depict a process that has many handoffs. It is useful to show dependencies among parties, making it ideal for illustrating the potential value of HIE. For example, instead of using the systems flowchart for mapping the process to obtain clinical information, a swim lane could have been used to depict what the social service agencydoes and what the provider does.

Symbols used in the swim lane chart may be the same as those used in a systems flowchart or may simply be documented as illustrated. Arrows may used to show handoffs between parties, or placement of the steps can denote handoffs. It is assumed that the flow within a swim lane proceeds in the sequence designated. While the swim lane process chart may seem easier to use, if there are options for decision with branching, these are not as easily illustrated. Inthe illustration, the social service agency does not receive the information twice, but that is how the sequence is presented for options.

Obtains Faxes Info Ask client Info Info

Auth Auth Rec’d to Request Rec’d Not Rec’d

Provider

Accepts Faxes Does not Receives Faxes Does not

Auth Info Accept & Request Info Accept &

Notifies Does Not Notify

Flow Process Chart Template

The flow process chart lists the steps in a process. This is sometimes easier for people who are not visually oriented. The symbols designation on the side serves as a quick reference. In addition, this tool is set up to track the time it takes to complete each step. If each step is performed on only one unit of work at a time, there is no need to record quantity. However, some tasks might be performed in a batch, and keeping track of quantity helps analyze productivity. This tool can also be used to analyze processes for future changes. Much like the swim lane chart, however, this tool is not conducive to documenting options or decisions.

Flow Process Chart

Process:
 Present  Proposed / Analysis () / Performed by:
Date:
Operation / Transportation / Inspection / Decision / Delay / Storage / Time / Quantity / Why is it done this way? / Notes
Why is it done by this person?
Why is it done at this time?
Why is it done at this location?
Why is it done – is it necessary?
Details of present/proposed process: /

Notes

 /  /  /

◊

D

/ 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
 /  /  / ◊ / D / 
Totals: / Present / Proposed
 / Summary: / No. / Time / No. / Time
Operations
 / Transportations
 / Inspections
◊ / Decisions
D / Delays
 / Storages
Totals:

An additional resource that provides a comprehensive discussion of workflow and process redesign for HIT is: Process Improvement with Electronic Health Records: A Stepwise Approach to Workflow and Process Management”, M. Amatayakul, CRC Press, 2012.

Workflow and Process Redesign

Once current process maps are documented, the following steps should be used to map how workflows and processes can be performed in the future with HIE and other HIT in order to meet your goals:

Identify potential problems in current workflows and processes and determine their root causes. Study the following areas:

□Bottlenecks

□Sources of delay

□Rework due to errors

□Role ambiguity

□Unnecessary duplications

□Unnecessary steps

□Long cycle time

□Lack of adherence to standards

□Lack of information

□Lack of quality controls

The following tools may be helpful in identifying root causes of potential problems:

□Statistical charts (e.g., Radar, Pareto, Control)

□Relations diagrams

□Tree diagram

□Affinity diagram

□Force field analysis

□Cause and effect diagrams

□Physical layouts

Identify changes that may be able to resolve problems today.
Educate about HIE and HIT and identify further changes that will be possible.
Document changes by creating a map showing proposed improvements, sometimes referred to as the “to be” state.
Use the redesigned map to identify functional specifications for vendor selection.
Use the redesignedmap to make any necessary configuration changes in the HIT applications to achieve your desired improvements.
Test new workflows and processes.
Train all staff on new workflows and processes.
Incorporate changes into policies and procedures.
Collect current data about outcomes, evaluate against your goals, celebrate successes and correct course where necessary. Conduct formal benefits realization as applicable.

Workflow and Process Redesign Example

In analyzing the process described in the examples above, it can easily be observed that there is a significant amount of delay at several points in the process. In some cases, in fact, the delay may be so great that action is taken without the desired information, or maybe no action can be taken because the information is not available. There are both productivity issues associated with a fairly complex workflow for a seemingly simple process, as well as quality of service issues. In addition, there are anticipated workflow and process issues involving extending the process to subsequent receipt, use, and storage of the information.

The following are two potential revisions to the process. The first illustrates how the use of secure email via the Direct protocol can reduce delays and add alerting that the information has been received. It can also be anticipated that use of Direct will aid in subsequent processing of the information because it is received and filed in electronic form so others in the social service agency have access to it as needed (and can search to locate the document however it may have been indexed).

Example of Systems Flowchart for Mapping Future Request for and Obtaining Clinical Information from a Provider Using the Direct Email Protocol

In the example above, review of the current state may have illustrated that sending the SS authorization form to the MD often results in a delay where the MD wants its own form to be used. (The frequency of this and amount of time delayed could have been documented in the D symbol on the current map.) The SS decides to start using the Direct email protocol. This means that both parties to the exchange agree with a trusted certificate authority to exchange encrypted email and a community-based care coordinator has helped set standards for email response time. SS has decided that part of its new process will be to request the form from the MD’s receptionist and have the client fill it out so it can be returned to the MD via Direct email within a matter of minutes. Still, there is the potential for delay, so an alert has been set that if the form is not received within five minutes, the receptionist will be called.

Once the signed authorization form has been emailed (the client completes and sign the form online using the SS’s computer), there is another potential for delay. The community may have set the standard at less than one day for response because most MD offices now have electronic health records (EHR). Still, there is a human factor so the process must include deciding whether to call the office if the information is not received within the specified time period, or proceed without the information.

The second example illustrates how participating in an HIE organization (HIO) can streamline the process of client authorization and receipt of the information even further. In this case, if the HIO retains clinical summary information and the client has previously indicated preferences for authorizing disclosures, there is no intermediary step of sending the authorization to the MD and waiting for the information to be sent via Direct email. If only consent is required, the client can provide that online. If there is no information about the client, the SS can follow the same procedure as above, using the Direct email protocol. The ideal future state includes no delays and has the same additional benefits as described above for receiving the information, using it, and storing it.

Section 2 Plan—Workflow and Process Analysis and Redesign for HIE and Other HIT - 1