Healthcare Business Process Management, Adaptive Case Management & Process-Aware EHR & Health IT Systems

Health IT

Workflow Complexity: Complicated data and simple workflow is complicated. Simple data and complicated workflow is complicated. Healthcare's complicated data and complicated workflow is hypercomplicated.

No Cost Competition: In other industries, companies are forced to adopt technology to optimize workflow to minimize cost while maximizing flexibility.

Regulatory Environment: EHR and HIT vendors are stretched thin addressing Meaningful Use requirements.

Screens vs. Workflow: It’s easier to appreciate EHR screens (layout of data and controls over space) than workflow functionality (sequences of events over time).

Threat to Revenue Streams: Switching to new platforms is risky and threatens current revenue streams.

Billing Over Clinical Emphasis: As long as the right codes are generated to maximize revenue, nothing else matters.

Skeuomorphism: Misguided attempts to model EHR user interfaces on paper medical record forms.

Workflow Stereotypes: Workflow management systems and business process management once emphasized automating human users out of processes. Not true now!

Not Invented Here-ism: Most academic and commercial BPM activity occurs outside the US.

Paradigm Shifts: You stick with a paradigm unless you’re forced to change. Health IT picked a document-based, instead of workflow-based, paradigm.

*Top Ten Reasons EHR-BPM Tech Is Not (Yet) Widely Deployed in Healthcare

Blog Posts

Smart Health IT Requires BPM Tech

Over on the EMR & EHR blog @TechGuy titled a post "Is Your EHR Stupid?" I waited a day or two, because I assumed there'd big pile-on of comments, and I was looking forward to reading them. But not a peep. Crickets!

So I wrote my first comment. And then my second comment. And then my third, for a total of almost 2,000 words. Hey, I was asked a question! That's like four times the size of an average blog post. Anyway, after investing all that work, I thought I'd repost my comments here as a blog post.

Here's a roadmap:

  • In my first comment, I equate "smart" with "intelligent" and argue that BPM's workflow engines (AKA process or orchestration engines) are the closest thing we have today to a "brain" we can embed in EHR and health IT systems.
  • In my second comment, I elaborate about physicians's natural and understandable resistance to workflow-oblivious EHRs and health IT systems
  • In my third comment, I talk about screenflow, frozen workflow, Meaningful Use, speech recognition and natural language processing workflow, and mobile and cloud workflow.

 

Adapted from comment #1:

Question: Do We Need Smarter Users or Smarter User Interfaces?

Answer: Smarter User Interfaces.

Consider the distinction between intuitable EMRs (EMRs that are “figure-outable” by their users) versus intuitive EMRs (EMRs that figure out their users and do something useful with that insight). Intuitable usability corresponds to what I call shallow usability. It’s the “surface” or skin of an EMR.

In contrast, intuitive usability (used “correctly”) corresponds to what I call deep usability. It is about how all the components and processes deep down behind the user interface actively work together, to perceive user context and intentions, reason and problem solve, and then proactively anticipate user needs and wants. Deep usability is like having the hyper-competent operating room nurse handing you the right data review or order entry screen, with the right data and options, at the right moment in your workflow.

To perceive, reason, and act (let alone learn) EMRs need at least a rudimentary “brain.” When many folks think of medical artificial intelligence, they think of medical expert systems or natural language processing systems (rule-based, connectionist, or statistical). However, the most practical candidate “brain” today, with which to improve usability by improving workflow, is the modern process-aware (and context-aware) business process management (BPM) engine (AKA workflow or process engine).

Intuitive EMRs need to represent user goals and tasks and execute a loop of event perception, reasoning, and helpful action. BPM process definitions represent goals and tasks. During definition execution, goal and task states are tracked (available to start, started, completed, postponed, cancelled, referred, executed, etc) and used to coordinate system-to-system, user-to-system, system-to-user, and user-to-user activity.

BPM engines “perceive” by reacting to not just user-initiated events, but potentially other environmental events as well, an example of complex event processing. For example, a patient entering or leaving a patient class or category, going on or off a clinical protocol or regime, moving into or out of compliance, measuring or needing to measure a clinical value, or a clinical value becoming controlled or not controlled, are all complex events that can and often should trigger automated workflow.

Smart EHRs are adaptive, responsive, proactive, and capable of autonomous action.

  • “Adaptive systems: these learn their user’s preferences and adjust accordingly….
  • Responsive systems: these anticipate the user’s needs in a changing environment.
  • Proactive systems: these are goal-oriented, capable of taking the initiative, rather than just reacting to the environment.
  • Autonomous systems: these can act independently, without human intervention.”

http://ubiquity.acm.org/article.cfm?id=764011

Learn, anticipate, goal-oriented, initiative, independent…none of these describe the behavior of today’s typical EMR towards its users. As a consequence physicians must compensate with a torrent of clicks (so-called “clickorrhea”) to push and pull these EMRs through what should be simple patient encounters.

What “drives” this smart behavior? An executable process model. In older terminology, a workflow, or process, engine, executes a collection of workflow, or process, definitions, relying on user input and context (the who, what, why, when, where, and how) to select and control definition execution. If the engine encounters inputs for which there is no model, then fall back on general purpose adaptive case management techniques for tracking goals and tasks, making them visible and actionable by physician users. Traditional BPM technology automates the predictably routine. More recent adaptive case management supports dealing with unpredictable exceptions—the high value-added knowledge work that diagnoses and treats the complicated cases.

Usability can’t be “added” to EMR. It has to inform and influence the very first design decisions. And there are no more fundamental early design decisions than what paradigm to adopt and platform to use.

No matter how “intuitable,” EMRs without executable process models (necessary to perceive, reason, and act, and later systematically improve), cannot become fully active and helpful members of the patient care team. Wrong paradigm. Wrong platform.

A truly smart EHR, on the other hand, has a brain, variously called a BPM, workflow, or process engine. This is the necessary platform for delivering context-aware intelligent user interfaces and user experience to the point of care. Right paradigm. Right platform.

In the spirit of advice from my Speech teacher about effectively and efficiently beating dead horses (”Tell them what you’re going to tell them. Tell them. Tell them what you told them.”)

Question:

Do We Need Smarter Users or Smarter User Interfaces?

Answer: Smarter User Interfaces.

Adapted from comment #2:

The workflow-usability connection, or in this case, disconnection, is at the technological heart of what’s wrong with many EHRs today. Most EHRs are, essentially, structured-document management systems. All the bits and pieces of the medical document are stored in rows and columns of databases. And this is fine, as far as it goes.

However, without *also* structured workflows, amenable to execution by workflow engines (also called process engines or orchestration engines in today’s business process management suites), physicians are forced to become workflow engines themselves. That’s what all the clicking is, the clicking that they hate. It’s the navigation from screen-to-screen and the manual triggering of events that should really happen automatically, without requiring physician attention.

Ironically, and I think somewhat cruelly, physicians are sometimes characterized as Luddites for resisting modern, more efficient, technology. This is wrong in two ways. First, the Luddites attacked automated looms (precursors to our modern digital computers since they executed programs stored on punched cards) because they were *too* efficient. They eliminated the need for human labor.

In contrast to those automated looms, and most modern technology today, many EHRs actually create *more* work for physicians (and, unlike the Luddites, they don’t want it). So that particular aspect of the physician/Luddite analogy is completely wrong. Second, Luddites had nothing against modern technology. They were angry and frustrated with their working conditions, such as they were.

That part of the analogy holds up. Much health technology, even while it improves healthcare for patients, isn’t improving the lives of physicians. Until this mismatch between the goals and consequences of EHR technology is addressed and resolved, we will continue to see finger-pointing about who and what is to blame for slow adoption of EHR technology. Speech recognition and natural language processing will be part of that resolution, but it won’t be all of it. That is going to require the embedding of more sophisticated workflow automation into more EHRs.

Adapted from comment #3:

The single most essential characteristic of “workflow” is task sequence. What tasks? What sequence? Task sequence varies greatly across who’s performing the tasks, where the tasks are performed, how the tasks are performed, what the tasks are, and why they are being performed (that’s context, and context drives workflow). By and large, tasks correspond to screens, or subsections of screens, in EHRs. That said, screenless tasks exist. In fact, one way to make an EHR smarter is to turn screen tasks that require user interaction into screenless tasks happening automatically.

But screenflow is a good place to start. Here, the user is the expert. He or she knows what they need to do to do their job and in what order. But, while the user knows best, they don’t know everything. That’s why flexible, user-customizable workflow is so important. Later, after they’ve used an EHR for a while, they need to be able to modify workflows without requiring a trip back to the Java or C# programmer. If that happens, it takes forever, it introduces bugs, the software needs to be redeployed, users need be retrained, etc.

That is the saving grace of modern workflow technology, also called workflow management systems or business process management systems or suites. There’s a workflow engine executing process definitions (turning manual screen-oriented steps into screenless automatic steps). The process definitions can be examined graphically, much like a decision chart, and then edited by someone who isn’t a programmer. This human editor of workflow may be a clinical analyst, or maybe even an ambitious and precocious user, who, after all, knows their own workflow better than anyone else.

Use the Litmus Test for Frozen Workflow. Ask to see a demo. Ask them to pull up some sort of editor and to edit a representation of that workflow. Ask to see the demo again. The workflow behavior should change in the way that one would predict, assuming there is a workflow engine to execute the just edited process definition.

It’s tempting to imagine an alternate history of Meaningful Use, one in which MU features and functionality were implemented on structured-workflow management systems instead of human labor-intensive structured-document management systems. Many screens could be created and edited by non-programmers. Then the workflows could be edited and reedited until users were happy with them, instead of the situation now, in which is workflow is the biggest Meaningful Use complaint (my subjective impression, others may disagree).

Speech recognition and natural language processing technology is a special workflow case. The advantage of this tech is not just that speaking is faster than clicking (not always true, by the way), but that SR/NLP tech typically relies on more sophisticated workflow technology to weave it into point-of-care workflow. Early on this had to be true because layers of workflow were required to catch and correct speech recognition errors.

Now that SR is so good, this workflow technology uses context (the who-what-why-when-where-and-how of what users says or even, heaven forbid, types) to automatically drive workflows. It turns tasks that otherwise require human intervention into tasks executed automatically by a workflow engine.

Right now, speech recognition and natural language processing is viewed an adjunct and value add-on to EHRs, to make them more usable and useful. However, in the not too distant future, as SR/NLP platforms add more-and-more EHR-like functionality, we’re going to seen some very interesting competition: “Don’t buy a clunky EHR when you can have a Meaningful Use certified SR/NLP smartphone that sings!”

But speech/language/workflow tech isn’t the only game in town. Much of the attraction of smartphones and tablets to physicians is that they appear to have much simpler workflows than EHRs. Part of this comparison is an illusion, but part of it is becoming real too. There’s often a direct correspondence between context, app, and workflow. If you want to do one thing, quickly, and that app is on your home screen, and that app has a two or three-step non-branching workflow: fast and easy!

However, mobile apps are “sandboxed” for security reasons, preventing them from easily sharing clinical context. So, while workflow within an app is simple, workflow across apps, in any attempt to comprehensively replicate EHR functionality, gets you right back to where you were, if not worse, with traditional EHRs, at least with respect to workflow usability.

While limitations on secure sharing of clinical data and context across solo apps are being addressed by various cloud-based technologies and platforms, many of these systems also rely on (wait for it…) workflow engines in the cloud. At the recent HIMSS conference I saw some let-us-mobilize-your-legacy-application-without-much-programming-required vendors in the exhibit hall. I suspect that workflow engines play important roles in their Model-Driven Composition Environments (that’s a Gartner term for codeless, or nocode programming).

So, regarding existing EHRs, apply the Litmus Test. Regarding the near future, language technology and workflow technology are traveling into healthcare along with the SMAC techs (Social, Mobile, Analytics, Cloud) in all kinds of interesting and promising ways.

In the short term, what to do? Do a Google search of “workflow” and “EHR” or “EMR”. Check out some of the EHR tag lines. If they emphasis great workflow, well, maybe there’s a correlation with actually having great workflow. (But apply the Litmus Test of Frozen Workflow: trust but verify!)

 

Add comment


Security code
Refresh

My Next Speaking Engagement!

bpm-summit-banner

BPM Solutions

Process Orchestration Engine (AKA workflow engine) to drive the progression of work in structured and unstructured processes or cases

Model-Driven Composition environment for designing processes and their supporting activities and process artifacts

Content Interaction Management supporting e progression of work, especially cases, based on changes in the content itself (documents, images and audio)

Human Interaction Management enables people to naturally interact with processes they're involved in

Connected Processes and Resources they control, such as people, systems, data, event streams, goals and key performance indicators (KPIs)

Continuous Analytics monitor activity progress, and analyze activities and changes in and around processes

On-Demand Analytics to provide decision support using predictive analytics and optimization

Business Rule Management systems guide and implement process agility and ensure compliance

Management and Administration monitor and adjust technical aspects of BPM platform

Process Component Registry/Repository for process component leverage and reuse

Cloud-Based Deployment of about features and functions across desktop platforms and mobile devices

Social Media Compatible external and/or similar internal activity streams integrated with workflows

*Adapted from Gartner

Login Form