Based on a generic extensible data access framework (DAF) [10], we devised a domain-speci c extension to support interoperability of Yawl work ow cases with hospital information systems (HIS). In the scenario considered, the HIS is the principal system that keeps master data and clinical data of the patient. Data transfer between HIS and the Yawl runtime environment is facilitated via exchange of standardized HL7 messages. The solution presented supports read and write tasklevel synchronization of work ow variables using the patient's case ID as correlation parameter. A rst proof-of-concept has been carried out in a real clinical setting.
Clinical value chains are in general well-structured and follow an a-priori known execution path. Thus, such scenarios lend themselves to be supported by process aware information systems in general and by business process management systems (BPMS) in particular.
When a BPMS approach is adopted, particular challenges arise if the process engine is external to existing hospital information systems. Patient's master data and visit-related clinical data such as diagnosis and scheduled treatments are usually handled within a HIS, which is the principal system. However, a subset of data is required to be known by the process execution engine to support execution of patient's work ow cases. Conversely, it may be necessary to map process runtime data, such as the duration of activities, back to the HIS. These scenarios call for a data synchronisation solution that integrates HIS with the process execution environment.
In the Perikles project we have introduced an extendable generic data
synchronisation framework (DAF) [
A second extension to Yawl is the FlexY approach [
In this paper we focus on the DAF approach to extend Yawl to handle task-level read and write access to hospital information systems by exchanging standardized messages. The extension described in this paper makes use of Yawl concepts like work ow engine level extensibility (gateway mechanism), automated tasks provided as services, tasks and sub-net variables and parameters based on an XML type system, exible enactment of sub-processes and exception handling. 2
A Generic Data Synchronisation Framework
The current version of the Yawl engine already provides a simple interface to
populate task and net variables using a data source called data gateway. In case
of using a data source some implementation e ort is necessary, because Yawl
provides no standard gateways. To provide a con gurable, policy based
integration of external data sources, we presented a framework called D ata Access
F ramework in [
A1
A2
A3
A4 var:=extVar
var:= fA2(var,...) var:=extVar var:= fA3(var,...) param param param
param extVar:= x extVar:= var extVar:= x
extVar:=var extParam extParam
extParam extParam r(x) w(x) r(x)
w(x)
External Variables Access to data in external sources should be transparent
to the user who models and executes a Yawl process model. Therefor, we
introduce a new variable type external variable in Yawl [
Figure 1 shows the main idea behind the external variable concept. Each variable (c.f. Fig. 1: var) in a process model, can be bound to an external variable (c.f. Fig. 1: extV ar), using a parameter mapping (c.f. Fig. 1: param). To bind an external variable (c.f. Fig. 1: extV ar) to an plug-in, we use a new type of parameter called external mapping (c.f. Fig. 1: extP aram). For each net we can de ne a set of external variables with the type Ext, a set of plug-in id's P lugInID and a set of external parameter mappings extP aramID. De nition 1 (External parameter mapping). (pID; distKey; map; rp; wp), with: A mapping is de ned as pID references a plug-in which should be used, distKey is the key attribute to identify a single XML fragment, map is an XQuery query which de nes the transformation rule between an external variable and the respective data source (with the ID pID), rp is a local read policy (consistent, read-only) for the external variable and wp is a local write policy (consistent, immediate) for the external variable.
In Def. 1 an external parameter mapping is de ned, where pID is used to
identify a plug-in. The disKey and map parameters describe a data item in the
source and the rp and wp parameters are used to de ne the access policies.
Framework Architecture To support external variables within Yawl, we
extend the existing Yawl data gateway implementation with our own data access
gateway [
Adaptation to Clinical Information Systems In healthcare, interoperability between clinical information systems is generally accomplished via exchange of standardized HL7 messages. HL7 messages are made up of segments, elds and delimiters. The MSH segment in the example (cf. Fig. 2) indicates that the message is of type ADT (admission, discharge, transfer) and has been caused by an A01 (patient admission) trigger event. 3.1
Supporting clinical healthcare work ows by Yawl requires integration of given hospital information systems with the process execution runtime. Following our general approach, we have thus extended the existing DAF by an HL7-plug-in to support read/write access of Yawl processes to HL7 enabled clinical systems. The basic architecture of our approach is shown in Fig. 3.
HIS HL7 message files
HL7-XML
Data Access Framework
HL7-XML Plugin YAWL specification YAWL Engine 2.3
Clinical Data
Process
Data Extending the Process Speci cation By utilizing extended attributes one can specify at the task level data synchronization policies for individual variables. These policies instruct the DAF about the mode of the data access (read or write), the correlatable parameter to be used (e.g. the patient's medical case id), the plug-in that handles the request, and an XPath expression that extracts the relevant data from the XML representation of the HL7 message. By calling the plug-in the data synchronisation with HL7 sources is handled for all external variables.
Listing 1 shows an example of a de nition of an external variable. Besides a plug-in ID (pluginID=XML_PostgreSQL_ADT_Extract), the source description is de ned by an SQL table name (xmlColumn=patientdata) together with key attributes (mappingKey=medcaseid,msgtype,datetime) and the selection of an XML fragment (mapping=//patientdata/pv1/patientclass). We also de ne some initial values for two of the key attributes (mappingKeyVal=,A01,[max]) and a table for write access (writeProcess=createHl7[public.hl7out;m1]).
To identify HL7 messages in the database, a number of di erent attributes are necessary, which are used as key attributes. Some of the key attributes are known at design time, like message type or aggregate functions over an attribute. Other attributes are only known at runtime, like medical case ID. These compound primary keys are described by the mappingKey attribute.
Listing 1. External variable de nition e x t V a r p l u g i n I D=XML PostgreSQL ADT Extract e x t V a r r e a d P o l i c y=readOnly extVar xmlColumn=p a t i e n t d a t a extVar mapping=// p a t i e n t d a t a / pv1 / p a t i e n t c l a s s extVar mappingKey=medcaseid , msgtype , d a t e t i m e extVar mappingKeyVal =,A01 , [ max ] e x t V a r w r i t e P r o c e s s=c r e a t e H l 7 [ p u b l i c . h l 7 o u t ; m1 ]
In most cases HIS assume the role of a data source. Upon the occurrence of prede ned events the HIS emits HL7 messages that travel along a message bus or may be exported to the le system. In order to validate our approach in a real clinical setting without running the risk of interfering with production systems, we have used the latter method (cf. Fig. 3).
Since Yawl handles task and case variables as XML data types, every incoming HL7 message needs to be transformed into an XML representation that is compliant to the XML schema of the Yawl process speci cation. Conversely, all outgoing messages must be converted from XML to a proper HL7 representation. Therefore, depending on whether variables are speci ed for read or write access, we use di erent tables for read and write access. We therefore extend the source de nition of an external variable, such that a second source for write access can be de ned (cf. Lst. 1: extVar_writeProcess). These bi-directional message transformations are accomplished by an HL7-XML adapter (cf. Fig. 3). In read mode, the adapter polls the HL7 export le for new messages and transforms any of these into an XML representation. In order to avoid excessive transformations each time a message is accessed, all XML-formatted messages are stored persistently in a database (cf. Fig. 3: Database HL7Messages). 3.2
The validity of our approach for real clinical settings has been demonstrated by a single-day proof of concept (PoC) deployment in a German hospital. Figure 4 shows the principal design. While the PoC has been restricted to read-only synchronization, the gure shows also write-mode use cases that may be relevant for future evaluations. The underlying clinical scenario is a perioperative care ow, which, for the sake of clarity, has been greatly simpli ed.
From the perspective of the treatment layer, each patient follows a sequence of events, beginning with the admission to the hospital end ending with the post-operative transport to the intensive care unit (ICU). While this sequence is strongly aligned with the process layer, there are also important interactions with the hospital information system.
The HIS layer may be viewed as consisting of two distinct components: The patient management system (PMS) keeps the patient's master data such as name, address, gender, and date of birth as well as the visit-related administrative case data. For every visit a patient may make to the hospital, the PMS assigns a medical case ID to this visit. On the other hand, the clinical information system (CIS) is responsible for recording and managing the medical visit-related data, such as diagnosis, lab test results, and the planned treatment. Both subsystems are capable of emitting and receiving HL7 messages in order to communicate business events to other information systems or to process such events that have been emitted by other systems. HL7 messages may contain administrative data only (e.g. in case of an admission or transfer event) or primarily medical information (e.g. in case of communicating lab results).
The process layer has been implemented by the Yawl runtime environment and is thus external to the hospital information systems. The use case evaluated in the PoC required a read-mode synchronization of the work ow instance with the patient's master data as well as the visit-related administrative data, both of which are kept inside the PMS. Upon start of a work ow case, the patient's medical case ID is passed to the process as a parameter. The medical case ID, which is to be distinguished from the work ow engine's case ID, serves as the principal correlation link between the process layer and the clinical information systems. Once the task Supply Master Data and Case Admin Data becomes enabled, synchronization with the HIS layer takes place in read mode such that the required administrative data are extracted from an appropriate HL7 message that has been emitted by the PMS. This information may then be reviewed by the clinician that is executing the task before continuing with Do Surgical Assessment. In this way, synchronization relieves the stakeholders of re-entering the same data twice.
Possible Future Use Cases Data synchronization between process and HIS layer is by no means restricted to the read-only mode. Our approach is also capable of supporting write-mode scenarios that may be interesting from the clinical point of view and that lend themselves for future evaluation. In the gure, we give two motivating examples. In both of which, the work ow case acts as information source and a hospital information system as recipient of that information. Compared with the former scenario, the situation is thus reversed.
The work ow tasks Transfer To OR and Transfer To ICU correspond to events that are relevant from an administrative point of view. So rather than capturing this information twice, it may be desirable to run a write-mode synchronization on completion of these tasks, respectively, to communicate the time stamp of the event to the PMS. In terms of the HL7 messaging concept, this would also amount to automatically executing a transfer patient request inside the patient management system.
The task Do Surgical Procedure may have captured clinical data such as duration and description of the surgical procedure. However, this information may also be required by the CIS. Hence, one could think of enabling the work ow system to write this information back to a HIS layer by sending an appropriate HL7 message to be consumed by the clinical information system.
Process
Layer HIS Layer medical case data
Clinical Information System
Patient Management
System master data & admin case data Treatment
Layer start YAWL case with medical case ID as parameter
SDuaCptaapsl&yeMADdaamstatienr ADsoseSsusrmgiceanlt
Read (admin data)
Message
Files medical case ID known
Do Diagnostic
Tests Do Anesthes.
Assessment s u B e g a s s e M
Write(medical data) Write(admin data) possible future use cases Register Procedure
Transfer To
OR
Do Procedure
Transfer
To ICU
Do Induction Do Surgery
admitted to
hospital
indication for surgical
procedure given
transfered
to OR
surgical
procedure
transfered
to ICU
Yawl is used and extended by several research initiatives including but not
limited to clinical work ows. The framework supports the data patterns de ned by
Russel et al. [
In the context of data-driven processes, di erent approaches for data
integration exist. SIMPLE [
Conclusion In this paper, we present an adaptation to a data synchronisation framework for Yawl and its application to a clinical information system. We showed that an e cient way to access data from di erent clinical information systems during runtime is necessary. We then adapted an existing data synchronisation framework to support accessing these data at the task level. In future, we intend to use Yawl in di erent scenarios supporting also exibility.
Acknowledgments Part of this work has been funded by the German Federal Ministry of Education and Research (BMBF) under grant 01IS099009. We thank Markus Bandt and Viktor Baidinger for their contribution to the implementation. Validation of the key concepts has been done in cooperation with the Hetzelstift hospital in Neustadt/Weinstra e, Germany. The authors wish to thank especially Dierk Vagts and Bernd Wossner for supporting the proof-ofconcept in a real clinical setting.