Data and/or Processes: The Designer’s Dilemma—Clinical Swift Series, II

by Jerome Carter on December 7, 2015 · 4 comments

Traditionally, clinical software has been organized around data.  The reason for this is the paper chart, which is a process-agnostic information source.  At the outset of creating a new software product, this question has to be answered early on: Is this a data-focused system or a process-focused one?  The architectural differences between the two types of systems are sufficiently extensive that one type cannot be easily repurposed to the other.  Every system does not need to be process-focused, so the question becomes how to decide what is needed. The only way to do that reliably is looking at how the software will be used.

Lately, after experimenting with BPM suites, I have begun mulling when systems should be process-based. Thinking about this question led to a set of basic criteria for determining if a system would benefit from being process-centric.

Process-focused system required
Decision-making has multiple steps or branching
Decision-making requires input from multiple sources
More than one person is involved in an outcome
Criteria exist for making decisions

Data-focused system sufficient
Decision-making is done by one person
Only one step (data review) is required to take action
No criteria exist for good vs bad decision outcomes
Cases are one-off (i.e., final decision terminates the case)

Here is the thinking that led to these criteria.  Decision-making weighs heavily in the criteria because that is what many clinical systems are intended to do.  Simple decisions like selecting the next waiting patient require little support. Unless there is an emergency, one simply selects the next person from the queue.  Here, there is only one decision step, and the decision terminates that case (selecting a waiting patient).  Other examples of these types of decisions would be choosing an item from a to-do list, looking up a lab value, and checking the next appointment date.  In addition, the decision-maker does not require any ancillary input or advice to make the choice.  All of the above decision situations terminate naturally with no side effects (I assume…). For these examples,  it would seem that nothing is needed other than simple data. Finally, if the software user does not desire help and only wants information, then, obviously, process support is unnecessary.

Another factor to consider is the cost—time, resources, money—required to create process-centric systems.  There is no reason to support processes if such support would add little to the value of using the software.  Like all design decisions, there are pros and cons.

The situation changes if decisions can branch (i.e., there are multiple choices with different consequences/outcomes). In such cases, each branch requires information and the outcomes of each branch must be weighed by the decision-maker.  Complex decisions require a way to keep track of the location in the decision space along with knowledge of currently available branches. Even though only one person may be involved in decision-making, properly designed software can help with complex decisions.   If it is the case that either other people are involved, or there are rules/criteria for what makes a good decision, then additional software support is usually required to assure adherence.  Complex decisions are processes, whereas simple decisions are events.  If complex decisions are involved, then the software should be process-centric.

Deciding how to approach prn: CIM – On Call has made the dichotomy of these two system types a major design point.  I now have to wrestle with a problem I was hoping to save for later.  It is all the more irritating because it encourages feature creep.  Should I settle on meeting the initial idea of a peripheral brain, then the obvious choice is data-focused as the app is just a way of keeping searchable notes.  However, should I ever decide to make it more helpful; say allow the app to track patients beyond the initial call or provide follow-up alerts, things get slightly fuzzier.   One need not use a WF engine to implement alerts or tracking. However, the further down that road one travels, the greater the likelihood that a WF engine should be part of the design.   

Since this is a demonstration project (i.e., no wealthy backers and no definitive market), YAGNI wins,  and I’ll go with data-focused.   Of course, there is nothing preventing my replicating this project with BonitaSoft.  And now that I have broached the subject, repeating this project with BonitaSoft (or Appian if they would provide the software at no cost)  would seem like a great way to firm up the criteria for when to build a data vs. process-focused system.

Of course, having a data-focused app has its own problems.   At this point, I wish openEHR had a component I could use.  Alas, that is not the case, so now I am stuck with deciding how to handle data storage.  At the very least, this means creating a data schema, mapping it to a data access layer, deciding how to store demographics, diagnosis, medication and notes data, and creating an audit/logging system.  Yeah, a clinical data management platform that I could build on top of would be great about now. 

Open mHealth has an interesting take on clinical data management, and I will take a deep look at what they have done before making a final decision concerning data storage.  Before I get to that point,  however, there is much more to be done with requirements, UI ideas, design patterns, use cases, and classes.   

EHR Science is about clinical software design principles and precepts—not just about what to build, but also about the scientific and engineering knowledge that undergirds those principles and precepts.  To that end, this matter of data versus processes seems worthy of discussion.  Anyone care to offer an opinion?   Chuck? Bueller???


Leave a Comment

{ 4 comments… read them below or add one }

Philippe Ozil December 16, 2015 at 8:57 AM

Hi Jerome and thanks for your interesting analysis.

For the sake of transparency, I must say that working for a BPM vendor (Bonitasoft), I am rather partisan of the process-centric approach.

Now, to get back on the subject, I wish to go further on the example you gave on selecting the next waiting patient. This is probably not a process on its own but it can be two tasks (patient arrives and select patient) in a larger process.

Using BPM in that case would allow you to easily gather metrics such as average wait time. This has several benefits:
– on the short term, this helps patient to wait.
– on the longer term this can be used as a KPI to better manage your organization over time.

Going further, with this KPI you can set a quality of service target (e.g.: “the average wait time should always stay under an hour”). Collecting some stats on a larger period will then allow you to plan for extra staff on rush hours thus optimizing expenses while improving quality.

This is just an example inspired by the traditional BPM life-cycle: model, execute, monitor, optimize.

Of course, implementing such a system does require resources and it may be an overkill depending on the volume processed but one can foresee the added value.

I agree with your comments on the value of BPM when it comes to decision branching.
Some of the core focuses of BPM are collaboration and decision making.

To establish that, BPM relies on traceability. It basically keeps tracks of the actions and decisions of previous process actors. These audit trails can then be used to assist other actors when they interact with the process.
Then, on a broader scale, this audit data can also be data mined to optimize processes.

An extra advantage of a BPM approach than you mentioned is that it provides a certain level of self-documentation through process diagrams. By reading a diagram, one may get a sense of the organization of tasks and actors.
This helps to standardize practices among all actors and can facilitate training of newcomers.

To conclude, I would say that the process-centric approach has some advantages over a pure data approach. However, it certainly cannot run alone without business data.
In the end, the end-user should be looking at his data and ideally, data modifications should be managed by processes.


– Philippe


Jerome Carter December 16, 2015 at 11:33 AM

Philipe, thanks for your comment! Few clinical care systems are process-centric, but I believe many aspects of clinical care, such as decision support, would greatly benefit from a process-centric approach. BPMN needs to be adapted to provide better fidelity for modeling clinical care, but that work is not difficult. In all, I believe Clinical Process Management using BPM software has a very bright future.

Please consider visiting Clinical Workflow Center, which is dedicated to workflow methods/tools/BPM in clinical care.


Chuck Webster MD MSIE MSIS @wareFLO December 7, 2015 at 10:30 AM


It’s my day off! 🙂

As usual great blog post, especially whenever you address healthcare workflow and workflow technology. I’m on the run at the moment, but I will say that health IT has been doubling down on data-centric systems for years, but we’re pivoting toward more-and-more workflow-centric systems (partly to compensate for the extremely data-centric position healthcare IT finds itself in). I will point folks to question 2# in my most recent post: Health IT Workflow Integration: Whither #FHIR? (Fast Healthcare Interoperability Resources)

2. Can health IT workflow standards encourage adoption of process-aware BPM-like workflow platforms?

“CW: ‘A technology currently touted as a means to integrate systems together is FHIR, for Fast Healthcare Interoperability Resources. In a couple years we’ll see standalone apps accessing data in from these data-centric systems. Some of these apps will be embedded into EHR user interfaces (such as for calculating pediatric doses or specialize drug interactions). FHIR will also be used by more workflow-centric care management systems, which you can think of as a layer on top of individual data-centric systems. These workflow-centric systems will increasingly coordinate care across providers, track patient events, and management handoffs. However, until FHIR can also push data to IT systems, and represent task and workflow state, workflow platforms will have to compensate and provide these missing pieces of the workflow interoperability puzzle.

To the degree we surround healthcare organizations with process-aware health information systems, process-aware technologies will inevitably seep across and into these healthcare organizations. If we use workflow technology to effect workflow interoperability among healthcare organizations, they will begin to leverage task and workflow representations within their borders with workflow technology. I’m reminded of a recent conversation with a hospital IT executive. He needed a Business Process Management engine to maximally leverage interoperability with his local Health Information Exchange, because it had a BPM engine.'”




Jerome Carter December 7, 2015 at 2:07 PM

Sorry to bother you on a day off! Thanks for your comment!


Previous post:

Next post: