Short Link: http://ehr.bz/lb
If this blog has a symbol it’s two cars, one labeled EMR (or EHR, more recently) and one labeled Workflow Management System (or Business Process Management, also more recently), speeding toward collision (see Welcome! (EHR + WfMS = EHR WfMS), the post kicking off this blog). The result, of all those flying parts magically recombined, might be an EMR or EHR Workflow Management System, which I’ve favored for years. But it also could be Process-Aware Clinical Groupware.
[Updated: Unfortunately “Clinical Groupware” has fallen out of marketing style. This is unfortunate because it’s a great description of what EHRs need to become. Groupware includes a variety of software tools for collaboration and coordination of team members, including workflow systems.]
Whatever you call this hybrid offspring, it has to solve healthcare’s version of “The BPM Problem,” expressed by John Reynolds in his blog Thoughtful Programmer informally, but insightfully, as:
“A bunch of things have to be performed by a bunch of people in the right order in the right amount of time…or all hell will break loose.
After the folks have finished — We need to know who did what and how long it took them to do it — in the hope that we can learn something useful that will help them do it better next time.”
Assuming hell breaking loose is a dramatic metaphor for mission criticality, is there any aspect of the “The BPM Problem” that *isn’t* true of many patient care processes and workflows?
I don’t think so.
Healthcare needs to solve its own version of the “The BPM Problem.” Solving it, subject to healthcare’s unique culture and constraints (“workflow with healthcare characteristics”), is an end for which much of health IT seeks a means.
Business process management (or business process management and adaptive case management, the relationship between about which there is healthy debate), is the most logical, comprehensive, internally consistent, conceptually mature–and, to me, inevitable–means to this end.
So let’s marry the functions and features of traditional EMRs and EHRs, with the human-centric origins of clinical groupware, and the modern tools of BPM and case management (an admittedly polygamous metaphor) to create:
- well understood,
- consistently executed,
- adaptively resilient,
- and systematically improvable
healthcare processes and workflows.
Hence, the title of this post:
EMRs and EHRs Need to Solve “The BPM Problem”: Why Not Use BPM to Help Do So?
What is (Traditional) Business Process Management Anyway?
Quoting from the incontrovertible and therefore irrefutable Wikipedia:
“Business process management activities can be grouped into five categories: design, modeling, execution, monitoring, and optimization.” (Wikipedia)
-
Process Design “encompasses both the identification of existing processes and the design of ‘to-be’ processes. Areas of focus include representation of the process flow, the actors within it, alerts and notifications, escalations, Standard Operating Procedures, Service Level Agreements, and task hand-over mechanisms.” (Wikipedia)
- Healthcare specific example: Design of ambulatory patient encounter workflows by editing BPM process definitions.
-
Process Modeling “takes the theoretical design[,] introduces combinations of variables…[and] involves running ‘what-if analysis’ on the processes.” (Wikipedia)
- Healthcare specific example: Importing a patient encounter process model, generated by step 4, into a discrete event simulation program, a popular industrial engineering tool (here’s a short discussion in a previous post, ought a do an entire future post on the topic, though). Candidate changes to patient encounter process definitions can be simulated, tested, and results predicted *before* changes are made to process definition in actual use.
-
Process Execution “software has been developed that enables the full business process (as developed in the process design activity to be defined in a computer language which can be directly executed by the computer. The system will either use services in connected applications to perform business operations…or, when a step is too complex to automate, will ask for human input. Compared to either of the previous approaches, directly executing a process definition can be more straightforward and therefore easier to improve. However, automating a process definition requires flexible and comprehensive infrastructure, which typically rules out implementing these systems in a legacy IT environment.” (Wikipedia)
- Healthcare specific example: Execution of previously mentioned process definitions of patient encounter workflow by a workflow engine.
-
Process Monitoring “encompasses the tracking of individual processes, so that information on their state can be easily seen, and statistics on the performance of one or more processes can be provided….In addition, this information can be used to work with customers and suppliers to improve their connected processes…These measures tend to fit into three categories: cycle time, defect rate and productivity….The degree of monitoring depends on what information the business wants to evaluate and analyze and how business wants it to be monitored, in real-time, near real-time or ad-hoc. Here, business activity monitoring (BAM) extends and expands the monitoring tools in generally provided by BPMS….Process mining is a collection of methods and tools related to process monitoring. The aim of process mining is to analyze event logs extracted through process monitoring and to compare them with an a priori process model. Process mining allows process analysts to detect discrepancies between the actual process execution and the a priori model as well as to analyze bottlenecks.” (Wikipedia)
- Healthcare specific example: Real-time tracking of patient encounter tasks status via BAM; generation of process models from EHR workflow logs–see step 2, also future post.
-
Process Optimization “includes retrieving process performance information from modeling or monitoring phase; identifying the potential or actual bottlenecks and the potential opportunities for cost savings or other improvements; and then, applying those enhancements in the design of the process. Overall, this creates greater business value.” (Wikipedia)
- Healthcare specific example: Using a process definition editor to improve cycle time (encounter length), clinical performance (consistent accomplishment of clinical tasks), practice productivity (cost, revenue, profit), and user experience (usability).
“There are four critical components of a BPM Suite:
-
Process Engine – “a robust platform for modeling and executing process-based applications, including business rules.”
- Healthcare specific example: The workflow engine embedded in the an EMR Workflow System.
-
Business Analytics — “enable managers to identify business issues, trends, and opportunities with reports and dashboards and react accordingly.”
- Healthcare specific example: Two EMR BPM extensions developed for which a paper has been accepted for presentation at an upcoming medical informatics conference–more details later.
-
Content Management — “provides a system for storing and securing electronic documents, images, and other files.”
- Healthcare specific example: Much EHR is structured patient data created through a point-and-click user interface or mapped from incoming HL7 and XML message files. However, some data is in the form of so-called attachments, such as scanned or other viewable files (BLOBs) either because it arrives as such or it is necessarily generated and then archived.
-
Collaboration Tools — “remove intra- and interdepartmental communication barriers through discussion forums, dynamic workspaces, and message boards.”
- Healthcare specific example: an EMR Workflow System coordinates tasks among the patient care team in a pediatric or primary care office, relying on a combination of workflow engine-driven task forwarding and task status visibility, an example of adaptive case management.
In a “learn to walk before one can run” sense, EMRs, EHRs, and clinical groupware cannot effect a BPM-style life cycle of systematic process improvement without, at the very least, a process engine (AKA workflow engine) executing a process model (AKA process definitions, workflow definitions). A process engine executing a process model is necessary, though not sufficient, to cycle through systematic design, modeling, execution, monitoring, and optimization of healthcare processes. Lack of a process engines, executing declarative representations of process knowledge, is the most immediate pressing issue to be addressed, if present-day clinical information systems are to evolve into full-fledged healthcare BPM “process improvement process” systems (another phrase from Wikipedia’s description of BPM).
What’s New (Untraditional) in BPM That’s Relevant to HIT and Clinical Groupware?
A lot! From open-source BPM to SaaS and BPM in the cloud to adaptive case management and social BPM to process mining and discovery to business intelligence and complex event processing, and more, BPM, with much healthy debate, is dashing into the future. Looming changes in the BPM industry even prompt poetry (So. Farewell then BPM; there are no poems yet, of which I am aware, about traditional EMRs). Whether or not the initials B, P, and M stick around, “The BPM Problem” won’t be going away. And process-awareness, in one guise or another, will also likely stick around for a while, as it is an important ingredient in any successors to BPM. I sort of like the old fashioned term “groupware,” that Johnson-Lenz and Johnson-Lenz coined thirty years ago. But whatever you call it, healthcare needs it.
The HIT and BPM industries are arcing toward a productive, slow motion, collision. The result will be what I used to call an EMR or EHR workflow (management) system but now, going with the flow, call process-aware clinical groupware (a workflow system is a important form of groupware; BPM systems are examples of process-aware information systems). Eventually…who knows? (“A rose by any other name would smell as sweet,” how’s that for a touch of class?)
Process-aware clinical groupware will be more usable than traditional EMRs / EHRs. Workflow management systems, workflow systems, business process management systems and suites are obviously relevant to workflow. Less obvious, but no less profound, process-aware information systems are relevant to usability, lack of which is a contentiously debated impediment to EMR / EHR adoption. For my two cents, see my comments on workflow and usability, shallow versus deep usability, contextual usability and process awareness, skepticism about EMR usability checklists, interruption theory, aviation human factors and EMR workflow systems, and the relevance of Fitts and Hicks Laws to point-and-click EMR user interfaces).
Wide Spread EMR / EHR Adoption Requires Process-Aware Information Systems
The key to EMR / EHR adoption is productivity.
The key to productivity is usability.
The key to usability is workflow.
The key to workflow is a process model, a declarative representation of process knowledge
- with sufficient detail to be executed for repetitious, predictable processes (“traditional” BPM: engines executing models),
- or for unpredictable processes that cannot be represented in a detailed process model, representation of goal and task state, plus context, resources, and automation to make tasks visible, trackable, ownable, escalatable, and accomplishable (the newer “untraditional” BPM: creative, ad-hoc, human-centric exception handling),
- and means to shift back and forth, necessarily or strategically, between the former and the latter, in unpredictably predictable environments.
PS Follow me on Twitter at .