Short Link: http://j.mp/avq1k3
(Text in blue is from the original HIMSS proceedings paper. My comments about that paper are in black.)
This post’s title does sound a bit like a press release issued ten years after the fact. I could have waited and published this on April 11th, 2010, because then will be ten years to the day since our presentation at the 2000 HIMSS conference, about an EMR workflow system for pediatric workgroups. However, with the HIMSS conference occurring here in Atlanta, March 1-4, I think more people will read this if I publish it now.
So…
*Almost* ten years ago, representatives from two pediatric practices (Cooper Pediatrics and McDonough Pediatrics, near Atlanta) and I presented Session 48 “The CPR in Eleven Paperless Physicians’ Offices: Performance, Processes, and Results” on April 11, 2000, at the Dallas HIMSS conference (CPR stood for Computerized Patient Record). Ten of the eleven practices were pediatric; one was family medicine. The proceedings paper is still on the HIMSS website (and archived here).
One forgets that in 2000 less than one percent of physician offices had EMRs, let alone were paperless (except for scanning what came in from the world and what had to be printed back at it). However, that was not what made our presentation so remarkable. In three ways, it prefigured developments that are beginning to affect collective thinking of the HIT industry today:
- Workflow management systems (business process management today)
- Computer-supported collaborative work (groupware and workflow systems today)
- Componentized EMR architecture (software modules/plugins and service-oriented architecture today)
Session 48 (sounds a bit X-Files-ish) was really two presentations, because EMR workflow systems are two software applications (EMR plus workflow groupware: Tastes Great, Less Filling! Two great tastes that taste great together! It’s a dessert topping, and a floor wax! Sorry!). The 2000 title reflected only the EMR part of the presentation. In this post I resurrect material not explicitly referred to in the title: EMR workflow automation, workgroup coordination, and componentized modular EMR architecture.
EMR Workflow
From our proceedings paper (in blue, I’ve added bold emphases for purposes of this post):
Uncommon are instances of CPRs integrated with workflow systems that automate manual processes and distribute information within a workgroup.
A workflow system is a complex, dynamic assemblage of:
- Tasks—These are activities that must be completed in order to achieve a business goal. The CPR in this study has a task-based orientation.
- Actors—Tasks are performed in a specific order by specific actors (that is, receptionists, nurses, physicians) based on business roles.
- Roles—Roles are defined independent of the actors or the processes that fill that role. For example, the CPR defines a nurse’s role as different from a physician’s role in the ambulatory care office.
- Processes—Processes are the sequences of tasks to be performed based on business conditions. Workflow automation may mirror existing processes or call for redesigning processes to eliminate redundancies and bottlenecks, and to facilitate communication.
BUSINESS PROCESSES
Workflow Automation
The workflow-enabled CPR reduces the amount of time required to retrieve information, document care, order labs and procedures, and communicate among clinical and non-clinical staff by two important mechanisms: smart sequences and simultaneous communication. Smart sequences are based on who you are (physician, nurse), where you are (exam room, tech station), and “when” you are (that is, what has been accomplished, such as vital signs, and what remains to be done, such as physical exam), and drive the sequence of user interface screens. [CW: see discussion of simultaneous communication in upcoming section on clinical groupware.]
The CPR and workflow system allows instant communication within the office and simultaneous access of a medical record by various people in the office. When the healthcare provider orders a lab or procedure, the nurse is notified automatically and immediately. The physician need not bother with or waste productive time trying to locate a nurse or turning on a certain light. While the physician is still with the patient, the nurse can prepare for the procedure. In the case of vaccinations, the dosage, manufacturer, lot number, and the intended site of administration can be documented before even entering the exam room and while the physician is still charting the exam. The nurse can also enter the results of labs and the information will appear in the exam room for the physician, thus preventing interruptions.
In an earlier study of changes in office patient volume and staffing levels, volume was observed to grow at five times the rate of growth in staff. Since patient volume correlates positively with revenue, and staffing level correlates positively with expense, there is good evidence that the workflow-enabled CPR increased profitability by allowing medical practices to see more patients with a less than corresponding increase in human labor.
According to the IOM, the greatest motivation for practitioners to use CPR’s would be evidence that CPRs can help to improve the quality of patient care and to reduce administrative burdens. This study yields preliminary evidence that a computer-based patient record combined with a workflow management system can yield a paperless office within two weeks or less after installation and that paperless offices indeed can produce immediate improvements in time savings, profitability, and staff productivity.
Clinical Groupware
I’ll address the relationship between clinical groupware and EMR workflow systems in future posts, but for now refer to the following descriptions of groupware:
“The term *groupware* was coined by Peter and Trudy Johnson-Lenz…as follows: ‘GROUPWARE= intentional GROUP processes and procedures to achieve specific purposes + softWARE tools designed to support and facilitate the group’s work’ (1982)” (p. 1, Baecker, Readings in Groupware and Computer-Supported Cooperative Work: Assisting Human-Human Collaboration, Ronald M. Baecker (Editor), 882 pages, Morgan Kaufmann, 1992.)
And
“Groupware is distinguished from normal software by the basic assumption it makes: groupware makes the user aware that he is part of a group, while most other software seeks to hide and protect users from each other…Groupware…is software that accentuates the multiple user environment, coordinating and orchestrating things so that users can ‘see’ each other, yet do not conflict with each other.” (Lynch, Snyder, and Vogel, 1990, quoted in in Readings in Groupware and Computer-Supported Cooperative Work: Assisting Human-Human Collaboration, Ronald M. Baecker (Editor), 882 pages, Morgan Kaufmann, 1992.)
From our proceedings paper:
Simultaneous communication is based on posting tasks to be done in a central location (a CPR screen that provides an office “big picture”), which allows everyone to know what needs to be done and act accordingly.
And
At the heart of the workflow system is the “big picture” screen that tracks patients throughout the visit. From this screen, configured to the office specifications of each site, everyone can see where each patient is, which provider the patient is waiting for, what service the patient is waiting for, and finally, how many minutes the patient has been waiting. And the observer can easily take charge of a pending task simply by touching its representation on the “big picture” screen.
[click slide to animate]
From PowerPoint slide notes:
“A workflow-enabled CPR should show everyone the runways and holding patterns of patients as they wait for service. On the left of each room is the name of a patient. On the right are tasks (vital signs, examination…) waiting to be done. Colors correspond to who is responsible for a patient or task. At number indicates the minutes the patient has been waiting. Touching a patient or task color bar displays the appropriate screen for accomplishing the task.“
EncounterPRO’s big picture Office View is called a “radar view” by usability engineers, for obvious reasons.
Component Architecture
Just as I started the previous section on clinical groupware with a quote, I’ll do so again. Speaking of groupware….
“Ideally these coordination tools should be implemented as reusable software modules that may not stand alone, but can be used by developers as components of other domain-specific products.” (p. 8, Greif, Computer-Supported Cooperative Work: A Book of Readings, Irene Greif (Editor), 793 pages, Morgan Kaufmann, 1988.
The best way to present our own comments on the importance of modular and extensible EMR component architecture is to highlight two slides along with their slide handout notes (still available on the HIMSS website and archived here). They refer to Microsoft’s COM objects, not today’s Web services, .NET components, plugins, and so on, so I’ve supplied an updated translation. These slides are also animated, so be sure to click on them.
(I admire the WordPress plugin system that allows me to extend my blog to publish these Flash videos based on ten-year-old PowerPoint slides. The average WordPress blog has five plugins. This one has fifteen. Works great. It’s similar to the point I’m making about extensible EMRs–ironic!)
Two slides from our presentation (animated):
From PowerPoint slide notes:
“Allow developers to customize the workflow-enabled CPR, since one size does not fit all. Here Microsoft’s Component Object Model (COM) is critical, since it allows a developer or VAR to add their own screens as options for selection by the workflow engine.”
Updated translation:
“Allow users and developers to customize EMR workflow groupware systems, since one size does not fit all. Here Microsoft’s .NET, Web services, plugins, and other modular means to extend EMR functionality are critical, since they allow a user, developer or reseller to add their own screens and functionality as options for selection by the workflow engine.”
From PowerPoint slide notes:
“This slide is for the programmers in the audience (please explain it to the non-programmers). Decide to work with a workflow-enabled CPR that relies on a COM architecture possessing a set of publicly accessible APIs, so you can assemble a best-of-breed component solution and customize to your users or market.”
Updated translation:
“This slide is for the programmers in the audience (please explain it to the non-programmers). Decide to work with an EMR workflow groupware system that relies on a modern modular architecture possessing a set of publicly accessible APIs (application programming interfaces, check out the WordPress plugin API), so you can assemble a component solution customized to your users and market.”
After our 2000 presentation we continued to emphasize the relationship between clinical group workflow requirements and modular componentized EMR platforms:
“Workflow management systems are usually highly componentized, in that the workflow engine does not need to know much about the applications that it executes (just the prerequisite circumstances for execution and what context information to supply). This componentization provides a route … to introduce new EHR functions or ways of accomplishing them (such as a new decision support module or data display) into work-a-day … settings.” (“EHR Workflow Management Systems: Essentials, History, Healthcare”, TEPR Conference Proceedings, 2004, Fort Lauderdale)
The EncounterPRO Pediatric EMR Workflow System did not start out as single function system, as many other EMRs did. It wasn’t a prescribing system or a vaccine tracking system or a practice management system (OK, that’s usually two functions: scheduling plus billing). EncounterPRO was and is a workflow system and workflow systems coordinate work. EncounterPRO coordinates system-to-system, system-to-user, user-to-system, and user-to-user interactions. To do so, EncounterPRO coordinates modules, components, users, and roles to manage an ambulatory patient encounter for a team of physicians and clinical staff. EncounterPRO’s workflow engine and process definitions on one hand, and componentized modular architecture on the other, are two sides of the same EMR workflow groupware coin.
Conclusion
OK, (just in case you skipped directly to this conclusion) lets deconstruct this post’s subtitle, ”Modular Pediatric EMR Workflow Groupware”:
-
“Modular”–A
module is “a self-contained component (unit or item) that is used in combination with other components.” EncounterPRO’s modular components are its optional screens and screenless activities that can be combined into a network of task interdependencies. This network is automatically executed by a workflow engine. Third-party components and functionality can be added into this mix. Task statuses is displayed and updated in a group-facing display called the Office View.
-
-
“EMR”–Did I mention that EncounterPRO is not *just* a workflow-oriented groupware system, but an EMR too?
-
“
Workflow“–”The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.” In the EncounterPRO EHR Workflow Management System (used to create specialty-specific EMR workflow systems), these procedural rules are called “workplans,” although they are more generally called “workflow definitions” or “process definitions” in the workflow management/business process management industry.
-
“Groupware”–”Intentional GROUP processes and procedures to achieve specific purposes + softWARE tools designed to support and facilitate the group’s work.” The original Johnson-Lenz definition is a good one.
-
“GROUP” = pediatric staff.
-
“specific purposes” = pediatric care.
-
“intentional…processes” = workflows intentionally triggered to achieve pediatric goals.
-
“intentional…procedures” = workflows intentionally designed to achieve pediatric goals.
-
“softWARE tools” = pediatric EMR workflow groupware.
-
“designed to support…the group’s work” = a “radar view” supports a shared mental model, updated in real time, of task status among pediatric staff. EncounterPRO’s Office View “accentuates the multiple user environment, coordinating and orchestrating things so that users can ‘see’ each other, yet do not conflict with each other.” (Lynch, Snyder, and Vogel, 1990, quoted in in
Readings in Groupware and Computer-Supported Cooperative Work: Assisting Human-Human Collaboration, Ronald M. Baecker (Editor), 882 pages, Morgan Kaufmann, 1992.)
-
“designed to…facilitate the group’s work” = visual representations of task status are “hot”; selecting a task brings up screen to accomplish it; tasks appear without need for user attention due to automatically executed workflow definitions; users trigger optional workflows that cause more tasks to appear on user and role worklists and in the Office View.
Terminology has evolved: workflow management systems, business process management, computer-supported cooperative work, clinical groupware, components, modules, plugins, CPRs, EMRs, and EHRs. The technologies manifesting these ideas have evolved greatly (for example, the Web did not yet exist when “groupware” was first coined, defined, and discussed). But the ideas themselves have been around for decades (well, “pediatric EMR” a decade and a half). I’d like to think our presentation and paper “The CPR in Eleven Paperless Physicians’ Offices: Performance, Processes, and Results” on April 11, 2000, at the Dallas HIMSS conference is a bit of a landmark.
However, I am hardly a disinterested observer. So you be the judge.
