PERSONALIZED MEDICAL WORKFLOW THROUGH SEMANTIC BUSINESS PROCESS MANAGEMENT
Jiangbo Dang, Amir Hedayati, Ken Hampel, Candemir Toklu Siemens Corporate Research, Princeton, NJ 08540, USA
[email protected] Keywords: Medical Workflows, Business Process Management, Semantic Web Services, Ontology, Knowledge Base Abstract: Business Process Management (BPM) systems are becoming the runtime governance of emerging Service Oriented Architecture (SOA) applications. They provide tools and methodologies to design and compose Web services that can be executed as business processes and monitored by BPM consoles. Ontology, as a formal declarative knowledge representation model, provides semantics upon which machine understandable knowledge can be obtained, and as a result, it makes machine intelligence possible. By combining ontology and BPM, Semantic Business Process Management (SBPM) provides a novel approach to align business processes from both business perspective and IT perspective. Current healthcare systems can adopt SBPM to make themselves ubiquitous, adaptive, intelligent, and then serve patients better. Our ontology makes our vision of personalized healthcare possible by capturing all necessary knowledge for a complex personalized healthcare scenario including patient care, insurance policies, drug prescriptions, and compliances. This paper presents a hospital workflow management system that allows users, from physicians to administrative assistants, to create context-aware medical workflows, and execute them on-the-fly with the support from an ontological knowledge base.
1
INTRODUCTION
Workflows are becoming ubiquitous in enterprise applications from industry to healthcare. They encompass both system processes and human workflows. Herein, we use the process and workflow terms interchangeably. SOA has become the most praised way to deal with issues in enterprise application integration, such as interoperability, efficiency and system scalability. Semantic Web services, as envisioned by Berners-Lee (Berners-Lee, 1998), are intended to be applied not statically by developers, but dynamically by the services themselves through automatic and autonomous selection, composition, and execution. BPM systems provide methodologies to govern service selection, composition, execution, and monitoring. In this paper, an ontology is developed to describe a healthcare network including hospital resources and processes, and to serve as a knowledge base for our Web-based workflow management system. This ontology provides the semantic layer to BPM applications and helps business rules, enterprise policies, and running environment context be described at the semantic level. Therefore, services
can be described, advertised from a business perspective, and these functionalities can be discovered, and composed by business specialists, instead of IT professionals. Moreover, ontology helps business rules, enterprise policies, and context to be described in a machine understandable way to support adaptive workflow composition and execution. Most existing workflow systems don’t support semantic process design or composition. They are not context-aware and do not support run-time process composition and execution. In contrast, this paper advances the state of the art by (1) developing an ontological knowledge base including healthcare processes, resources, organizations, and compliances; (2) applying semantic to the lifecycle of business processes: from modeling to monitoring, (3)providing a prior knowledge base for task scheduling and resource allocation at semantic level, and (4) bridging the gap between IT and healthcare business. Our system allows users to: (1) create and deploy personalized medical workflow in the run time; (2) control and monitor the process flow that a patient will pass through; and (3) maintain historical process data for further diagnosis. Note that our intended users
are healthcare professionals such as physicians, therapists, nurses, and administrative assistants who have no or little IT background. Our workflow system, together with the ontological knowledge base, will help these users to create, manage, and monitor workflows without intervention from IT people.
2 2.1
BACKGROUND Semantic Web Services and BPM
A workflow can be represented as a set of composed Web services. OWL-S (Web Ontology Language for Services) (Coalition, 2004) is an initiative to facilitate automatic discovery, invocation, composition, and monitoring of Web services through their semantic description. It augments BPEL (Business Process Execution Language) processes with preconditions and results to encode the side effects. BPM systems provide process modeling tools, execution engine, and key performance indicators (KPIs) to monitor and measure end-to-end processes (in BPEL) against operational targets. As discussed in (Noel, 2005), SOA is BPM enabler while BPM is SOA lifecycle governance. BPM address business needs and design flexible processes that are based on services, which can be implemented later with SOA infrastructure. New and changed processes modeled in the BPM may be implemented in the SOA infrastructure more rapidly because the SOA decouples the described service from the specific implementation of particular service. (Laukkanen and Helin, 2003) and (Mandell and McIlraith, 2003) present methodologies for semantic Web service composition.
2.2
Ontology and Knowledge Base
An ontology is a data model that represents a set of concepts within a domain and the relationships among these concepts. A knowledge base may use ontology to specify its structure (entity types and relationships) and its classification scheme. Ontology, together with a set of its instances, constitutes a knowledge base that includes: (1) a set of concepts, properties, and the relationships among them, (2) high-level abstraction of rules in the form of constraints, low-level rules defined with semantic rule markup language such as SWRL (Semantic Web Rule Language) (Horrocks, 2004), (3) semantic service descriptions and (4) a semantic model of event context. A ontological knowledge base builds the metadata needed by a program to understand its environment and status, reason about
them, then this program can composed services automatically to create new tasks, which in turn can be scheduled with optimized resource while complying with business policies and compliances. The MED Global solutions group at Siemens (Dickmann, 2006) has used a methodological approachto describe the different processes accomplished in a hospital. (Emanuele and Koetter, 2006) discussed how BPM and workflow technologies can be applied in healthcare management systems. (ST Liaw and Lewis, 2006) proposed a modeling methodology to define processes and prescribing practice using BPEL. We believe that healthcare systems can adopt BPEL processes, semantic Web services, and ontology when dealing with workflows applied in a hospital. By doing this, these systems can deliver personalized medical workflows to patients, coordinate these workflows to improve the service they deliver, monitor the status of tasks within the workflows and optimize the flow in real-time. This paper aims to present a system to deliver these features. In the rest of the paper, Section 3 introduces a motivating medical workflow scenario. Section 4 discusses the ontological knowledge base. Section 5 describes the system architecture with an emphasis on dynamic process orchestration. Section 6 presents methodology for process monitoring, and Section 7 concludes.
3 SYSTEM OVERVIEW 3.1
A Hospital Scenario
Here we introduce our motivating scenario with a simplified healthcare process. There are five kinds of participant roles in this workflow: RegistrationOfficer, DischargeOfficer, Nurse, Physician, and SupportStuff. For each role, there might be more than one participant (instance). For example, one physician reviews patient’s medical record, while another physician prepares for the operation. The A DMIT phase starts when a patient comes into a hospital, he/she should register himself/herself in a waiting list. An administrative assistant can check the relevant data including insurance information, medical history, patient address, emergency contact, etc. Then the patient will go through the D ETECT phase when a healthcare professional like physician might do some tests, such as blood test or X-ray test. Then, the T REAT phase follows and consists of treating the patient’s disease for instance by applying a surgery and/or a plaster. The last phase is D ISCHARGE when the patient leaves the hospital and all relevant data in-
cluding the processes he/she has been through is gathered and saved for record and future diagnosis. Even with a well defined process reference, it is difficult to handle all events and emergencies in a hospital. From a patient’s view, patient may have to have his/her processes including treatment plan updated from time to time. This uncertainty and dynamics exist because of: (1) newly come findings from test, unexpected outcome from treatment, (2) lack of resource, and (3) emergency. From a hospital’s view, a hospital may want to dynamically route tasks among physicians and resources to provide better care, timely response with minimized cost. Our system provides an intuitive way to users to create and execute a contextaware user-specific process for patients.
3.2
System Interfaces
Fig 2 shows a physician’s task panel. On this page, if is authorized, a user can check patient’s information and medical record, add new observation, diagnosis information, operation suggestion, etc. As shown in Fig 2, the user can access the history of the patients on the middle-top of the page. There is also a process history on the left, where you can browse previous processes. If you log in as a physician, you will have the right to deploy new processes. By clicking on the button ”Deploy or Execute Processes”, a physician can create a new process by choosing and arranging necessary atomic tasks from a task pool, which is validated by the ontological knowledge base. Then the physician can deploy this process by clicking on ”Apply Processes”. All necessary files are created and the process is deployed on the server. After clicking on ”OK”, this process is executed and its status will be updated in real-time.
4 ONTOLOGICAL KNOWLEDGE
Figure 1: User Interface - Worklist
Figure 2: User Interface - Taskpane
Our workflow system provides role-based online access to patients and hospital staffs. As shown in Fig 1, a user can log into the system with the corresponding roles. On his/her personalized welcome page, there is a worklist pane that shows all the pending tasks for the user as well as the in-progress tasks. Using the worklist, the user can claim a task, review the patients which are still in the workflow. More flexibly the user can set his/her working status to allow or avoid newly coming tasks. All the status will be monitored for resource optimization and performance evaluation purpose (detailed in Section. 6).
BPEL is widely accepted as industry standard but it does not provide semantic annotations, which can be exploited by an intelligent software system to automate the selection, composition, and execution of complex processes. The newly published WS-BPEL 2.0 specification does not talk about semantic annotations neither. As our effort toward the direction of Semantic BPM, we have tried to extend current BPM with the support at semantic level by adopting the following methodologies: (1) extending the process groundings from WSDL to WSDL-S, (2) defining an OWL-based process model for process selection and orchestration, and (3) mapping between OWL-S services and BPEL processes. In this paper, we combine (2) and (3), and develop an OWL-based ontological knowledge base to facilitate process orchestration and execution. This ontological knowledge base provides a formal semantic knowledge representation model to capture the hierarchy information and business intelligence behind the described healthcare process hierarchy. By adopting the ontological knowledge base, we separate business rules represented in knowledge base from process logic defined in a process. In Figure 3, we describe healthcare concepts and the corresponding properties from different views: roles, resources, organization, KPIs, and processes. Process view unifies all other views by: (1) consuming assets and people from resource view, (2) specifying actors with roles defined in role view, and (3) providing process activity information and business data to calculate KPIs from the KPI view. We created a process view by separating business rules rep-
DataProperty
e
belongsTo
b integer num
Room
er
Agent
Person Resource
Imaging Device
assignedToRoom
Device
t
Monitoring Device
tie n
nt tie pa
its
Ultrasound
Patient
contains
nce
Xray
hasInsura
rms
er Pa
sV is
Asset
Bed
Admit
Laboratory Device
MRI
hasAllergy precedes
Stretcher
integer
WheelChair
Drug
Allergy ‘s Ontology Process
Detect
consumes
Medical Process
precedes
precedes Treat
PrepPlaster
Plaster
SurgicalOperation
QualityofCare
be num
e rFre
ds Be
patie
ay feredD rans ntsT patie
S ntLO
integer
PlasticSurgery
e integer
Medication
da t
HouseKeeping
av gC os integer tPe rP ati en t
pa t
integer
ien tsD isc date ha rg ed Da y
HeartSurgery
EKGTest
Administrative Process
MRITest
Financial
PatientCost
integer
DptVisitDay
precedes
m ov ab le
boolean
serialNum
assignedToPatient Discharge
BloodTest
XrayTest
MRATest
KPI
integer
AssetUtilization
integer
patientSatisfaction
HealthCare Network
ourc Res
assignedToDpt hasPatients
takesInCharge
perfo
tP
ha
Care
Clinical
integer
integer
People
s rie
ff
ju In
co s
e ye plo
ta lS
cupatio n
Facility
has
Employee Insurance Company
ProcessKPI
Pharmacy
rug
em
ica
TurnoverRate
ed m
diagnosticTurnaround
Hospital
partOf
employedBy
performedBy hasKPI
roomOc
Organization
Pediatrics
ole sR ha
DischargeOfficer
duration
OfD gth
integer
integer integer
topical
Surgery
CardiacSurgery
PlasticSurgery
AdminstrativeStaff
RegistrationOfficer
Orthopedic Therapist
XrayTestAvg
integer
len
Administrating Method
rectal
ObjectProperty
Medical
Radiology
Role
SupportStaff
Nurse
Physical Therapist
integer
integer
inh ala tio n
Emergency
Cardiology
GeneralPractitioner
Healthcare Personal
Surgeon
Plastic Heart Pharmacists
integer
integer
us eo tan cu al or
integer
integer
ha sV alu e
employs
Figure 3: A simplified Hospital Ontology
resented in knowledge base from process logic defined in processes, and adding the semantic layer into the healthcare process reference discussed in Section 3. Processes in this hierarchy are defined in terms of their actors, inputs, outputs, preconditions, and results (AIOPRs). All concepts involved in the process AIOPRs are defined in other views namely resource, role, and organization. Some KPI-related concepts are also defined in the AIOPRs for monitoring. Business rules represent business policies and logics. Ontologies provide a formal semantic model to capture business objects as concepts and business rules behind the described business objects. Properties, constraints, and relations are defined to describe high-level business rules. Meantime, low-level business rules including business logic can be described explicitly with SWRL clauses. We define an ontological healthcare network as the schema of our onto-
logical knowledge base. This knowledge base covers the domains that a healthcare enterprise encompasses - in particular a hospital - from the medical or administrative tasks, to hospital assets, medical insurances, patient records, drugs and regulations. Therefore, it allows this ontological knowledge base to capture all necessary knowledge for a more complex scenario involving patient care, insurance policies, and drug prescriptions, and compliances.
Initiate Processes Patients
PatientRegister Interface
Check/Upadte Patients data
MySQL DB
Hospital Member Interface
Users,Tasks,Patients tables
-Log in/out System -Learn assigned Tasks -Save Output of Tasks
r
a
c
l
e
A
p
p
l
i
c
a
t
i
o
n
S
e
r
v
e
r
ProcessComposition Web Service TaskAssigner Web Service
Oracle BPEL Console
Calls for Process Assignment and Accomplishment
Oracle BPEL Process Manager
Create and Deploy new processes
KnowledgeRetrieve Engine Servlet Jena API
Ontology Uploader Interface
Update Dashboards data
B A M
Check domain’s constraints and relations from the ontology
Maintain BPEL Processes
Monitor processes
O r a c l e
Users
Creates a Process Instance
-Assigns it to a Role -Deploys it to Task Pool Database -Waits for Accomplishment -Send results back to Oracle PM
O
- worklist - task
Compose new processes
S e r v e r
Hospital Dashboards
Protege
OracleXE DB Jena Ontology tables
Upload Ontology in the DB
Maintain/Update Ontology
Figure 4: System Architecture
5 5.1
ADAPTIVE WORKFLOW SYSTEM FOR HOSPITALS System Architecture
As shown in Figure 4, We built our workflow system on Oracle Application Server and Oracle Business Activity Monitoring (BAM) server. In the Oracle Application Server side, we implemented and deployed Web services for process composition and execution. In the Oracle BAM server side, we defined BAM data objects and designed BAM dashboards, and then monitor running processes by pulling data from sensors embedded in the process model. For the system front end, we developed role-based Web interface for hospital users to interact with the system, and use Prot´eg´e (Stanford, ) as the ontology viewer and editor for knowledge maintenance purpose. For the system back end, we adopt Oracle XE database and MySQL database to store the ontological knowledge base and workflow related data separately. The followings are major system components: Task Assigner Task Assigner is the Web service in charge of assigning tasks to the corresponding roles. When a patient registers, our system will automatically generate a patientID for this patient in the database. Personal information of the patient like patientID, name and age are passed to the Task Assigner Web service. These information allows the Task Assigner service to select a role for this task. The task
is then inserted into the taskpool table in the medical database, waiting to be accomplished by the next user who has the proper role. After that Task Assigner checks in the database the status of the task. When it is accomplished, its status field is changed so that the task is marked as finished. The taskpool table keeps track of all the processes being executed or waiting to be executed and to which role they are assigned. As mentioned before, in the current implementation, the service assigns the task to the role by checking the field assignedRole in the table processes. Knowledge Retrieve Engine It extends Jena API (api, 2007) to extract ontological knowledge from our data base. Jena API can be utilized to store and retrieve RDF, RDF Schema and OWL data from a file or a database. It was developed by Semantic Web group at HP Lab and is now available as an open-source framework for the semantic-web community. By combining a Jena query engine SPARQL and an OWL-S API for Jena from Carnegie Mellon University (api, 2004), we developed this knowledge retrieve engine to extract properties, classes, and instances of classes from the OWL specifications in our knowledge base. Meanwhile, we retrieve inputs, outputs, preconditions, and results of a Web service from the OWL-S description, and provide the retrieved knowledge to the process composition service for service selection and composition. Process Composition Service The Process Composition Web service is called once a user has com-
posed his own process and wants to deploy and execute it on the BPEL server. The process composer gets the information concerning the TransactionID, ProcessInstanceID, ParentID, the patient’s name, etc. and the structure information about the newly composed process. And then the service deploys the new process onto the application server after creating all files needed by the BPEL server to properly deploy the process. The last step of the composer is to execute the freshly deployed process on the BPEL server by calling it. At this step, Oracle’s BPEL API is used to generate a unique ID for the process and it is inserted in the ProcessInstanceID element. The ID is returned to the process composer to monitor the status of sub-processes of the composed process. After completion of the dynamic process, this ID is used to construct the tree of linked processes, which allows tracking a patient’s process history for future use.
composer constructs the tree of relationship between the parent process, the context in which the process has been deployed, and the new process. This allows the users to see the history of all the processes that a patient has passed through. In addition, our system maintains a process repository on the BPEL server. This repository allows users to save newly composed processes and reuse them in the future. To enable dynamically composed processes, we design one main BPEL process - the MainPatient process encompassing the business logic of the flow of all processes. The MainPatient process is triggered each time a patient registers with the system. In the MainPatient process, there are four sub-processes in sequential: Admit, Detect, Treat and Discharge . The whole process and all the calls to the subprocesses are asynchronous to allow human interventions. Moreover, we develop a pattern for all atomic processes to make them compos-able using our methodology. Figure 5 shows an example of atomic processes. As you can see, the BloodTest process has the following components: • A receive element receives events as a start point. • An Add Index element, which generates a unique ID for the current instance of the executed process and saves the ID in the Oracle Lite database as an index attribute of the instance. All atomic processes use this element to generate IDs for their instances. In the case of a newly composed process, we use this element to generate ID and retrieve process information by the ID for the process deployed and executed on the server. In addition, we extend it to retrieve the status of the executed processes - whether it is accomplished or not. Moreover, we developed a contextaware process monitoring component, which utilizes this element to attach the newly deployed process to the context in which it was executed.
Page 1/1
Figure 5: BloodTest Process
5.2
Dynamic Process Orchestration
The dynamic process orchestration is one of the core features of our system. Our system makes personalized medical workflow possible by letting healthcare specialists create new medical processes for specific patients without knowing anything about IT infrastructure or BPEL code. This feature can be seen as the first accomplishment to bridge healthcare needs and IT technologies in a hospital. Meanwhile, our process
• An Assign TaskType element updates the coming event (in XML format) by inserting the task name and sending it to the Task Assigner Web service. • An invoke element invokes the Task Assigner Web service that will assign the task to a role, and will call back when the task is done by a user. • An Assign Output element further updates variables sent back by the TaskAssigner Web service. This element implements process-specific logics • Finally, a callback to the requester if it is a newly composed process. By adopting the above pattern, we unify the structure of all atomic processes and make the runtime process composition and execution possible. Each time a
dynamic process is created, the Process Composition Web service generates a unique ID so that the new process can be attached to the context and monitored within the context.
6
DASHBOARDS
Business Activity Monitoring refers to the aggregation, analysis, and presentation of real time information about business activities inside organizations. It is an enterprise solution primarily intended to provide a real-time summary of business processes to business managers and upper management. As such, BAM presents dashboards that contain KPIs that support business analysis and alerts that warn of impending problems. Based on the KPIs, a set of dashboards can be created to monitor running workflows and system performance.The collected performance data can be used to improve the performance. In this section, we briefly describe how BAM needs to be designed and linked to BPEL processes for BAM usage.
6.1
Design BAM objects and dashboards
dashboard with multiple views: Hourly Patients distribution, Average process times, Patient satisfaction.
6.2
Map BAM objects to processes
BAM views depend on information provided by the processes we monitor. Therefore, the linkages between process data and BAM data need to be created. In our system, BAM Data objects are linked to process data via sensors and sensor actions. A sensor is configured in a process to gather data to the BAM server when a BPEL process is triggered. There are several kinds of them: activity, variable and fault. The activity sensors are created to gather process activity information. For instance, one can configure a BAM sensor to send the data of the time when a process is triggered and the time when a process is finished. Then on the BAM server side, a new field in the data object can be added which calculate the duration of the process by subtracting the starting time from the ending time. Variable sensors can send values of variables within a BPEL process to the BAM server during execution time. Sensor actions specify how sensors data are sent to BAM data objects. In addition, an XSLT transformation is defined to map various sensor data to the fields of predefined BAM data objects.
7 CONCLUSION
Figure 6: BAM Dashboards
First, business analysts need to define KPIs that need to be monitored from a workflow. To achieve this goal, BAM data objects are created based on KPIs from our knowledge base. These BAM data objects are created as a set of variables, each of which is composed of multiple fields to store the values of properties of the KPIs. For instance, a field of process starting time and another filed of process ending time can be added and used to calculate the duration of a process. On the BAM server side, these data objects, as a set of tables, will be filled with real-time data extracted from running processes. Dashboards can be designed for different users to monitor these data from different perspectives. Figure 6 shows a hospital main
This paper presents an adaptive medical workflow system with an ontological knowledge base. There are several directions for future work. First, we are going to fully explore semantic Web service description to elaborate the automation process selection and orchestration. Second, we will automate and optimize runtime resource allocation among processes. Third, we will adopt a semantic rule engine to facilitate the knowledge retrieve and reasoning procedure.
REFERENCES (2004). API. http://www.daml.ri.cmu.edu/owlsapi/. (2007). Jena A Semantic Web Framework for Java. http://jena.sourceforge.net/. Berners-Lee, T. (1998). Semantic Web Road Map. Coalition, T. O. S. (2004). OWL-S: Semantic Markup for Web Services. Dickmann, C. (2006). Workflow support in healthcare IT systems. Siemens MED. Emanuele, J. and Koetter, L. (2006). Workflow opportunities and challenges in healthcare. Siemens MED.
Horrocks, I. (2004). SWRL: A Semantic Web Rule Language combining OWL and RuleML. http://www.w3.org/Submission/SWRL/. Laukkanen, M. and Helin, H. (2003). Composing workflows of semantic web services. In Proceedings of the Workshop on Web-Services and Agent-based Engineering. Mandell, D. J. and McIlraith, S. A. (2003). Adapting bpel4ws for the semantic web: The bottom-up approach to web service interoperation. In International Semantic Web Conference, pages 227–241. Noel, J. (2005). BPM and SOA: Better Together. IBM. ST Liaw, E. Deveny, I. M. and Lewis, B. (2006). Clinical, Information and business process modeling to promote development of safe and flexible software. Health Information Journal. Stanford. Prot´eg´e. http://protege.stanford.edu/.
