Currently, there is a strong interest in improving decision support systems (DSS) [1
]. Despite several decades of effort, we have been unable to develop DSS platforms that would gain wide adoption [2
]. Some solutions are embedded in a proprietary system or are tied to a particular electronic health record (EHR) vendor which limits their adoption. Other solutions often introduce a healthcare-specific representation format and healthcare-specific execution engines, whereas past experience shows that successful healthcare solutions often rely on cross-industry standards. Finally, easy authoring or easy review of DSS logic still remains a considerable challenge [3
]. We present our implementation of a workflow engine technology [4
] which addresses two current challenges of DSSs.
The first challenge is the ability to evaluate DSS modules prior to deployment. For seamless testing and deployment, it is beneficial to be able to easily switch the execution of a DSS module from prospective to retrospective mode. Traditionally, this problem has been solved by two approaches, both of them sub-optimal and requiring additional resources. The first approach involves deployment of the module at a pilot site prior to enterprise-wide deployment and fine tuning the logic directly within the deployment environment. The second approach is a separate side-project for each deployed module which extensively analyses the possible impact of the intended DSS module. This separate side-testing usually involves a separate DSS logic representation for such retrospective testing (compared to the deployment prospective version of the logic).
The second challenge is the ability of non-programming clinicians (as recipients, reviewers, maintainers, or authors of decision support) to understand and manipulate the logic of a given DSS module. From a perspective of non-programmers, it can also be described as a "black-box phenomenon." A clinician who cannot review in detail the logic of a given decision support system may be reluctant to adopt a system that he can not fully understand.
We were able to address the two above-mentioned challenges with a system called HealthFlow
, which is an implementation of a workflow engine in the context of an EHR system. This software category article aims to provide implementation details for informaticians and champion clinicians at healthcare organizations that may be considering workflow engine technology to enhance their decision support functionality. We use the term clinical logic
to encompass not only decision support problems, but also knowledge representation for domains of quality improvement and clinical research alerts [5
]. The HealthFlow project is an effort to utilize a workflow editor and a cross-industry process definition standard to represent clinical logic and to use a workflow engine to execute such logic. Key objectives of the HealthFlow project are: (1) the ability to switch seamlessly from retrospective execution mode for prior-deployment testing to prospective mode; (2) the ability of non-programmers to review the executable logic in a user-friendly fashion (graphical, step-based flowcharts); and (3) the interoperability of the encoded executable logic across different healthcare institutions. The HealthFlow system described in this article consists of two components that share a set of common characteristics. We use the term RetroGuide
for the retrospective mode of operation, and our initial work with workflow technology focused on modeling retrospective and analytical processes is presented elsewhere [6
] (a comprehensive set of our desired functional requirements for a healthcare process modeling platform is published separately [7
]). For the prospective component of the system, we use the term FlowGuide
, and it was developed later as a distinct component within the HealthFlow project. The functional specification for the prospective component did not stem from a fixed set of initial requirements, but instead were an effort to maximize the use of functionality already included in a workflow technology suite.
Several prior studies report the use of workflow technology (WT) in healthcare, and we briefly survey some of these studies. Emanuele [8
] presents the use of WT to improve infection control and proposed a term workflow-enabled EHR system
, which can communicate bi-directionally with a Workflow Management System (WfMS); e.g., send EHR event notifications to the workflow engine and display in the EHR system tasks and alerts generated by the workflow engine. Quaglini et al [9
] piloted the use of the Oracle workflow software suite to implement a stroke guideline. Their project used a non-standard and proprietary process definition language; the workflow engine generated tasks, and alerts were delivered to clinicians via email. Peleg [10
] discusses the close relationship of current workflow engines with clinical decision support engines, and in collaboration with Mulyar [11
], compared existing guideline representation formats with workflow process definition standards using workflow patterns [13
]. Finally, Haux [14
] describes a commercial EHR system that tightly implements a workflow engine with clinical care information technology (IT) systems to enable advanced customization of many EHR functions to address local needs and utilize location-specific resources. The implementation presented in this article extends this prior work and proposes a prospective as well as retrospective operation mode of utilizing a workflow engine. Unlike previous implementation, it is also a solution that relies on established workflow technology standards rather then proprietary process definition languages. A later subsection of this article (architectural evaluation) further compares and analyzes workflow technology-based approach to decision support in comparison to other decision support platform using an architectural evaluation model [15
]. In the following section, we present the architecture overview of our WT implementation, typical usage phases, how the system interfaces with available clinical data and healthcare environment, and a use case example.