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

AppianWorld 2012 Trip Report, Just In Time For AppianWorld 2013 (Plus Ten Questions)

Almost a year ago I attended AppianWorld 2012. I love this conference (been more than once) and frequently tweet about Appian related news and blog posts (and retweet @Appian) especially about business process management in healthcare. I wrote the following trip report (starting below, after my ten questions for Appian) but didn’t publish it at the time. I think the conference was so good and gave me so much to think about that the draft trip report was quite a sprawl of interesting ideas. I kept thinking I needed to get back to it and reorganize, polish and publish. I finally did. On the morning of the beginning of the next AppianWorld conference, AppianWorld 2013!

Why do I go to AppianWorld? It’s a hometown favorite (I can walk to this year’s conference in the Reagan International Trade Center). Appian BPM is an excellent concrete example of how mobile, cloud, and workflow automation are coming together. There are some excellent Appian healthcare BPM case studies. Lot’s happened since last year's conference, including announcement of Appian’s partnership with Quest Diagnostics at the HIMSS conference (here’s my HIMSS conference trip report).

I’ve interviewed a lot of interesting people on my personal blog at I even “interviewed” a website. This year I think I’ll interview AppianWorld 2013. I’ll post my ten questions below. (After them I post my original, but finally published AppianWorld 2012 report.) It’d be great if someone from Appian were to take a stab at answering some or all of my questions. Most of my ten questions could apply to any BPM vendor venturing into the healthcare space.

Thank you for (tentatively) agreeing to this interview!

1. Let’s start of with your recently announced partnership with Quest Diagnostics. It made a splash at HIMSS, enough so I created a POW!HIT! Profile for Quest. (POW!HIT! stands for People and Organizations improving Workflow with Health Information Technology.)

Tell us about what each of you bring to the partnership and what you intend to accomplish together.

2. What is Business Process Management? What is an Intelligent Business Process Management Suite? How are they relevant to issues facing healthcare today?

The Appian combines a number of technologies from which healthcare can benefit, including Social, Mobile, Analytics, and Cloud (SMAC). Let’s explore these in the next several questions…

3. Let’s start with the Cloud. Essential to any BPM system is an “engine” that executes, or enacts, user-to-user, user-to-application, and application-application workflows and processes. And what are advantages of putting this workflow engine in the cloud?

4. How does Appian add Mobile technology to this mix? How can this help healthcare?

5. What is “WorkSocial”? How does Appian deliver it? How can healthcare benefit?

6. Healthcare conferences, such as the recent HIMSS conference, have lots of presentations and exhibiting vendors focusing on Clinical & Business Intelligence. Tell us about Appian’s iBPMS’s Analytics. Are there analytics, available in BPM software but might not be available in non-BPM software, of particular interest to healthcare audiences?

7. Considered separately, Social, Mobile, Analytics, and Cloud technology all seem poised to diffuse throughout healthcare. However, Appian integrates SMAC technologies into a single iBPMS platform. Tell us how this combination works together and how its combination benefits to healthcare.

8. Some of healthcare’s workflows are frequent and routine. Some are infrequent and highly variable, perhaps even one-of-a-kind. How does Appian support this spectrum from predictable to unpredictable workflows?

9. Do you have any other partners and case studies in the healthcare space you could tell us about or to which you could direct our attention?

10. Might we see your booth at the HIMSS conference next year?

Fantastic! Thank you. I’m a fan of business process management and adaptive case management in healthcare. Located, as you and I are, in the DMV region (District-Maryland-Virginia), I’m proud of such a local success story as Appian. And I’m particularly pleased to see your forays into healthcare.

I’ve been to several of your AppianWorld conferences. And I look forward to attending Appian World 2013, in downtown Washington DC!



Finally, disproving "Old news is no news!", here's my AppianWorld 2012 trip report…

Last month I attended Appian World 2012, the BPM vendor’s annual conference. It was a fantastic conference, especially for someone, like myself, interested in application of business process management technology in healthcare. As Ben Farrell, Director of Corporate Communications at Appian said on stage, “Interest in BPM in healthcare is exploding.” So it was an especially exciting time to attend.

[CW: Ben's right!]

Several disclaimers: I am not an employee, customer, or partner of Appian. But I do cheerlead for hometown accomplishments. Appian is part of a remarkable technological and entrepreneurial ascendancy of a DC/VA/MD (“DMV”) metroplex that continually impresses. While I am a proponent of workflow management systems and BPM software in healthcare in general, Appian is an excellent “reference implementation” to which to refer when making these general points.

Second: this post, as most posts on this blog, is heavily influence by the idea that there is a remarkably complementary relationship between BPM technology strengths and EHR/health IT problems. Combining these technologies just makes so much sense. Anyone who reads my blog, or follows my tweets, understands this “broken record” is my brand. If you’re new here, well, you are forewarned.

Third: There’s more than a little editorializing about the sad state of workflow automation in healthcare. The editorializing comes from me, not the Appian presentations. In fact, this "trip report" is more of an admiring reaction to Appian's BPM platform and its potential uses in healthcare, than it is a true trip report.

I loved that kickoff slide:

  • The world’s best way to organize work.
    • Ease of use.
    • Universal participation.

“The world’s best way to organize work,” “Ease of Use,” and “Universal Participation.” Anyone in the EHR and health IT industry must be struck, as I was, that this tag line and these themes resonate with EHR and health IT concerns that many current EHRs and health IT applications get in the way of work, are not easy to use, and divide healthcare into silos of users unable to communicate, let alone coordinate their patients’ care with each other.

If you think that slide about ease of use and universal participation was relevant to electronic health records and health information systems, wait you see this next slide.

For readability and emphasis sake I’ll outline some of the bullets…

  • Easy to create
    • Rapid Application Development – Drag & Drop, No Code
    • Single integrated suite – no integration [required] between BPM components
  • Easy to deploy
    • Write Once, Deploy Everywhere – All Mobile Platforms
    • Instant availability and easy upgrades
    • Identical platform on-premise & cloud
  • Easy to Adopt
    • Elegant interfaces – optimized for every device
    • Simple, no-training social interface
    • Same user experience on every platform
  • Easy to Reuse
    • Reusable
    • Modular components

I dare any health IT professional to claim any of these sterling qualities aren’t relevant to EHRs and HIT. 

Let’s start with “Easy to create.” Most EHRs highly customizable, they have to be. But one thing that is very difficult to customize, without being a programmer with access to their original source code, is their workflow. This is so unfortunate, since complaints by physician users about unusable EHR workflow are rife. That’s the great thing about BPM systems, you don’t have to be a programmer to create and edit workflows. Dragging and dropping, clicking and setting, entire screens, their contents, both for data review and data and order entry, can be customized and then assembled into whatever workflows the users require or prefer.

Regarding “integrated suite” and “components”, both screens and screenless activities can be programmed by non-programmers to work together in ways that EHRs, since they are not based on BPM technology cannot do.

How about “Easy to Deploy?” While some EHRs are making the move to the cloud, so anyone with a browser and a connection to the Internet can be up and running “Live in Five” (minutes, not months), this “Easy to Deploy” means way more than that. It means that the same application created by the domain expert, a non-programmer because they don’t need to be one, can be used on the desktop, over the Web, on a tablet or smartphone, iPhone, Android, and Blackberry (and likely more to come), without having to write separate applications for each platform. How many EHRs can claim this? (Yet.)

Now, what about, “Easy to Adopt”: EHR “adoption” is the subject of much hand wringing, in white papers, on blogs, and the Twittersphere. Given all their obvious benefits, EHR adoption has been frustratingly slow, so much so that the Federal government earmarks billions of dollars of subsidies to encourage physicians and offset productivity loss due to less than completely usable EHR workflow. A familiar refrain in the blog is that solving EHR workflow usability problems requires use of workflow technology, at the very least workflow engines and process definitions, ideally also the other modern aspects of BPM, including process mining, simulation, activity monitoring, and case management.

The “no-training social interface” referred to is the now almost classic activity stream. Folks are used to Facebook, LinkedIn, and Twitter, why not use a similar user interface? It takes less training and is naturally social to boot. Since each platform doesn’t require a programmer to create a different program, and therefore different user interface, consistency across platforms is achieved. So, not only does previous user experience with social media transfer to the EHR, training on one EHR platform (say, desktop Web) transfers to another (say, mobile, or, increasingly, from mobile to Web and desktop)

Finally we get to “Easy to Reuse”. Calls for modular EHR components far outnumbers the number of modular EHR components in evidence. This is in spite of meaningful use certification for both “complete” EHRs and EHR “components”. Oh there are lots of certified components advertised and listed, but true software components can be quickly and easily assembled into complete applications, in this case complete EHRs. The problem is that even if such chimeric applications can be assembled, their workflow is still is less than optimally usable. That is why we need BPM style workflow engine and process definition to more elegantly glue together these components into usable workflow wholes.

From presentation by @SKemsley

The “External Socialization Spectrum” refers to the degree to which an information system can ignore resources (human or not) outside the info system’s organizational confines versus degrees of interacting with, or including, outside parties in process execution. For example, a patient may need to know about an important lab result, but not need to be a full-fledged power user. Or, an outside specialist needs to become a full-fledged user of an EHR in order fully participate as a member of a patient’s care team.

I’ve written elsewhere that patients should be users of EHRs, with defined roles and tasks within EHR process definitions, but that was a comment on someone else's blog, so I think I’ll quote myself here by way of repatriation of content to one of my blogs:

Business process management ideas and software can accommodate both patient-centric and physician-centric emphases. The patient role is a “role”, just as the physician’s role is too. According to the Workflow Management Coalition’s “The Workflow Reference Model” a role is “a collection of participants based on a set of attributes, qualifications and/or skills."

So, what are a patient’s (or customer’s or client’s or whatever is consistent with political, marketing, or ideological orientation) attributes, qualifications or skills? When a process-aware health information system is designed, encompassing patient activities, the patient’s role needs to be defined as part of that design. More abstractly, the patient is a resource (a Human Resource, of course!), just as other users are resources, necessary to accomplish a business process (or clinical process, health process, or just “process”, again terminology varies according to agenda).

Just as physicians, nurses, technicians, transcriptionists, billers, and other staff have worklists in which workitems appear (placed there by a workflow engine executing a process definition, or placed there in an ad-hoc fashion by a human user), patients could and should have worklists of workitems too (perhaps appearing in smartphones). Of course, patients (and physicians and nurses and others too) may ignore these items, in which case these items can be programmed to automatically escalate. Some of these items also may be accomplished automatically or semi-automatically via home or mobile devices on, connected to, near, or ambiently present near, the patient.

Current structured-document, as opposed to structured-workflow, EHRs don’t have the necessary process-centered data models necessary to represent patient and provider roles and to automatically, semi-automatically, or manually (but with real-time activity monitoring and visibility plus subsequent opportunity for design-time improvement) execute, or “enact”, healthcare processes. This is a large part of the reason that I believe that health IT needs to move from debate about patient-centered versus physician-centered design (“Who is the real user?”) to a more encompassing view (including explicit and executable representations) of the processes within which users (including patients) are embedded.” (Link)

The idea of “patients’ work” appears occasionally in research literature, such as here, where they write

“[It takes work to be a cancer patient. During cancer care, all patients navigate the health-care system, communicate with clinicians, and manage information related to their health situation. However, patients’ work remains largely invisible [15–17]; we understand little of how patients accomplish their tasks or how existing systems and services relieve or exacerbate the burden of these tasks….Our study provided several examples of how patients’ work helps detect, prevent, and recover from medical errors. However, current clinical information systems do little to support that work. Generally, these systems do not extend functionality to patients, facilitate information sharing between patients and clinicians, or support clinical interactions beyond the treatment center. Consequently, patients have difficulty accessing and using information to participate in their own care.”

Certainly, there is much discussion of participatory medicine and patient access to their medical record (“Gimme my damn data”). It therefore seems reasonable and sensible to not just design systems to include, not exclude patients, but to choose EHR platforms that make such systems “designable” in the first place. By designable, I mean choosing a platform capable of delivering easy to create, deploy, adopt and reuse: from the patient’s perspective.

Traditional structured-document EHRs, even those based on user-centered design, do not explicitly represent the workflows necessary to include all members of the care team as users. Hence my recent call for process-centered design of process-aware EHR and health information systems.

Back to AppianWorld [CW: the 2012 conference, remember!]...


Mobile user interfaces and experience influences everything these days, from big “targets” to disappearing UI “chrome” to list-like activity streams (promoting “peripheral awareness”). Display on a smart phone, 30 percent of the UI disappears (but is available with a click or a gesture). Display in bigger screen, and see more items per list and more columns. We'll be seeing this come to most EHRs and health IT UIs eventually.

This presentation about adaptive case management (which I’ve written about previously) was one of the most interesting of the conference. There's a bit of debate going on within the BPM industry about structured versus unstructured processes (again, have written about this here).

(The print is small so...) This slide says that ACM...

“provides a support environment for the optimal performance of knowledge work cases in line with stated goals, together with management tools that enable analysis-based improvement of work effectiveness. In an ACM environment work is not carried out according to prescribed process definitions; instead it’s guided by teams of case workers working toward a clear goal, leveraging codified patterns of practice, and complying with rules that specify key business constraints.”

Described this way, but substituting “patients’ health” for “stated goals”, “evidence-based medicine” and “clinical outcomes research” for “analysis-based improvement of work effectiveness”, “care team” for “case workers” and “clinical” for “business” I’d venture to say that quite a few EHR and HIT designers, developers and (especially) marketers would argue “that’s what EHRs do!” “that’s what HIT does!” Well, it certainly what they should do, we can agree on that.

Unfortunately, more EHRs evolved from digital charting and reporting systems. They have lots more bells and whistles these days, especially due a long list is requirements to qualify for twenty-odd billion dollars earmarked for EHRs certified for meaningful use. The problem is, in many cases, these systems are often too difficult for individual users to learn and use, let alone facilitate workflows for the high performance care teams most thoughtful observers think healthcare needs.

What if EHRs were implemented with, that is, on top of, BPM and ACM system foundations? If users don’t like the workflow, if they don’t find them usable, well, change the workflow without having to go back to the Java or C# drawing board.

If user workflow is routine (as it is in many pediatric and family medicine clinics) automate the workflow using BPM process definitions executed by workflow engines. If the workflow is not routine (as say in complicated multiple-disease/system cases) fall back on more general ACM goals and constraints.

In either case, you have a shot at addressing one of the most pernicious and almost universally condemned disadvantages of most traditional structured-document EHRs: lousy workflow. Which should not be surprising. If workflow is the problem, then workflow technology is the solution.

Let's get back to the debate about “traditional BPM” versus adaptive/dynamic case management. Other industries, other than healthcare, have automated many or most of their routine workflows. Workflow that can be represented in advance and automated, has been. Given that these industries are literally decades ahead of healthcare in this regard, this should not be surprising. These industries have already moved on to providing automated support for what Peter Drucker call “knowledge workers”. Aren’t physicians and clinical staff knowledge workers. Shouldn’t healthcare skip traditional BPM and go directly to ACM? (A bit like so-called undeveloped countries skipping the telephone poles in favor of cellphone towers or satellites.)

No. Why? Because we haven’t yet modeled and automated all the routine processes of healthcare that can be modeled and automated. Yes, much of medicine is knowledge work, but a lot of that knowledge is compiled down to repetitive pattern recognition. Ask the pediatrician who loses money if he or she can't diagnose and order treatment for an ear infection in less than thirty seconds.

That same pediatrician, though, does need to deal with complicated cases, in which there is no set chronic asthma process definition to make the EHR behave super efficiently. That is where the ACM comes it. Healthcare needs both: traditional BPM, with it tried and true modeling and execution of healthcare processes; and nouveau approaches managing more complicate cases such as adaptive case management.

Luckily, BPM and case management vendors aren’t standing still. Both are working hard, as Appian is with version 7, to combine user-initiated less structured processing with process definition directed automation, in which tasks and screens are pushed to users to reduce their work and increase their workflow usability.

As a cheerleader for local companies I’d like to think Appian is representative of the best that BPM and case management can offer to healthcare. And I think I am right in this assessment. As noted at the outset, interest in application of BPM in healthcare is indeed exploding. I tweet about it at @EHRworkflow and archive the best of these tweets at http://EHR.BZ (over a thousand links to material at the interface between healthcare and BPM, with more added every week, sometimes every day).

I'll end with a slide from the Beneden Healthcare Society presentation at AppianWorld 2012 (their case study).

  • Questions?
  • Thank you!


Add comment

Security code

My Next Speaking Engagement!


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