process-aware-hit – Healthcare Business Process Management Blog by Chuck Webster, MD, BSA (Accountancy), MSIS (Intelligent Systems), MSIE (Industrial Engineering), #HIMSS18 Social Media Ambassador

Process-Aware EHR Workflow Management Systems: Essentials, History, Healthcare (Written In 2004!)

Warning: fopen(himss16-tepr-toc.txt) [function.fopen]: failed to open stream: No such file or directory in /home/content/41/4031141/html/000websites/wareflo/wp-content/plugins/allow-php-execute/allow-php-execute.php(13) : eval()’d code on line 3

Warning: filesize() [function.filesize]: stat failed for himss16-tepr-toc.txt in /home/content/41/4031141/html/000websites/wareflo/wp-content/plugins/allow-php-execute/allow-php-execute.php(13) : eval()’d code on line 4

Warning: fread(): supplied argument is not a valid stream resource in /home/content/41/4031141/html/000websites/wareflo/wp-content/plugins/allow-php-execute/allow-php-execute.php(13) : eval()’d code on line 4

Warning: fclose(): supplied argument is not a valid stream resource in /home/content/41/4031141/html/000websites/wareflo/wp-content/plugins/allow-php-execute/allow-php-execute.php(13) : eval()’d code on line 5

In 2003 and 2004, thirteen years ago, I wrote a series of white papers, and presented them at the now defunct TEPR (Towards an Electronic Patient Record) and 2005 HIMSS conference in Dallas. In that series I laid out a dramatically different EHR architecture. It was workflow-centric, whereas todays EHRs are data-centric. I was remarkably prescient. However, it’s taken more than a decade so see much of what I predicted to finally begin to come true. Every year, since 2011, I search every HIMSS exhibitor for workflow and workflow tech-related content. We are finally seeing a remarkable search in workflow tech, such as workflow engines and business process management (BPM) highlighted defusing into healthcare and health IT. So, for this years HIMSS16 conference I sliced-and-diced that original series and white papers and am tweeting those bits during this years HIMSS16 conference. (Skip the “Table of Contents” and go directly to original 2004 material. Skip both the TOC and 2004 contents and go to HIMSS16 commentary.)

(also see the 2005 HIMSS05 paper EHR Workflow Management Systems in Ambulatory Care)

EHR Workflow Management Systems: Essentials, History, Healthcare

Charles Webster, MD, MSIE, MSIS

Abstract

Workflow management system technology promises critically important increases in electronic health record (EHR) usability and productivity. This paper describes the characteristics of electronic health record (EHR) workflow management systems (WfMSs): the difference between workflow management and mere workflow, the workflow reference model, the central role of the process definition, various frameworks within which to understand workflow, a productivity survey, the importance of workflow management to EHR usability, and future research and development directions.

Keywords

Workflow management systems, electronic health records.

Introduction

Electronic health record systems are evolving from patient documentation systems into tools for physicians to accomplish their many tasks and to manage others with whom they work in close conjunction: to document, to direct, and to delegate. EHRs used in this way must have customizable workflow—to specialty content, to local clinical and administrative processes, and to user preferences. If an EHR can be instructed (that is, customized) in what to do—automatically— based on who, what, why, when, where, and how, the EHR is not just a patient documentation system, it is an EHR workflow management system.

Throughout this article I will rely on a series of frameworks to present the components, behaviors, and advantages of EHR workflow management systems. These different frameworks are not mutually exclusive (occasionally making the same point in different terminology), however, used together, they provide a broad description of EHR workflow management systems components, behaviors, and advantages (over non-workflow management system EHRs).

Warning: fopen(himss16-tepr-end.txt) [function.fopen]: failed to open stream: No such file or directory in /home/content/41/4031141/html/000websites/wareflo/wp-content/plugins/allow-php-execute/allow-php-execute.php(13) : eval()’d code on line 38

Warning: filesize() [function.filesize]: stat failed for himss16-tepr-end.txt in /home/content/41/4031141/html/000websites/wareflo/wp-content/plugins/allow-php-execute/allow-php-execute.php(13) : eval()’d code on line 39

Today, “workflow management systems” has been superseded by “Business Process Management” systems (BPM). Though you will notice I do mention Business Process Management in this 2004 paper. You may also be interested in my more recent BPM-based Population Health Management & Care Coordination: Workflow, Usability, Safety & Interoperability Perspectives.

Take me to the next blog post in this series! The Critical Difference Between Workflow Management Versus Mere Workflow: Process-Aware HIT.

The Critical Difference Between Workflow Management Versus Mere Workflow: Process-Aware HIT

Workflow Management Versus Mere Workflow

Van der Aalst and van Hee [1] describe an evolution of information systems that can be profitably applied to the evolution of the EHR as well. First were collections of separate applications, each with its own database; then applications began to share a common database. Each application had its own user interface; then applications shared a common look and feel and, increasingly, context as well. Finally, workflow-related business logic moved into workflow management systems, which managed application workflow. In short, data, user interface, and now workflow have migrated or are migrating out of healthcare applications and into shared databases, user interface resources, and workflow management systems.

A workflow management system is a software application that stores and executes workflow or process definitions to create and manage workflow processes while facilitating interactions among users and applications [1, 2]. “Workflow” and “workflow management” (and by extension, “workflow systems” and “workflow management systems”) are frequently confused and this is naturally so. Users usually interact with workflow systems, not the workflow management systems used to implement them. However, it is the underlying workflow management system that allows a workflow system to be flexibly tailored to local processes and user preferences, and to be easily monitored and maintained.

A useful analogy can be made between a database management system and a workflow management system. A database usually comes with a database management system that is used to execute and manage it. The database management system creates, executes, monitors, and edits the database, but is not itself the database. During database execution, users and applications create, update, and delete data. Similarly, a workflow management system creates, executes, monitors, and edits a workflow system, but is not itself a workflow system. The main advantage to EHR users of getting both a workflow system and a workflow management system—together—is that they can further customize the EHR workflow system to reflect their clinical needs, personal preferences, and business requirements.

At this moment when the EHR can benefit so much from workflow management system technology, the EHR can also benefit from the model of how the workflow management system industry has developed during the past decade. In both cases, WfMSs then and EHRs today, there existed or exists a software application that had or has great potential to increase the effectiveness and efficiency of core processes as well as increase the satisfaction of those engaged in making those core processes happen. While there was and is great opportunity, there was and is uncertainty. There was no standard model of application functionality and no standard terminology for discussion, education, and planning. So, the Workflow Management Coalition helped to define a standard model of workflow management, the Workflow Reference Model [2] (Figure 1 represents relationships among important terminology).

This Workflow Reference Model described a common vocabulary about workflow, a workflow management architecture that was technology and vendor neutral, and key interfaces that required standardization.

The Workflow Reference Model is reminiscent of the electronic health record reference model being defined today. So, it is natural to connect these two efforts when presenting the concept of electronic health record workflow management systems. In fact, a recent paper examining the legacy of the original reference model concludes by saying that the core legacy may be that “it has provided a common framework for people to think about Workflow and BPM (Business Process Management) and ten years of fascinating discussions!” [3] I hope and believe the same will be true of electronic health record workflow management systems, too! (By the way, there remains a residual of terminological variation, such as process definition versus workflow definition.)

For further exploration of the difference between a workflow system and a workflow management system, see my Confusing Workflow Technology With Workflow Is Like Confusing Your Database With Your Data.

Take me to the next blog post in this series! The Critical Importance of Executable Model Of EHR Workflow: Process-Aware HIT.

The Critical Importance of Executable Model Of EHR Workflow: Process-Aware HIT

At the heart of an EHR workflow management system is the workflow or process definition, which is used by a workflow engine to drive EHR behavior. For example, in Figure 2, applying the Workflow Reference Model to an ambulatory context, we see on the left a process definition. In this case, the process definition drives the se- quence of screens presented to two members of the ambulatory team, to the nurse and then to the physician: (1) Get Patient, (2) Take Vital Signs and a Chief Complaint, (3) Review Allergies, (4) Review Medications, (5) Examination, (6) Assessments, (7) Orders, (8), Evaluation and Management code generation, and (9) Billing Approval.

On the right is a process instance, sometimes referred to as a case. This is the actual patient encounter. To use an analogy, if the list on the left is a recipe, then the list on the right is the actual cake!

business-process2

Workflow management systems have workflow or process definition tools. These are graphical editors that al- low a non-programmer to define or modify EHR workflow, in effect, to program or debug EHR workflow be- havior. Figure 3 depicts one such tool. (By the way, this gives rise to a litmus test: if an EHR purports to be an EHR workflow management system, ask to see the process definition tool. While it may not look exactly like Figure 3, it should allow changes in a process definition used by the workflow engine to drive EHR behavior.) In this case, the process definition saves the user from having to navigate manually through a thicket of menus, tabs, or popup lists; the EHR presents the correct screen given the context of the user’s tasks.

Process definitions are used by the workflow engine in a similar way to rules being used by an expert system. The workflow engine reasons about who, what, why, when, where, and how in order to save the user work. Who is the user? (Dr. Jones or Dr. Smith?) What is their role in the office? (Physician, nurse, technician?) Why is the patient here? (Well child? Chronic disease management?) When is “now”, relative to what has been accomplished and what remains? Where is the user? (Exam room? Tech station?) How does this specialty accomplish its tasks?

Each step in the process definition corresponds to a specialized data presentation, acquisition, or transformation task. The process definition describes the event that triggers the presentation of the screen as well as a context that informs its content and behavior. For example, the Review of Systems screen allows the nurse to do just that, review the patient’s systems. It is triggered by the completion of the preceding screen (or by the nurse log- ging into the EHR in the exam room in the presence of the patient after all the preceding tasks in the process definition have been accomplished).

Note, however, that the process definition does not merely drive a sequence of screens with respect to a single user; rather, it drives a sequence of activities, some visible as screens, others not (printing, messaging, and so on) across a team of users occupying a variety of roles (nurse, tech, specialty provider). There are many such screenless tasks, such as printing patient materials, automatically inserting a work item into a worklist, or communication with other applications such as devices (ECG, vitals), intra-office programs (billing, patient inter- view), or communicating with the outside world (laboratory, e-prescribing).

Thus, EHR workflow management systems offer means to integrate applications with applications (such as communication from scheduling to patient charting and order entry and then on to billing, or between a medical device and the EHR), integrate applications with users (such as retrieving data from already existing systems), and integrate users with users (as in this example, in which the nurse’s tasks precede the physician’s tasks and information is forwarded from the nurse to the physician—in a more complex and realistic scenario, the physi- cian might delegate additional tasks to the nurse and monitor them.)

For more on the incredible value of executable models of healthcare workflow, see my BPM-based Population Health Management & Care Coordination: Workflow, Usability, Safety & Interoperability Perspectives.

Take me to the next blog post in this series! Different Versus Same Person Versus Time EHR Workflow: Process-Aware HIT.

Different Versus Same Person Versus Time EHR Workflow: Process-Aware HIT

The following four categories of EHR workflow (Table 1) are useful in broadly construing EHR workflow ca- pabilities. First there is different person/different time workflow. This is the classic workflow that most people think of as workflow. The nurse enters vitals information, which is forwarded to the physician who reviews it and other data, and then delegates tasks back the nurse.

Then there is different person/same time workflow. The workflow management system workflow engine “knows” what activity started where and for how long, as well as who is responsible, and this information can be fed into not just worklists but onto a universally available status screen. Everyone can see which patient is waiting where, for what task, for how long and who is responsible. This screen functions much like the radar screen in an aircraft control tower, only it is patients and tasks being are tracked, not airplanes. By continually updating a universally accessible display of system state—a universal worklist tagged with information about location, time, and responsibility—all EHR users can maintain a shared mental model, and, more important, they can act with respect to that model under the assumption that others have the same mental model of what needs to be done, where, and who is responsible. (This does sound complicated, but reflect on how much judg- ment often depends on one person knowing that another person knows something, or even each person knowing that other people know that he or she knows something.)

person-vs-time-workflow

Not only can a user send information or a delegate task to another user, a user can do so to themself, much as people sometimes send an email to themselves or leave a message on their own answering machine. This is same person/different time workflow.

Finally, there is same person/same time workflow. This kind of workflow does not come as naturally to mind as the classic different person/different time workflow, but it can be critically important in a “user friendly” EHR. Just as process definitions can be used to forward tasks from person to person, they can also be used to drive the individual screens that a single user interacts with during the accomplishment of a series of related activities. Instead of having to navigate through thickets of menu hierarchy or drilling down through complicated dialog boxes or scrolling through long lists, the information that has been gathered or deduced so far (what is the en- counter type, who is logged in, what is the next step in the process definition) determines the right screen, in- cludes the right content (data, orders) on that screen, and displays the content in the most appropriate format (such as a list sorted by category or alphabet, based on the user’s preference).

Take me to the next blog post in this series! Multi-Specialty, Multi-Site, Multi-Encounter Workflow Management: Process-Aware HIT.

Multi-Specialty, Multi-Site, Multi-Encounter Workflow Management: Process-Aware HIT

Here is another set of dimensions for understanding and comparing EHR workflow management systems.

Workflow management systems for ambulatory medicine must (eventually—to be maximally effective) span time, space, and subject matter. These dimensions correspond to multi-encounter, multi-site, and multi-specialty workflow management. Multi-encounter workflow management results from process definitions that span en- counters (useful for chronic disease management). Multi-site workflow management spans sites (for example, medical offices in different parts of town). Multi-specialty workflow management allows a workflow engine to coordinate the flow of tasks among multiple specialists (both in the sense of routing between specialists, but also in the sense of different specialists having their own specialty-specific process definitions).

Multi-encounter workflow management includes, for example, the following: follow-ups, in which a step in one process definition triggers the application of a future process definition (such as returning for a specialized test); referrals, in which a process definition triggers a future review of an intervening external consultation; and re- curring activities such as screening tests and chronic disease management.

Now consider multi-site workflow management. The same specialist may be at one medical practice location one day but at another the next. Can specialty process definitions be shared across sites, eliminating the need for creating separate process definitions for each site? Alternatively, can different sites create their own site specific process definitions? Can each site track its own patients, but can a supervisor also easily see what is happening at another site? (“Hey! I’m calling from the Eastside office to ask why Mr. Smith has been waiting an hour for his vitals?”) Can process definitions span sites, so that a patient can be seen in one office but show up at another office for testing only available there?

One way to think of multi-specialty workflow is in terms of an analogy to rail mass transportation in a major city. Subway lines start in different places, end in different places, stop in different (but also the same) places along their way, but work together in a globally coherent system. Each specialty has its own collection of proc- ess definitions, whose constituent tasks may or may not be shared with each other (like subway stops, to con- tinue the analogy). Patients enter one workflow (subway line) but may switch to another workflow during the course of consultation between specialists. Specialty workflows start and stop in different places while sharing resources and working together in a globally coherent system.

Take me to the next blog post in this series! A Survey of EHR Workflow Management Productivity Survey: Process-Aware HIT.

A Survey of EHR Workflow Management Productivity: Process-Aware HIT

In a survey of 200 practices using an EHR workflow management system, thirty-six responded. Of these, twenty practices had pre-existing operations, so they could compare their before and after experiences. The average practice had been on an EHR WfMS for 2.7 years, had 3.76 physicians, and 17.5 total staff. Their specialties were pediatrics (55%), family medicine and internal medicine (35%), obstetrics/gynecology (5%) and multi- specialty (5%).

The survey was a self-assessment survey which covered the categories of usability, revenue, expenses, time and quality.

Usability

Practices achieved competency in five weeks. Of the practices 85% had achieved a paperless office (except for printing paper destined for the outside world or scanning incoming documents). These offices took an average of eleven weeks to achieve this paperless state. Notably, 100% of physicians used the EHR.

Revenue (and related figures)

Visits per day increased 13.5%. Exam rooms increased 34%. Charges per visit increased $17. Billing increased 30%. Denied claims decreased 61%. And revenue increased 24%.

Expenses (and related figures)

Total staff decreased from 17.5 to 16.7 fulltime equivalents. The staff to physician ratio decreased 12%. (Which is good because physicians generate revenue while staff generate expenses.) Transcription costs decreased 67%. And (in conjunction with the previously described increase in revenue) the estimated pay back period for EHR software and hardware was fifteen months.

Time and Quality

Time and quality have a very interesting relationship. Before the quality management movement, most people assumed that one must increase the amount of time spent on a product or service in order to increase its quality. (This is not necessarily true.) More to the point, patients see timeliness and convenience as an important element of the quality of care. If they do not have to wait or the encounter is shorter and allows them to get back to work on time, this is perceived as increased quality. These practices estimated a 13.5 minute decrease in patient wait, a six minute decrease in charting time, and a 16 minute decrease in overall encounter length. The amount of time to return a phone call to answer a question or to refill a prescription decreased by two hours and 45 minutes and four hours, respectively. Finally, in spite of a higher volume of shorter visits, immunizations increased by 25% (in pediatric practices) and quality review scores increased by 17%.

Take me to the next blog post in this series! EHR Productivity Survey Discussion: Process-Aware Health IT.

EHR Productivity Survey Discussion: Process-Aware HIT

Why did visit volume increase? The most likely reason is that encounter length decreased, freeing up resources to see more patients. Consider this hypothetical and simplified example. If average encounter length is 30 min- utes, then resources such as waiting and exam rooms, as well as staff are tied up during this time. However, if encounter length is reduced to 15 minutes, then resources are freed up that can be used to see another patient. Shorter visits incline toward greater visit volume.

However, the real question is “Why did the encounter length decrease?” Three reasons: decreased non-value- added EHR activities, increased parallelism among value-added EHR activities, and better coordination among EHR activities.

Value-added activities are typically those that someone will pay for. To use a manufacturing example, an auto- mobile buyer may willingly pay for a leather interior but will be loath to pay for fixing a defect that shouldn’t be there in the first place. Encounter length is determined by a combination of value-added and non-value-added EHR activities. EHR value-added activities include entering data that may be used in a future decision or making a decision that affects the welfare of the patient. Non-value-added activities include navigation from screen to screen and searching for the next person to handover the next activity in the encounter. If these non-value-added activities, and the time required to accomplish them, can be eliminated, encounter length can be reduced.

Process definitions can be used by the workflow engine to accomplish exactly this. Instead of users having to proceed through multiple clicks to search for the next data or order entry screen, the workflow can be controlled by the process definition and the user merely needs to click ‘Next’, ‘Next’, ‘Next’…. (Of course, a user always has the option of jumping out of an executing definition to manually access a different screen than the one pre- sented. Over time, with process definition refinement, this usually happens less and less.) Similarly, instead of user having to find the next user to hand off the next activity, the workflow engine can do this instead, perhaps by forwarding items into a user’s To-Do list or onto a generally available status screen of pending tasks.

Reduction of non-value-added activities can go only so far in reducing encounter length. Once the non-value- added activities are eliminated, there are still value-added activities, and these cannot be eliminated without re- ducing the overall value to the patient. However, many value-added activities can be accomplished at least par- tially in parallel. While it is true that the patient can only be one place at one time, and this imposes a certain requirement for the serial accomplishment of activities that require interaction with the patient, there are preparatory portions of these activities that can indeed be accomplished in parallel—if only the people needed to accomplish them can be informed of the need at the earliest possible moment during the encounter.

Printing and assembly of educational materials to be delivered to the patient or setting up trays of materials necessary for obtaining a specimen or administering a vaccination can be accomplished before the physician even leaves the exam room. While the physician is seeing the patient, orders can be entered and forwarded into To- Do lists or onto real-time task status screens and staff can accomplish these preparatory steps. When the physician walks out of the room, procedure trays are ready and staff members are waiting at the door to do whatever they need to do with the patient.

Now that so much is happening so quickly and at the same time, a coordination problem potentially arises, but workflow management systems have a solution for that as well. The real-time task tracking capabilities of workflow management comes into play.

The workflow engine, in executing process definitions, keeps track of what activity is waiting, how long, where and for whom. This information can be fed not only into To-Do lists, but also onto a status screen available to all EHR users. For example, in Figure 4 we can see an office status screen. We can see rooms, tech station, nurse station, exam room one and so on. In room one is Jessica Dalwart waiting for vital signs and several other tasks. Each task pending completion is tagged with a continually updated number representing the total number of minutes that have elapsed since that task was posted to the office view. These can be used to prioritize tasks when many are competing for attention. Patients are color coded according to physician; tasks are color coded according to who or what role is responsible for completing the task. So, at a glance, a nurse can see all pending nursing tasks or a physician can see all his or her patients.

The office view supports all the users in building a shared mental model of everything that needs to be done on moment-by-moment basis. In this particular case, the status screen is “hot” in that a user can select a task (such as vitals) and the EHR will take that user directly to the relevant EHR screen for accomplishing that task. When the task is completed, the workflow engine removes the task from the status screen (or the To-Do list, if that was the means by which the task was selected and accomplished).

This survey’s results do not mean that EHR workflow management systems are sufficient in and of themselves for generating such dramatic productivity improvements. Investment in a workflow management system has its largest positive effect when work teams already strive to share information, distribute decision making, and im- prove processes. (An EHR workflow management system gives them the tools to accomplish what they have already been trying to do.) Thus, successful workflow management is highly dependent on social factors (as are many other information technology initiatives).

Take me to the next blog post in this series! Workflow Management and EHR Usability: Process-Aware HIT.

Workflow Management and EHR Usability: Process-Aware HIT

EHRs have long been lauded for their potential contributions to legibility, decision support, and clinical research. They hold especially great promise for reducing medical error. However, until recently, EHR usability obstacles have not been sufficiently addressed. Typical EHR systems are not easy to use. Many physicians are small businessmen and women. Anything that slows them down may also reduce their revenue. As a business proposition, EHRs must become not just comprehensive and accurate, but usable and fast. Lack of workflow management capability is a major reason for many EHRs being difficult to use.

Usability is “the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments.” [4] However, in the case of EHR workflow management systems, usability must be construed not only relative to single users, but also with respect to the entire team of users who work together for common goals. One might rephrase this definition of usability to become the effectiveness, efficiency, and satisfaction with which teams of users achieve collections of goals in complex social environments.

Consider these major dimensions of EHR usability: naturalness, consistency, relevance, supportiveness, and flexibility [5]. Workflow management concepts provide a useful bridge from usability concepts usually applied to single users to usability applied to users in teams. (And, to pick up a thread that was introduced in the previous section, each dimension of usability can contribute in its own way to reductions in encounter length.)

Naturalness is the degree to which an application’s behavior matches task structure. In the case of workflow management, multiple task structures stretch across multiple users in multiple roles. For example, a visit to a cardiology office may involve multiple interactions among patient, nurses, technicians, and physicians. Task analysis must therefore span all of these users and roles. Creation of a process definition is an example of this kind of task analysis, and results in a machine executable (by the workflow engine) representation of task structure.

Consistency is the degree to which an application reinforces and relies on user expectations. Process definitions enforce (and therefore reinforce) consistency of user interactions with each other with respect to task goals and context. Over time, team members rely on this consistency to achieve highly automated and interleaved behavior. Consistent repetition leads to increased speed and accuracy.

Relevance is the degree to which extraneous input and output, which may confuse a user, is eliminated. Too much information can be as bad as not enough. Here, process definitions rely on user roles (related sets of ac- tivities, responsibilities, and skills) to select appropriate screens, screen contents, and interaction behavior.

Supportiveness is the degree to which enough information is provided to a user to accomplish tasks. An applica- tion can support users by contributing to the shared mental model of system state that allows users to coordinate their activities with respect to each other. For example, since a workflow management system represents and updates task status and responsibility in real time, this data can drive a display that gives all users the big picture of who is waiting for what, for how long, and who is responsible.

Flexibility is the degree to which an application can accommodate user requirements, competencies, and prefer- ences. This obviously relates back to each of the previous usability principles. Unnatural, inconsistent, irrele- vant, and unsupportive behaviors (from the perspective of a specific user, task, and context) need to be flexibly changed to become natural, consistent, relevant, and supportive. Plus, different users may require different proc- ess definitions, or shared process definitions that can be parameterized to behave differently in different user-task-contexts.

The ideal EHR (and EHR workflow management system) should make the simple easy and fast, and the com- plex possible and practical. Then the majority/minority rule applies. A majority of the time process instances are simple, easy, and fast (generating the greatest output for the least input, thereby greatly increasing productivity). In the remaining minority of the time, the productivity increase may be less, but at least there are no show stoppers!

Take me to the next blog post in this series! User-Centered, Human-Centered Process-Aware Health IT.

User-Centered, Human-Centered Process-Aware Health IT

EHR workflow management concepts mesh with research initiatives to improve EHR usability. For example, Human- Centered Distributed Information Design [6] (there applied to EHR usability issues) distinguishes four levels of distributed analysis: user, function, task, and representation, which correspond well to workflow management architectural distinctions.

Distributed user analysis can be interpreted to include allocation of tasks, relationship between roles, and task-related messaging, all of which are important workflow management concepts.

Distributed function analysis involves high-level relationships among users and system resources. From a workflow man- agement perspective, this includes who reports to who and who is allowed to accomplish what.

Distributed task analysis roughly corresponds to the creation of process definitions that in turn drive EHR behavior: What is to be accomplished by whom, in what order, and what needs to happen automatically.

Distributed representational analysis corresponds to some- thing that workflow management systems intentionally do not address. Workflow management system design tends to be agnostic about how information is displayed to, transformed, or collected from the user. The underlying workflow engine is intended to be a general purpose tool that can be used to sequentially launch whatever screen or initiate whatever behind the scenes action that the implementer of the workflow system deems most apt as part of workflow analysis and design. However, by remaining orthogonal to the choice of screen, by not mandating or hard coding, the designer/implementer is free to bring to bear the powers of representational analysis to use whatever screen and attendant representation is most appropriate.

Thus, workflow management concepts are consistent with human-centered distributed information design, an important emerging area of medical informatics research. “Task- specific, context-sensitive, and event-related displays are ba- sic elements for implementing HCC [human-centered computing] systems,” (p. 46 [6]) and they are the basic elements provided by EHR workflow management systems, too.

Much of what I wrote about in this 2003-2004 series of white papers is indeed coming into existence today. The basic idea of building workflow-centric health IT systems is indeed gaining steam. Many of my tweets during HIMSS16 are about companies embedding workflow engines in their products. In addition, we are seeing a surge of Business Process Management technology in healthcare and health IT. Terminology varies. Sometime they are called Healthcare or Care Management Systems. What they have in common is a “process-awareness” that has been mostly missing to day in recent medical informatics and health IT history. This new layer of cloud-based workflow engines addresses thorny issues of EHR and health IT usability, productivity, safety, and interoperability. Indeed, since my 7000-word, 5-part series, Achieving Task and Workflow Interoperability in Healthcare, was published in 2015, I’ve seen considerable progress. Nonetheless, I think it is useful to look back at my 2003 and 2004 series on EHR workflow management systems for seminal ideas that are only now being realized in products and driving results.

Take me to the next blog post in this series! Process-Aware Workflow Management Systems With Healthcare Characteristics: Process-Aware HIT.

Process-Aware Workflow Management Systems With Healthcare Characteristics: Process-Aware HIT

Evident throughout this article is a tension between straightforward, predictable, repetitive, high volume episodes of patient care versus more complex, less predictable, one-of- a-kind episodes, each of which is unique and therefore infrequent, but all of which taken together constitute a significant and important part of the ecology of health care. Traditional workflow management systems excel at what has been called ‘straight through processing’ (STP) in the banking and finance industries. For example, an order to sell shares in a publicly traded stock should ideally happen in a very short interval (that is, before the stock price changes materially). STP seeks to eliminate the human element that slows down stock trades, to only rely on humans for handling exceptional circumstances, and to reduce exceptional circumstances to an absolute minimum (if not altogether!). However, in health care exceptions happen all the time. Medical care is exception rich because abnormal states are, in effect, normally encountered occurrences.

Healthcare processes, and especially core patient-driven processes, are rife with exceptions—from the appointment no-show to the abnormal laboratory value to the undeniably unique history of present illness. And yet, these are in a way predictable and therefore categories and rules and workflows can be defined to facilitate execution of core clinical and administrative processes. Workflow management in health care, especially in and around the EHR, will be workflow with healthcare characteristics. While this may seem obvious, it also means that workflow management systems technology and concepts borrowed from other industries must necessarily be considerably adapted to become successful components of the next generation of electronic health records.

Take me to the next blog post in this series! The Future of EHR Workflow Management Systems: Process-Aware HIT.