Jerome  Carter, MD  June 20, 2016

For the last few weeks, I have been writing less and planning more. As plans work out, new plans are required, and lately, it seems about every three months I have to stop and recalibrate. The plan for the next six-month cycle includes two BPM/workflow tutorials and the outline for a book on clinical process management. For the tutorials and the book, I have been experimenting with BPMN modeling and investigating BPM products, which means contacting companies, looking closely at product offerings, reviewing product-focused tutorials, and similar activities. Wrangling BPM to fit clinical care is proving to be an interesting challenge.

When creating clinical process models, one of the first things that jumps out is how decision-making in clinical care differs radically from most business domains. Clinical professionals are expected to review data and make decisions, and while there may be protocols, is it rare that clinical judgment may not override them. Of course, there are many parallels between healthcare and other business domains—all have registration, accounts, billing, inventory—and in my experience, modeling for these types of processes differs very little across domains. However, EHR systems are targeted at clinical professionals, and their processes and activities have much less in common with typical business processes.

Consider Registration as a process. How much control do registration staff members have over the process? Typically, very little. Managers above them design and monitor the entire process. Clinical professionals, on the other hand, exercise much greater control over their processes—at least they did until EHR systems appeared. The essential tension between clinicians and EHR systems arises from the question of who is in control.

Since clinicians need information to make decisions, the availability of information is a limiting factor in clinical decision-making. When access to information is hampered by poorly-designed navigation or hard-to-read screens, decision-making suffers. From a modeling perspective, clinical processes require attention to both when decisions are made and the information they require. Any given decision may depend on information from multiple sources—labs, consultation reports, the patient, family members—so, when designing systems, one has to be sure that all sources are easy to access. In reviewing BPMN modeling examples, I noticed how many were form-centric. Loan applications, travel expense reimbursements, job applications, product sales, all revolve around forms that are filled out and passed along until the process completes. Decisions for these processes rely on information contained in the form. Clinical care doesn’t work that way. Patients don’t arrive with a set of completed forms with everything needed for decision-making. The same is true of results management. Following up on abnormal results may require as much new information as does making a clinical decision while seeing a patient.

Information gathering has to be finely-modeled in clinical processes, but usually isn’t (at least not well) because the EHR is presumed to be the go-to information source. When clinicians complain about EHR systems, the underlying problem is often difficulty in quickly accessing the information needed to finalize a decision.

Decision order is a second EHR/clinician control issue. Unlike typical business processes, clinical processes, being directed by clinicians, have no externally set order. Thus, just as any decision can require disparate information sources, decision sequences cannot be set in stone. For example, one cannot require that every lab be reviewed before an abnormal one is addressed. Similarly, three patients may call for refills simultaneously, and each request becomes an interruption in the lab reviewing process.

Individual clinical processes have a specific order, but clinicians often initiate multiple processes at once. As a modeling issue, one has to determine how to represent so many processes occurring with the same participant at once. As might be expected, this is an EHR issue as well. EHR design begins with assumptions about what clinicians do and in what order. When the order dictated by the EHR differs from that desired by the clinician, usability issues arise.

Using BPM tools in clinical care (not simply in healthcare settings) requires a different way of thinking about processes, such that, as I get further along in BPMN 2.0 symbols and practices, I find fewer examples that are appropriate for modeling clinical work. I am not saying BPMN is unsuitable for clinical modeling. Only that modelers have to be careful to capture clinical processes in all of their richness and good examples are hard to come by.

Aside from modeling, I have found my interactions with BPM suite vendors to be… educational? I am an internist and an informaticist, but I also have a business and sign contracts and provide deliverables, so I think of myself as a businessman until I run into enterprise software sales folk. Here is a simple question that I think most people would consider quite reasonable: How much does product/service X cost? One would think that buying BPM software should be easy since obviously there are many companies selling it. Nope. I found only one company that listed the cost of the software. Every other company required a few emails. Of course, all vendors offered to have a salesperson call. Now, if sales people understood the technical capabilities of the product, then that would make for a useful sales call. Nope. If technical information is required, that is a different call.

The number of companies that have a minimum purchase requirement also strikes me as counter-productive. It makes me wonder--if a minimum of 10 licenses must be purchased, would they be happy to sell 10 licenses to five companies, but not five licenses to 10 companies? And these are not Fortune 500 companies. Most BPM vendors appear to be relatively new, private companies. Fortunately, there are enough open source systems available that, in most situations, the issue is moot (at least for now), and I have found a few vendors who seem responsive to my questions. But still—why make it potential clients jump through hoops?

Bringing BPM to clinical care also requires a means of engaging clinicians in understanding processes beyond the level of flow charts (Keith Butler seems to be doing this). It also requires that modelers, analysts, or whomever, not make the mistake of thinking of clinical processes in term of forms and linear sequences, but instead, in terms of decisions and information flows. Unlike flowcharts, BPM tools allow one to create real applications so that (presumed) good workflows can be tested.

When I look at sites aimed at BPM professionals, and then turn to informatics, human factors, and software design publications, I see a huge gulf. Everyone is talking about workflows and processes, but not in the same way. Bridging that gap would bring benefits to all.