Short Link: http://j.mp/79mGR7
If a first year medical student says that a patient has a temperature, his or her attending may say something like “Of course your patient has a temperature, all patients have a temperature! Is their temperature normal or abnormal? Elevated or subnormal? What, exactly, is the patient’s temperature?
In the same sense, all software including EHRs, have workflow. The question is whether the workflow is good or bad and whether you have the means to adapt it to your purposes. EHRs whose workflow cannot easily be modified by a non-programmer have what might be called “frozen” workflow.
Most EHR applications require the user to navigate between screens to enter data. An EHR workflow management system can be configured to drive common input screens in any order that makes sense. This is most commonly based on the visit reason. In other words, an EHR workflow management system can deliver customized workflow around a practice’s current workflow process for gathering data. For example, a practice may currently use a paper based workflow system that they like. This not only involves what data they gather, but when and who collects the data during the workflow. An EHR workflow management system can be configured, through use of its process definition editor, to precisely match this pre-existing workflow.
Some EHRs do increasingly deliver some workflow capability; that is, they can contribute to an increase in productivity by doing for the user what they would otherwise need to do themselves (navigate to the next screen, inform the next person what they need to do, trigger an external application such as a digital ECG, and so on). However, these EHRs rely on “frozen” process definitions. Their workflow cannot be easily changed to adapt to circumstances not foreseen by the programmer. Programmers are not clinicians, or even more important, not intimately familiar with each and every minute step of dealing with a patient in medical practice. Only users can claim this degree of familiar knowledge. This means that users cannot easily change what EHR screens occur in what order, who gets passed the task baton when, or what external application to fire up automatically.
Only a full-fledged EHR workflow management system provides additional user interfaces that allow users, not programmers, to bend EHR workflow behavior to their specific and evolving needs. For example, a user should be able to easily instruct the EHR to insert a new data gathering step between vitals and chief complaint, or to easily add the automatic playing of a preventative care video at the optimal point of a well visit.
Apply the following litmus test designed to detect frozen workflow:
The simplest test of whether an EHR is built on a workflow management system is to ask for a live demonstration of the following:
- Ask to see an encounter from beginning to end. Focus on the sequence of screens.
- Ask to see the process definition that controls the sequence of screens just observed.
- Ask to see a small edit in the process definition using the EHR process definition editor, such as the deletion or reordering of several steps.
- Ask to see the same encounter again, while focusing on whether or not the changes in the process definition have indeed resulted in the appropriate changes in screen sequence.
- If the screen sequence changes in just the way that would be expected if an EHR workflow engine is consulting the just edited process definition, then you are likely looking at an EHR workflow management system.
If an EHR cannot demonstrate steps (1-5), then the EHR lacks the capabilities of a workflow management system. It does have workflow (because all software applications have workflow). It may even have workflow that is good for a particular task and context. However its workflow is frozen.