abstract
A review of difficulties experienced with proprietary guidelines languages and in clinical decision support has led us to the development of a decision support system (DSS) based on a service oriented architecture (SOA) using Business Process Execution Language (BPEL) and Web services. BPEL allows simple branching conditions and tests to be set based on the information artifacts in the workflow. For more complex tests, we preferred to place decision support in an external DSS Web service. An advantage of this approach is that the DSS could evolve independently of the clinical workflow. We have implemented an exemplar of the above using the Java expert system shell (JESS). The domain objects are sent by the BPEL engine into the DSS which consults external rules, reasons on the domain objects and rules, and transmits recommendations back. The article will discuss issues involved in implementation using as an example drug-drug adverse reactions.
introduction
In an earlier article (Liaw, Deveny, Morris, Lewis, & Nugrahanto, 2004), we developed an approach to Clinical Decision Support (CDS) based on the BPEL and Web services. The process flow associated with the treatment (diagnosis, referrals, consolidation, and action), was expressed, following expert group analysis, in a series of blocked activities which could then be drilled down into specific actions. The expert analysis led to (i) a set of activities (tasks or services or actions) and decision points; (ii) a set of information requirements at each stage of the process flow, to be mapped onto information sources and sinks; and (iii) a “best-practice” sequence of activities and actions. The sources and sinks and activities could be resolved into local process variables, or a Clinical Information System (CIS) or a set of external service providers described through Web Service Description Language (WSDL) (W3C, 2001).
In a follow-up article (Morrison, Lewis, & Nugrahanto, 2006), we explored issues in interoperability between the workflow engine executing the decision support guideline and the endpoints supporting the external service providers (including manual intervention). We showed the pros and cons of using either SOAP-encoded RPC-style information transfer or document-style transfer and how these approaches were reflected in the design of Web services endpoints and the types of Information Models able to be used to transfer application data.
The examples we provided at that time performed decision support within the workflow engine, utilizing BPEL decision constructs. However, this approach is not suitable when the decision is complex or if flexibility is required in environment/language bindings as in rule-based approaches commonly used in clinical decision making.
In this article, we present and discuss implementation of an evolved architecture, focussing attention on the separation of concerns amongst clinical workflow, reasoning engines, and rules bases in drug- drug adverse reactions as an application scenario. We place complex decision support in an external DSS Web Service accessible to the workflow engine in the same way as the EHR and other service providers Thus, the detail of the DSS implementation is abstracted from the workflow description and its mechanisms hidden behind an interface facade. Different reasoning engines can be made available depending on the application context and rules bases can be updated following expert review independent of the CDS processes. The rules bases could be maintained centrally and the most current version loaded on-demand.
service oriented architecture and clinical decision support
service Oriented Architecture
The basic principles of SOA consist in modularizing functions and exposing them as services. This idea of a software application as a service was recognized in the past (Sun’s RPC, Microsoft’s COM/DCOM), but it can now be fully realized using the Web services for systems interoperability.
A Web service is a software application available on the Web whose capabilities are described in XML and is able to communicate through XML messages over an Internet transport protocol. Basic elements of Web services are the standards for interoperability: XML for information representation), SOAP (W3C, 2000) for invoking, WSDL (W3C, 2001) for describing, and UDDI (http://www.uddi.org) for discovering.
On top of this basic interoperability protocol stack, new languages and specifications for defining the composition of Web services to form business processes have emerged, such as Business Process Execution Language (BPEL) (IBM, 2002). Characteristics of BPEL include a service orientation model that emphasizes standards compliance and XML encoding. As well as a formal basis to the language, services are loose coupled and can support synchronous and asynchronous activation.
When compared to related standards (such as XPDL and WSCI), it appears that BPEL is relatively expressive (Wohed, van der Aalst, Dumas, & ter Hofstede, 2003) and currently BPEL is the only standard that comes with execution engines such as Oracle BPEL Manager (Oracle, 2006), IBM’s BPWS4J (IBM, 2004a) and ActiveBPEL (ActiveBPEL, 2006)
SOA and CDs
Benefits from CDS include improved patient safety, improved quality of care, and improved efficiency in health care delivery (Sinchenko, Westbrook, Tipper, Mathie, & Coiera, 2003). However, these goals are yet to be fully realized largely due to poor integration with clinical workflow and practice and poor integration with EHR and/or other clinical systems (Eccless et al., 2003).
In recent years, we have seen development in SOA-related standards and technologies that could potentially to provide answers to some of the technical challenges around integration and interoperability in the clinical and health care context. Research in this areas are quite fluid at the moment but initial indications are positive (Peleg, 2005; Kawamoto, 2005; Anzbock & Dustdar, 2004; Anzbock & Dustdar, 2005).
Recognizing the need to develop service interface specification standards to support clinical decision support in SOA, the Health Level 7 (HL7, http://www.hl7.org) and Object Management Group (OMG, http://www.omg.org) have agreed to collaborate in the Healthcare Services Specification Project (HSSP, http://hssp.wikispaces.com). The project has identified some of the services that may be useful for the implementation of a CDS system. These services concern with, for example, managing patient identity, locating records, verifying terminology, and drawing conclusion based on patients’ data.
In Australia, NEHTA (The National E-Health Transition Authority) has recently recommended the use of SOA for the design of health applications and has produced an Interoperability Framework (NEHTA, 2005) and a Web Services Standards Profile (NEHTA, 2006) lending further weight to the adoption of these standards and approaches.
cds with Web services and BPEL
As clinical decision support requires a robust distributed architecture (Nealon & Moreno, 2003), Web services are a strong candidate as a delivery mechanism. BPEL has been developed in tandem with the development of Web services, firstly as a process description and execution language, and then, due to availability of Java-platform Application Programming Interface (API) and execution engines, as a means of automating (orchestrating) the coordination of Web services.
In using SOA (BPEL and Web services) as an architectural design, we noted (Morrison et al., 2006):
• Web services may not completely solve interoperability problems between clinical systems, however, they show great promise of reducing the complexity of interconnecting heterogeneous software systems distributed over the Internet partially by providing a level of service and information flow abstraction.
• The expressiveness of BPEL as a process description language to model business processes (Wohed et al., 2003) as well as providing execution engines supportive of web-services-based tasks/activities makes it a strong candidate for modelling coordination required in a clinical setting to assist decision making.
• BPEL cleanly separates transport, process definitions and information flows. Information flows can be defined by schemas (document-style) or mappings to classes/objects which are defined by SOAP-encoded RPC.
Coordination of decision-making process in BPEL can be done in a way that reinforces the centrality of the roles enacted (see Figure 1), whether they be by the General Practitioner (GP), EHR, or another entity, and specifies the interfaces to be implemented in a technology-neutral way. Although BPEL does not directly support a “role” at a language level, these can be affected through environmental bindings. BPEL then makes these roles and services explicit and transparent while hiding details of service implementations—in our earlier examples, we had a GP, practice nurse, and external service providers.
Figure 1. Representation of roles assignments using BPEL
In the SOA architecture (with BPEL and WS), for example, roles can be assigned to a healthcare-provider, a patient (and patient health record), the DSS/Workflow engine and associated services, such as terminology or medicines information.
Decision Making strategies with BPEL
BPEL allows simple workflow branching conditions and tests to be set based on the information artefacts provided by the services or held in the process execution context. For example, in the case of asthma (Liaw et al., 2004), we could check the patient’s age and X-Ray consolidation (extracted from CIS or Provider reports as external services) before deciding on the next course of action.
For more complex tests, we could embed snippets of Java code into BPEL as proposed by IBM and BEA (IBM, 2004b). The BPELJ extension will allow BPEL to not only to orchestrate web services but will also allow orchestration of local resources which is more efficiently accessed with local means. However, this approach as noted earlier would be at a cost to the portability, language and platform neutrality of BPEL as the extension deals only with Java 2 Platform Enterprise Edition (J2EE) (Sun, 2001) resources.
Therefore, we will investigate placing complex decision support in an external DSS Web service accessible to the workflow/process engine in the same way as the EHR and other service providers.
An advantage of this approach is that the clinical workflow, reasoning engine, and rules bases are all separated. Furthermore:
• The approach places all services on an equal conceptual footing. In particular, the DSS as a service could itself call on other services independently and as required.
• In the Web Services context, the DSS could itself then be comprised of other complex flows and be independent of the workflow provided it met the required interface con-tract-for-service.
• The approach decouples the clinical workflow and timing from the decision tests. In the case of the introduction of new drugs or the publishing of an update or an alert on an existing medication, the clinical workflow would not be affected however the DSS would draw on the new information.
THE TEST APPLICATION SCENARIO
We will look at the example of drug-drug adverse reactions. Drug-drug interactions occur when two or more drugs react with each other with potentially adverse consequences to the patient to whom they are being administered. For example, mixing a sedative and an antihistamine can slow reactions and make driving a car dangerous.
We model a GP interacting with a patient and deciding on a course of medication (see Figure 2).
The proposed medication, determined by the GP after consultation with the Patient, is sent with the patient external ID to an external (to the workflow engine) EHR service which then calls the EHR (practice-based or externally-based) and extracts the current medication list (expressed in this case as a drug list modelled as extracted from a Medical Director (http://www.hcn.com.au/) application (Practice CIS).
The current medication list and the proposed medication goes to the DSS which has loaded (i) drug concepts and drug classes and (ii) decision support rules in terms of these classes. The current implementation (there could be many rule sets per supported CIS) maps the proposed medication into a drug class and checks for known adverse reactions with other drug classes. That is we did not map specific medicine preparations but more types of drug (e.g. determined as per active ingredient, not preparation). This, of course, could be easily generalised. The examples we used in testing were drawn from the Therapeutics Goods Administration (TGA) Adverse Drugs Reaction Bulletin (http://www.tga.gov.au).
Figure 2. BPEL scenario for drug-drug collisions checking
The decision-making process implemented was choreographed in a synchronous BPEL process and all services were implemented as Web Services (EHR, DSS, and GP) that exchanged activity and information via the SOAP protocol over HTTP. Although we focus in this article on rule-based decision support, and implemented the test scenario in a simple Web Services Profile (equivalent to the NEHTA Basic v1.0 Profile), the addition of other services (e.g. WS-Reliable Messaging, WS-Security) and alternate communication models and transports is quite straightforward as shown in an earlier analysis of practice workflow and interoperability framework (Morrison, Lewis, Liaw, 2005).
Rule Engine
For the reasoning engine behind the DSS service facade we used Jess (Friedman-Hill, 2006), a rule engine developed at Sandia National Laboratories in the late 1990s and written in Java. Creating and invoking Java objects from Jess (or vice versa) is fairly transparent if the objects have JavaBeans (Sun, 1997) properties and reflect domain constructs able to be represented in XML schemas. As a result, domain-level attributes can be easily mapped into specific rules and facts and reasoned on.
The current Jess implementation does not support, however, automatic conversion of collection objects other than Java arrays but this restriction parallels those involved in the choice of Document-based rather than SOAP-encoded RPC-based content model transfer in Web services and is more an application-level design issue. It does not have practical limitations for the types of information models currently used in CIS Extracts and on Drug-Drug and Drug-Condition tests.
Architecturally, Jess is well suited to Web services DSS use as it complies with the JSR94 specification (JSR94, 1994) for “plug-and-play” rules engines for Java-based Decision Support and is the first engine to be endorsed under this community standard. This allows the DSS facade to be backed by an API that can select specific engines at run-time based on application requirements—facilitating multi-facetted DSS services. The concept is very similar to having multiple messaging providers and directory service providers behind a standardised service interface. Applications see the standard interface and providers can be switched.
One of interesting features of Jess is the notion of shadow facts. A shadow fact is an unordered fact whose slots/properties correspond to the properties of a JavaBeans. Therefore shadow facts serve as a connection between facts in Jess working memory and Java objects representing the facts.
Workflow Engine
For the workflow engine we used ActiveBPEL BPEL engine (ActiveBPEL, 2006), an open source and free-to-use implementation of BPEL engine with a strong community support. It has a visual tool to design workflows and thus minimizing the need to script them at textual level.
We should mention that as this engine is BPEL-compliant, we had no difficulty importing our examples in the treatment process for asthma (Liaw et al., 2004), previously developed in Oracle BPEL Process Manager (Oracle, 2006). However, we noted that one must develop in this case a library to accommodate the omission of user task management (a given, straight-out-of-the-box feature in Oracle PM). Also, there is no persistence mechanism by default but we could use any standard or public domain database as the linking mechanism has been provided as part of the suite.
EHR
For implementation of the EHR service we have extracted data from the Medical Director Practice CIS and organized them into a Clinical Document Architecture (CDA) (HL7, 2004) structure appropriate for Summary Clinical Data Extracts. Using the associated XML schema, we populated our EHR using XMLBeans (Apache, 2006). As noted, our approach is schema-driven throughout. The patient summary schema is not only useful for populating the EHR, but can easily be used to import the information models into our BPEL workflow. Using this approach, we are able to easily change patient record structures (and other required information structures associated with support services) as these are agreed to extend our prototype. In this way, clinical summaries and external services report content is made available to both the BPEL Process and the DSS. The approach and architecture are quite flexible and allow the data to be sent directly (encrypted, de-identified, and through choice of multiple communication channel—mail, http, Message Oriented Middleware [MOM], etc.) or by reference/delegation and extracted as required by the workflow engine or DSS services.
results and summary
We applied the above architecture and test scenario to a number of drug-drug adverse reaction alerts published by the TGA. In the cases considered the Process Engine and DSS operated within specification in detecting specific collisions between drug classes. The drug codes (by preparation) as prescribed and listed in the CIS were mapped to drug classes and the Jess rules scripted (i) to encode class definitions and (ii) define adverse reaction rules. The latter were drawn from the expert reference and the former from application (CIS) mapping tables. Once the class concepts were defined (schema, Java, or facts), the rules for each adverse reaction alert were trivial (a few lines of text each). The application mappings from a given CIS to drug classes needs done only once per CIS, however we note that a move to standardize medication descriptions (especially in schema form) would largely eliminate this last step. The rules base itself transparently factors into three elements (i) the adverse reaction alerts in standardized form, (ii) the concept definitions (drug class etc.), and (iii) per-CIS drug-class mappings. This leads to easier maintenance.
The tests show, in extension to our earlier work, that an SOA, Web services and BPEL approach to complex DSS in clinical care is feasible and architecturally exhibits useful features in (i) support for service and DSS abstraction; (ii) separation of concerns of clinical workflow, information models and flow, services, and transports; (iii) factoring of DSS concerns (concepts, rules, and application mappings); and (iv) concurrent support for multiple DSS mechanisms behind a common service facade. Although this article focused only on one specific application, the approaches support scalability and generalization at several levels, including drug-condition and related condition/co-morbidity checks.
The HSSP project has identified several services required to support clinical decision support in SOA. With regard to the DSS service, the project seeks to identify a common service interface for how DSS services make their knowledge available to the decision support applications (CDSs). As more functional and technical details become available, we could incorporate work on this area into our propotype.
