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???
(From EHR Science)