Volume 24 Article 33
Information Systems and Healthcare XXXI: Improving Infection Control Process Efficiency to Reduce Hospital Acquired Infections
Christian Janiesch
SAP Research CEC Brisbane, SAP Australia Pty Ltd
c.janiesch@sap.com
Robin Fischer
Karlsruhe Institute of Technology (KIT), Universität Karlsruhe (TH)
Inconsistent and incomplete information due to the diversity of isolated information systems is one of the major problems information technology faces in the healthcare sector. The insufficient integration of actors results in delays in clinical processes. However, due to strict constraints in health care such as health regulations, clinical processes cannot be modified freely. The approach of this work is to apply the less radical principles of Business Process Management to medical information systems to provide reliable and timely access to relevant patient information and to decrease process lead time. In particular, this work outlines the impact of optimization for administrative processes. To substantiate our research, we performed a case study in collaboration with a healthcare provider and a regional healthcare facility in the U.S. We report on the workflow implementation of a clinical infection control process which integrates disparate systems and automates clinical decision making according to clinical knowledge. The post-metrics clearly emphasize the capability of Business Process Management to improve the integration of information, increase the quality of patient care, reduce health worker’s stress, and ease costs of treatment by significantly shortening process lead time. We conclude with a generalization of the results for other healthcare enterprises. Keywords: business process management, workflow management, healthcare, infection control, hospital acquired infections
Volume 24, Article 33, pp. 557-570, June 2009
The manuscript was received 10/22/08 and was with the authors 2 months for 1 revision.
Information Systems and Healthcare XXXI: Improving Infection Control Process Efficiency to Reduce Hospital Acquired Infections
Information Systems and Healthcare XXXI: Improving Infection Control Process Efficiency to Reduce Hospital Acquired Infections
558 Volume 24 Article 33
I. INTRODUCTION
Hammer and Champy [1993] see the practice of automating existing processes as paving cow path compared to major Business Process Reengineering (BPR). However, the rather radical approach of BPR is not suitable for all business fields. It requires the freedom to modify organizational structures and free core business processes from non-value adding activities. In business sectors like healthcare, there are a variety of legal restrictions and treatment guidelines practitioners have to comply with [The Medical Letter Inc. 2004; The Medical Letter Inc. 2006]. Hence, freedom to reorganize the organization and to omit non-value adding activities is heavily compromised.
The approach of this work is to introduce the less-radical principles of Business Process Management (BPM) [Becker et al. 2003; van der Aalst et al. 2003] to healthcare and employ those principles to existing medical information systems [Borst et al. 1999; Gardner et al. 1999; Teich et al. 1999]. We performed a case study to show how BPM and information technology contribute to lower the frequency of human errors in healthcare [Institute of Medicine 2001; Kohn et al. 2000]. The case study originates from a customer project in the U.S. The goal of the project was to improve efficiency of the existing controlling process for hospital acquired infections (HAI). Our work outlines the potential for process improvement in administrative processes without reengineering the enterprise. Despite a restrictive environment and legal prerequisites, we show that it is possible to reduce cost, free staff from routine work, and improve patient safety even without changing initial medical treatment processes.
The structure of the paper is as follows: First, in Section II, a short literature review familiarizes the reader with relevant facts on BPR and BPM as well as workflow management. In Section III, we give an introduction to healthcare and clinical processes as characterization of the project. Section IV comprises the case study including details on restrictions in process design as well as a quantitative and qualitative process improvement analysis. The paper closes with conclusions and an outlook on possible further improvements and a generalization to other healthcare facilities.
II. HEALTHCARE AND CLINICAL PROCESSES
Processes
Processes are generally seen as activities performed within a company or an organization [Object Management Group Inc. 2006]. Activities are considered to be the smallest entity used to build a process. These entities may be seen as complex chunks, which do not need to be analyzed further, or atomic activities, which cannot be divided any more. Furthermore, an activity can either refer to work that needs to be done manually, or to work that can be done automatically. Other definitions of processes [Davenport 1993; Johansson et al. 1993] emphasize the timely and local order of activities and also regard different kinds of inputs and value-added outputs. Harmon [2003] considers business goals, which processes are tied to, to be significant for the definition of a process. In the context of this work, we define a process as a completely closed, timely and logical sequence of activities that are required to work on a process-oriented business object [Becker et al. 2003], as this definition integrates the relevant perspectives.
Consequently, we consider a business process as a special process that is directed by business objectives of a company and by the business environment. We further classify business processes into value-creating core processes and not value-adding supplementary processes. Whereas core processes contain corporate expertise and creates products or services that are delivered to customers [Harmon 2003; Porter 1985], supplementary processes facilitate the ongoing operation of core processes [Becker et al. 2003]. This differentiation of core and supplementary processes is not always selective, as one business process might be a core process for one product and a supplementary process for another.
The practice of business process reengineering, which emerged in the early 1990s, employs fundamental rethinking and radical redesign of business processes. In doing so, dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed can be achieved [Hammer and Champy 1993]. This kind of Greenfield project, however, does not consider any existing operational sequences or organizational structures during the construction of new processes at all. Furthermore, it lacks granularity with respect to process hierarchies. BPR targets the overall process perspective in one single shot rather than iteratively and continuously optimizing processes’ performances. Business process management, on the other hand, plans, controls, and monitors intra-
Volume 24 Article 33 559
and interorganizational processes with regard to existing operational sequences and structures in a consistent, continuous, and iterative way of process improvement [Becker et al. 2003].
Workflows
In dependence to processes, workflows can be seen as part of a work process that contains the sequence of functions and information about the data and resources involved in the execution of these functions [zur Muehlen 2004]. This close linkage of a workflow being an automated representation of a business process is also supported by the Workflow Management Coalition (WfMC). The WfMC considers workflows to be an automated representation of a whole or part of a business process. Procedural rules define documents, information or tasks which are to be passed from one participant to another for action [Workflow Management Coalition 1999].
To-be process models are used as sources to implement the workflows; therefore, process models need to be transformed into workflow models. Process models, however, primarily serve organizational (re-)design whereas workflow models focus on implementing IT support. That is why process models integrate functions in a lower level of granularity than workflow models.
While creating workflow models, workflow relevant data is required for the refinement of functions. Consequently, the necessity for a detailed specification of data needed during the execution of activities and data needed to creat e mathematic routing conditions emerges. In order to assign activities to either people or applications, user roles must be created and parameters for application calls need to be defined.
Finally, criteria for when to initiate and when to
terminate a workflow and how to handle errors are to be defined [zur Muehlen 2004].
Workflow Management (WfM) aims at providing this automated process execution where the transitions between the individual activities are controlled by a Workflow Management System (WfMS). So-called business rules may be used to evaluate the state of the workflow and enable appropriate activities by computation or inference based on the data available. Rules can also be used to implement guidelines or mandatory constraints in the overall workflow [Herbst 1997; von Halle 2001]. If an activity cannot be automated, a WfMS is concerned with demanding input from users while providing all necessary information needed to make a decision to those users.
III. HEALTHCARE AND CLINICAL PROCESSES
Healthcare Sector
Healthcare providers are under constant pressure to reduce costs while the quality of care needs continuous improvement [Institute of Medicine 2001]. While expenses for patient treatment and pharmaceuticals rise relentlessly, reimbursements refunded by insurance providers are fixed and coupled to diagnosis-related groups [DiMasi et al. 2003]. Diagnoses related groups allow classifying of patients in segments of comparable diseases. Every group has an assigned basis value for reimbursement. The actual reimbursement is calculated by taking the actual severity of the illness into account [Mast et al. 2004]. Despite these efforts, the healthcare system in the U.S. is the most expensive healthcare system in the world. Health spending as a share of the Gross Domestic Product (GDP) in 2004 has been 16.3 percent, which is almost double the average (8.9 percent) of all countries listed by the Organization for Economic Cooperation and Development [2006].
Information Systems in Healthcare
The historical evolvement of heterogeneous information systems in healthcare may be due to a lack of expertise in implementing systems and missing investment abilities. On the other hand, the rapid development of information technology may also be a reason for the heterogeneous IT landscape in healthcare [Magruder et al. 2005; Wisniewski et al. 2003]. The wish to provide a minimum level of data integration resulted in standards like Health Level Seven (HL7). HL7 defines a standard for the exchange of data between clinical applications. Therefore, HL7 describes clinical events and allows the definition of relevant data, which needs to be interchanged, when the defined clinical events actually occur [Health Level Seven 1998]. In addition, Arden Syntax was also developed under the umbrella of HL7. Arden Syntax defines complex clinical conditions in clinical rules called Medical Logic Modules (MLM) [Shwe et al. 1992]. Each MLM is written in a procedural programming language and stored in single files to enable intra- and interorganizational exchange of medical knowledge [Health Level Seven 2005; Pryor and Hripcsak 1993]. Each MLM consists of multiple slots. The invocation slot, for instance, defines which event triggers the execution of the MLM. Whereas the logic slot defines the criteria that are to be evaluated before an action is executed.
560 Volume 24 Article 33
Clinical Processes
We divide clinical processes into generic process patterns and medical treatment processes [Lenz and Reichert 2005; Panzarasa and Stefanelli 2006]. Both types of processes may be designed and executed cross-department as well as cross-company. Generic process patterns help to coordinate healthcare processes among different people and organizational units. They are essentially administrative processes. Medical treatment processes are the representation of an actual care process, which we consider the core processes of healthcare facilities. These clinical processes highly depend on medical knowledge and case specific decisions [Panzarasa and Stefanelli 2006]. Interpreting patient specific data according to clinical knowledge is the key component of making decisions in clinical processes.
Therefore, medical information systems must supply a recallable representation of clinical knowledge and a consolidated database of patient specific data to provide clinical decision support. The cooperation of clinical knowledge and complex decision support allows the implementation of treatment guidelines in highly flexible clinical processes. Flexibility is required since treatment of patients is likely to differ from patient to patient. Consequently, medical treatment processes need to be quickly adaptable. Medical treatment processes are seen as a diagnostic- therapeutic cycle. Main components of the diagnostic-therapeutic cycle are: observation, reasoning, and action. These stages are iterated until no further action needs to be taken, i.e. the patient no longer requires treatment [Lenz and Reichert 2005].
Infection Control
Infection Control (IC) is the process of preventing hospital acquired infections (HAI) by isolating sources of infections and limiting their spread. Today, HAI are by far the most common complications affecting hospitalized patients or intensive care patients [Borst et al. 1999; Centers for Disease Control and Prevention (CDC) 2004; Teich et al. 1999]. In the U.S. approximately 2 million patients acquire this kind of infections each year and costs are estimated at $4.5 to $5.7 billion per year [Burke 2003]. More importantly, up to 90 percent of deaths caused by HAI are considered preventable [Ricks 2007]. Identification of HAI typically involves testing of specimen in a laboratory. Therefore, nurses need to get a specimen and physicians need to order tests of the specimen. Then if tests are positive, Infection Control Practitioners (ICP) need to ensure that all precautions are occasioned and physicians need to prescribe treatment for the infections.
IV. A CASE STUDY IN BUSINESS PROCESS MANAGEMENT IN HEALTHCARE
Case Study Environment
The present case was performed by Siemens Medical Solutions USA, Inc. (Siemens MED) and a major healthcare facility in the U.S. The facility consists of multiple independent hospitals. More than 7,500 employees are employed at four sites, medical staff consists of about 1,000 physicians throughout the organization. Overall, almost 1,000 beds are available for inpatient care. In the following, the organization is referred to as “customer.”
The scope of the project was to analyze the current IC process, suggest possible improvements through workflow enhancement, and finally advance the current IT solution to increase process efficiency. The uniqueness of this project was rooted in the application service providing (ASP) environment [Dewire 2000; Tao 2001]. Siemens MED does not only provide the clinical software but also the comprehensive IT infrastructure required by the customer, who had never implemented a workflow onsite before.
Analogous to the theoretical exploration in the previous sections, the actual freedom to restructure processes or the organization was found to be heavily compromised by legal restrictions and healthcare guidelines. Although this already became apparent during the first stage of analysis, consensus was achieved to pursue the project even though potential for optimization could not be fully exploited. It was agreed that a workflow focused pilot project would provide essential knowledge for more complex projects to come.
The project started in April with an analysis of the existing processes. Also, pre-measurements were taken from this date. It ended in September with the completion of post-measurements. We designed measurements in a way that enables comparison of turnaround times before and after the implementation of the automated workflow. Build, test, and integration of the workflow needed to be done in just 12 weeks. Table 1 provides an overview of the project phases and the collection of data.
As outlined earlier, this project was done in an ASP environment where the IT equipment for the customer has been provided by Siemens MED. The medical information system used in this project is called Soarian®, developed and distributed by Siemens MED [Siemens AG 2007]. For information on clinical data sources cf. Wisniewski [2003].
Volume 24 Article 33 561
Table 1. Project Plan
Timeline
Phase April May June July Aug. Sept.
Analysis (as-is modeling)
Design (to-be modeling)
Implementation
Testing
Evaluation
Data collection: pre-metrics
Data collection: post-metrics
The Soarian® architecture is a three-tier, client-server architecture built according to principles of a service oriented architecture (SOA). The top layer, web application tier, comprises Soarian® web application servers running the Soarian® User Interface (UI). The application tier, the middle layer, is constituted by Soarian® application servers, a rules engine, and the WfMS. The Soarian® application servers are running the application logic, which is provided by so-called Soarian® Common Components (SCC). The rules engine is a system implemented in Arden Syntax to evaluate medical conditions and recommend possible treatment options. Hence, it represents clinical knowledge stored in MLM. The WfMS used in the Soarian® environment is the third party product TIBCO Staffware Process Suite. Core of this suite is the so called iProcess Engine, which is responsible for the execution and the management of workflow instances. The process suite further consists of a process definer, monitor, and an administration tool to provide a client application development environment. Thus, it enables distributed workflow management. Finally, the third layer, the data tier, is constituted by database servers.
In the project environment, the WfMS can use services provided by SCC to either add and remove items to/from work-lists or add and remove users to/ from census lists. Work-lists and census lists are components of the Soarian® UI enabling the WfMS to alert users in case of required user actions. On the other hand, users of the Soarian® UI are able to trigger events, hence invoke the workflow engine to perform actions on demand. Whereas simple routing conditions can be evaluated by the WfMS itself, complex clinical conditions need to be evaluated with respect to clinical knowledge and patient specific data. Therefore, the WfMS is also integrated with the rules engine. Finally, a Workflow (WF) Event Handler keeps workflows status synchronized with other applications and treatment progress (e.g. recognition of discharge, new order entries, new lab results). Figure 1 illustrates the integration of the TIBCO Staffware Process Suite and the Soarian® environment.
As-Is Analysis
According to the project plan we presented earlier, the first project phase comprised the analysis of the current IC process. Therefore, we conducted interviews with all involved actors (e.g. clinicians, nurses, laboratory workers, and ICPs). The combination of all expert interviews resulted in a comprehensive as-is process model (cf. Figure 2 and Figure 3).
The customer’s infection control process consists of two separate process fragments, synchronized over paper reports. The first part of the process starts as soon as a specimen is tested, if the patient to which the specimen is assigned to is an inpatient at the customer. First, the laboratory needs to screen the test result whether it indicates a positive statement of an HAI. In the laboratory a different information system supports workers to perform this task. Once a worker at the laboratory identifies a lab result indicating a positive infection statement, he directly calls the floor the patient is located on. In doing so, the nurse station is notified about an infectious patient and the responsibility for putting the patient in isolation is passed to the nurse station. Next, the nurse station initiates all necessary tasks to isolate the patient. The first part of the IC process ends, as soon as the laboratory completes the documentation of the lab result in the lab information system. The diagram in Business Process Modeling Notation (BPMN) [Object Management Group Inc. 2006] depicted in Figure 2 illustrates a structured overview of this part of the IC process.
562 Volume 24 Article 33
TIBCO Staffware Process Suite
Process Definition
Tool
Administration
Tool
Monitoring
Tool Workflow Engine(s)
SCC, WF Event
Handler
Soarian® UI Rules Engine
Figure 1. Integration of WfMS into Project Environment
N u
rs e
s ta
ti o
n /
b e
d m
g m
n t
L a
b o
ra to
ry Check lab
result for
infection
statement
yes Notify floor
Incoming
lab result
Complete
documenta-
tion of lab
result
Take isolation
precautions
Lab result
documented
Isolation
initiated
Lab result
Lab result
positive?
no
Figure 2. As-Is Notification Process
The second part of the IC process is rather a controlling process, as each hospital must report the amount of infection occurrences on a yearly basis [Weber et al. 2007]. As for this customer, specific reports for each infectious disease were created on a weekly or even daily basis. These reports are the starting point of the second fragment of the IC process (cf. Figure 3). Once an ICP receives a weekly or daily report of infectious diseases, he screens the report for infectious statement. This task results in a list of patients that need follow-up ensuring that isolation prerequisites are actually taken. During daily tours, the ICP does not only check if infection precautions have been taken for infectious patients but also controls, if the infection statement is transferred to the patient’s chart. If a patient is not put in isolation, the ICP immediately initiates isolation. The ICP does not use any cues to determine the patients, which are to be put in isolation, but follows the report result.
Volume 24 Article 33 563
N u
rs e
s ta
ti o
n /
b e
d m
g m
n t
IC P
Check report
for positive
statement
yes
Verify if
patient is put
in isolation
Every Friday /
weekday afternoon
Initiate
isolation
no
no
All infectious
patients are
isolated
Infection report
Take isolation
precautions
yes
Statement
positive?
Patient in isolation?
Figure 3. As-Is Follow-Up Process
Through the as-is analysis, we externalized the following intrinsic problem domains:
Lack of synchronization: Since reports of infectious diseases are generated only in the afternoon, even on weekends, an ICP only recognizes infections on the weekday the morning after the report has been generated. However, these reports are triggering the execution of the second part of the IC process. Hence, they are critical in time.
No use of information technology: The analysis of the IC process clearly showed that no information technology is used after the ICP has received infection reports. In addition, further investigations indicated that ICP did not have any access to Soarian®, yet.
Excessive time spent screening infection reports and charts: The review of reports and patient charts needs to be done manually as infection reports are printed and corresponding patient charts are not at hand instantly. A sample inquiry performed in collaboration with ICP indicated that screening all necessary documents takes almost 30 percent of ICP’s daily work time.
Involvement of ICP in notification tasks: Even though ICP have responsibility for the handling of infectious diseases, they are not directly participating in the IC process. Further inquiry showed that the former process was to leave a voicemail for the ICP, assigned to the nurse station the patient was located at, as soon as an infection disease was stated. Once the ICP received the voicemail, the isolation of infectious patients was initiated and controlled by the ICP. However, since ICP do not work nights or at weekends this process was changed to directly call the floor and notify ICP only through reports. In doing so, the customer reported faster turnaround times in putting patients in isolation even though notification of ICP was delayed, i.e. the follow-up processes started delayed.
To-Be Design
It became obvious that we could not change personnel capacities. Neither could we increase the involvement of ICP in notification tasks nor could we transfer the controlling responsibilities of ICP to Soarian® due to legal restrictions. The laboratory will still have to notify the nurse station directly, as ICP will not (yet) work during night hours or on weekends. In addition, the customer agreed to not work on further improving the turnaround time for putting patients in isolation, but on the elimination of time wasted while generating, delivering, and reading reports as well as screening patient charts. In doing so, the customer agreed to optimize IC tasks done by ICP without affecting existent clinical and business processes.
Therefore, we focused mainly on synchronizing the infection notification (cf. Figure 2) and the follow-up (cf. Figure 3) fragments of the as-is IC process. We suggested the introduction of a new workflow supported IC process. The
564 Volume 24 Article 33
workflow screens new and modified lab results for statements of infectious diseases. Therefore, we used events defined by HL7. In doing so, we subscribed the workflow to new and modified lab result events (HL7_R01 and HL7_R02). As the case study was a pilot project, the customer agreed to limit the workflow to only cover two infections: Clostridium difficile (CDIFF) and vancomycin resistant enterococcus (VRE). However, the workflow could be extended easily to cover other HAI, such as methicillin-resistant staphylococcus aureus (MRSA), once clinical conditions are identified and MLM are created for an automated evaluation of those conditions.
Figure 4 illustrates both parts of the IC process. According to the agreement made with the customer, we did not change the notification part of the IC process at all; however, the linkage between the notification process and the infection follow-up is made explicit in the to-be process models. We integrated the interface of the notification process and the follow-up process. In doing so, the follow-up process starts immediately after the notification process. Thereby, we save valuable process time by synchronizing both process parts.
More significant changes have been made to the infection follow-up process also shown in Figure 4. We streamlined this process in order to allow efficient automation through the use of a workflow. To achieve the requested level of automation we integrated a WfMS to the process. In addition, the process takes advantage of the fact that ICP are able to access Soarian®, as further IT support is provided in the remaining manual tasks.
The follow-up process is triggered every time a lab result is documented in the lab system. The workflow immediately evaluates the new or modified lab result. Only if the lab result either indicates a positive CDIFF or VRE statement, the workflow will notify the ICP assigned to the nurse station where the infectious patient is located. Hence, ICP will instantly see a new task on their worklist in Soarian®. ICP still need to manually verify whether a patient has been put in isolation, but ICP are now able to access medical records electronically in Soarian®. This enables ICP to work independently of any paper reports or patient charts. Unfortunately, we could not design the workflow to initiate and monitor the isolation of patients automatically due to a missing integration of participating actors (i.e. bed management).
The system could be designed in such a way as no separation of concerns was deemed necessary. The ICP used to check only for positive statements on the lab results. He did not use any additional indicators to determine if a particular patient has to be put in isolation which would have been eliminated with the new setup. In fact, the current system is able to apply much more sophisticated metrics than an ICP would have been able to perform in his daily routine.
Consequently, we established new possibilities for further process enhancement. We designed the to-be infection follow-up process to be executed not only every time a lab result has been documented, but also every time a patient is admitted as inpatient, an inpatient is pre-admitted, an outpatient is kept in hospital for observation or a patient requires emergency care (cf. Figure 4). In each case, the workflow screens the last six months of the patient’s medical record for an occurrence of an infection. If the workflow is able to identify an infection statement within the past six months, the patient is considered to require isolation and the workflow initiates infection precautions. These new characteristics increased the process quality and patient safety in addition to the increase of process efficiency, since many HAI are likely to reappear, if the last infection is more recent than six months.
Volume 24 Article 33 565
IC P
W fM
S N
u rs
e s
ta ti o
n /
b e
d m
g m
n t
L a
b o
ra to
ry
Check lab
result for
infection
statementIncoming
lab result
Patient
admitted*
Complete
documenta-
tion of lab
result
Take isolation
precautions
All infectious patients
are isolated
Lab result
Check report
for positive
statement
yes
Alert ICP
Initiate
isolation
no
Check history
for positive
statement
* covering admissions, pre-admissions, observation patients, and emergency patients
yes Notify floor
Lab result
positive?
Lab results
Statement
positive?
no
Infection report
Verify if
patient is put
in isolation
no
yes
Lab result
documented
Figure 4. To-Be Notification Process and To-Be Follow-Up Process
Implementation
We implemented the IC workflow based on a hierarchical model of procedures and sub-procedures. Thereby, the top level procedure coordinates the overall process flow (cf. Figure 5). The functionality to initiate new workflow instances (e.g., inpatient admit) and terminate existing instances (e.g., patient discharge) is built upon the WF event handler. So called subscriptions, which are basically rules that filter and evaluate selected HL7 events, allow the definition of case generation and case termination respectively. We implemented this workflow according to the to- be process models. Thus, a workflow case is initiated the first time a patient is admitted, pre-admitted, put in an observation bed or in the emergency department. The workflow instance will terminate as soon as the patient is sent home (e.g., discharged).
The purpose of the infection control model workflow is to alert users of Soarian® Clinicals of patients having infectious diseases (i.e. CDIFF, VRE). Therefore, the workflow is designed to immediately check new and modified lab results for patterns indicating a positive statement of an infectious disease. In addition, this workflow checks the medical record for a history of an infectious disease. Alerts on the work lists are created and patients are put on the census list of selected users (e.g. ICP), if a patient has an active indication for isolation. According to the to-be process the infection control workflow is required and triggered by multiple events.
Since every event provides a different set of data, the first three activities (e.g. Start, Get HCU Abbreviation, initialize field values) deal with consolidating data. This ensures that all workflow relevant data is available instantly. The sub- procedures Pt discharge and Pt Discharge Cancelled are used to perform a delayed workflow termination, if the patient was discharged and the discharge was not cancelled within eight hours.
566 Volume 24 Article 33
Figure 5. Infection Control Main Procedure Workflow
Following the path to the VRE infection checking activities, a conditional router (e.g., invoked by VRE result?) evaluates whether a lab result needs to be checked for VRE patterns (e.g., check VRE result) or a patient’s medical record needs to be screened for positive VRE statements (e.g., check VRE history). We encapsulated both, the checking of a lab result and the screening of a historical patient data for infectious statements, in sub-procedures. Thus, relevant data like patient identifiers, visit identifiers, or result values must be passed to the called sub- procedure. Values returned by the sub-procedure must be mapped in the calling procedure. Once the VRE lab result has been evaluated automatically or the medical records have been screened for previous infections without human intervention, another conditional router examines, if a clinical user needs to be alerted or if the patient needs to be added to the user’s census list. We used another call to a sub-procedure to alert users and adding infectious patients to the user’s census (e.g., send VRE notification).
Since the notification sub-procedure stays active until the alerted user confirms the infection alert (e.g., user releases the worklist alert), new lab results may be submitted in between. This behavior creates cases where the alert message needs to be changed or the alert needs to be withdrawn entirely due to new information provided by new lab results. Therefore, we provided functionality to remove or replace alerts. We implemented this functionality by withdrawing created alerts (e.g., withdraw connection of send VRE alert? and send VRE notification) before creating a new alert (e.g., wait for withdraw). Every time the hospital discharges a patient all alerts will be removed and the patient will drop off the user’s census list. If the hospital cancels the discharge for any reason, the workflow restores the status of the last notification.
Volume 24 Article 33 567
Project Controlling
Concurrent to the project realization, data was collected for a detailed analysis of the project outcome. We designed pre- and post-metrics to measure the performance of the IC process before and after the implementation of the workflow supported IC process. Our key metric is time to notification. Time to notification represents the time spent notifying an ICP of a newly identified infectious patient. In doing so, we started the measurement as soon as the laboratory documents a positive lab result. We stopped our time measurement as soon as the ICP had been notified. The ascertainment of notification dates needed to be done manually. Before the implementation of the IC workflow, we asked ICP to write down their dates of notification as soon as they had been notified of infectious patients. After we implemented the workflow, the date of notification was considered to be the date when an ICP acknowledged the automatically created infection alert in Soarian®. Nevertheless, we needed to extract this manually out of workflow audit trails, as there was no automated controlling functionality available. Also, ICP forgot to write down the times or to clear their work-list when they received the notification. Thus, we had to go back and ask for approximate times or had to estimate the time to notification by assuming an ICP’s standard daily routine.
Independent of the measurements of time to notification, we collected additional data in order to identify how much time ICP spent while screening paper reports or patient charts. Therefore, we asked the ICP to additionally write down their hours spent on reading reports and screening patient charts before the implementation of the workflow. Data collection took place over the course of about two and a half months each.
The pre-metrics we report are higher than expected. The post-metrics are still high. This is mainly due to the fact that in particular VRE reports have only been created every Friday afternoon. This means that only those VRE occurrences of past Saturday to Friday would appear on Friday’s report, which is read on the following Monday at the earliest.
Our comparison of pre- and post-metrics shows that we reduced time to notification by more than 75 percent after the implementation of our workflow (cf. Table 2). Time to notification averaged out at 70 hours before the implementation and has reduced to an average of 17 hours after the implementation of the IC workflow. While the time to notification of VRE infections could be shortened considerably, 17 hours on average is still a long time. This is, however, due to process limitations in matters of personnel capacity. There is still no ICP available on weekends or during night hours. Also, ICP are not continuously signed in their Soarian®. So delays for both, CDIFF and VRE, still occur. Nevertheless, we can clearly conclude that substituting the old paper reports based IC process for the new workflow supported IC process greatly increased efficiency.
Table 2. Comparison of Post- and Pre-measurements: Time to Notification (Hours)
N Mean Std. Dev.
Difference Mean
t Sig. (2-tailed)
VRE (pre) 17 150.00 42.71 129.33 (86.22 %)
9.107 .000 VRE (post) 10 20.67 16.88
CDIFF (pre) 34 29.68 17.64 14.00 (47.17 %)
3.498 .001 CDIFF (post) 28 15.68 12.91
Combined (pre) 51 69.79 63.80 52.80 (75.66 %)
5.006 .000 Combined (Post) 38 16.99 13.99
VRE = Clostridium difficile CDIFF = Vancomycin resistant enterococcus The reported univariate skewness and kurtosis statistics for each scale item are not exceeding the thresholds (skewness < 2 and kurtosis < 7) as suggested by Stevens [2001] and point to a normal distribution. Equal variances are assumed.
ICP spent an average of 30 percent of their daily work time on screening infection reports and patient charts. We decreased this effort to almost zero after the implementation of the workflow, since required patient information is now available instantly through Soarian®.
We want to accentuate, that we not only significantly improved the IC process on a quantitative perspective but also, and maybe even more importantly, on the qualitative perspective. We achieved major improvements to patient safety through the implementation of HAI history screening, as the workflow now screens every patient for a positive history (in the last six months) of infection statements. Furthermore, the process quality has been improved through reducing the risk of human errors, since ICP no longer rely on manually generated paper reports or voicemails. Finally, with the implementation of the workflow, we greatly contribute to the process of getting health workers,
568 Volume 24 Article 33
especially ICP, online. The automated IC process functioned as an incentive to overcome the negative attitude some health workers have concerning IT in inpatient care [Doolin 2004].
V. CONCLUSION AND NEXT STEPS
In this paper, we presented reasons for the inappropriateness of Greenfield project approaches, like BPR, for the optimization of clinical processes in healthcare. Both from on a conceptual and a practical perspective, BPM appeared to provide the desired cost reduction, increase in patient safety, and relief for health workers in matters of routine tasks. Furthermore, we discovered significant potential for automating coordination and evaluation tasks (e.g. calling floors and screen charts) and consequently contributed to patient safety, too.
As we presented in our process analysis, the implementation of the new workflow supported IC process improved quality greatly and increased efficiency as well as patient safety. However, the average time to notification of 17 hours is still high. This is mainly due to two facts: First, ICP do not work during night hours or on weekends; second, ICP are not continuously signed on to Soarian® during work hours as they need to be on the floor as well.
A simple solution to uncouple ICP from being continuously signed on is to use pagers, cell phones, or even personal digital assistants (PDA) to notify ICP of infectious patients. This could be used in addition to the work-list of Soarian®. We see additional possibilities to further decrease the time to notification in the implementation and delegation of on-call duties for ICP once paging. ICP could take their pagers home and perform simple follow-up tasks over the phone while working from home.
Finally, we see additional space for process improvement in integrating more actors into the IC process. Currently, the laboratory still needs to call the floor directly. This process could be handled by an extended IC workflow which would automatically notify nurse stations through pagers, PDA, or tablet computers. Other follow-up tasks could be integrated: Reminding the floor to put the patient in isolation after a given amount of time; or escalating the order for isolation to the designated physicians. Extending the workflow to more and more participants of the IC process could, finally, result in a companywide standardized automated IC process. In a more comprehensive approach, even digital door plates could be used to indicate isolation of infectious patients at the entry of every room. In doing so, the implementation IC workflow could actively reduce the risk of infection of nonclinical actors like visitors or patients.
With an enhancement like this, additional patient safety measures would be possible such as screening for a Typhoid Mary. If it was possible to extract traces and/ or contacts of a patient or nurse, an infectious (though eventually healthy) person could be singled out. This would further stop preventable infections. In our case, generating a list of patient contacts may have been possible but was not attended to.
The results from this case study can be generalized to other healthcare facilities and HAI. First, the results are rather independent of the HAI. As long as the specimen can be tested and infections can be inferred in a similar way, it does not matter whether we look at CDIFF, VRE, MRSA or any other HAI. The improvement in IC, quantitatively and qualitatively, was not achieved by testing infections more efficiently but by shortening and enhancing the generic process patterns around the realization of an infection. While we only looked at IC processes, there are other generic process patterns in healthcare which have potential for process improvement. Examples in related projects included but were not limited to patient discharge processes including discharge letters and risk factor analysis for congestive heart failure. Second, the results can be transferred to any healthcare facility with a similar organizational setup. The significant improvement in process lead time was achieved by applying BPM principles to an already existing clinical process which has to exist in every U.S. healthcare facility. Thus, we would assume similar savings for any facility with a comparable setup of the ICP. This implies in particular ICP, who do not work 24/7 shifts but have a regular eight-hour working routine without night or weekend duty. We deem generalizing the results to IC processes outside the U.S. possible, if similar IC measures to an ICP are in place.
REFERENCES
Becker, J., M. Kugeler, and M. Rosemann. (eds.) (2003). Process Management: A Guide for the Design of Business Processes, (1st edition), Berlin: Springer.
Borst, F., R. Appel, R. Baud, Y. Ligier, and J. R. Scherrer. (1999). “Happy Birthday DIOGENE: A Hospital Information System Born 20 Years Ago,” International Journal of Medical Informatics (54)3, pp. 157-167.
Burke, J. P. (2003). “Infection Control: A Problem for Patient Safety,” New England Journal of Medicine (348)7, pp. 651-656.
Volume 24 Article 33 569
Centers for Disease Control and Prevention (CDC). (2004). “National Nosocomial Infections Surveillance (NNIS) System Report, Data Summary from January 1992 through June 2004, Issued October 2004,” American Journal of Infection Control (32)8, pp. 470-485.
Davenport, T. (1993). Process Innovation: Reengineering Work Through Information Technology, Boston, MA: Harvard Business School Press.
Dewire, D. T. (2000). “Application Service Providers,” Information Systems Management (17)4, pp. 14-19.
DiMasi, J. A., R. W. Hansen, and H. G. Grabowski. (2003). “The Price of Innovation: New Estimates of Drug Development Costs,” Journal of Health Economics (22)2, pp. 151-185.
Doolin, B. (2004). “Power and Resistance in the Implementation of a Medical Management Information System,” Information Systems Journal (14)4, pp. 343-362.
Gardner, R. M., T. A. Pryor, and H. R. Warner. (1999). “The HELP Hospital Information System: Update 1998,” International Journal of Medical Informatics (54)3, pp. 169-182.
Hammer, M. and J. Champy. (1993). Reengineering the Corporation: A Manifesto for Business Revolution, New York, NY: HarperBusiness.
Harmon, P. (2003). Business Process Change: A Manager’s Guide to Improving, Redesigning, and Automating Processes, San Francisco, CA: Morgan Kaufmann.
Health Level Seven. (1998). Health Level Seven Implementation Support Guide for HL7 Standard Version 2.3, http://www.hl7.org/special/ig/final.pdf (current 2008-10-20).
Health Level Seven. (2005). Arden Syntax for Medical Logic Systems, Version 2.5, http://www.hl7.org (current 2008- 10-20).
Herbst, H. (1997). Business Rule-Oriented Conceptual Modeling, Heidelberg: Physica.
Institute of Medicine (2001) Crossing the Quality Chasm: A New Health System for the 21st Century, Washington, DC: National Academies Press.
Johansson, H. J., P. McHugh, A. H. Pendlebury, and W. A. Wheeler. (1993). Business Process Reengineering: Breakpoint Strategies for Market Dominance, Chichester: Hohn Wiley & Sohns.
Kohn, L. T., J. M. Corrigan, and M. S. Donaldson. (eds.) (2000). To Err Is Human: Building a Safer Health System, Washington, DC: National Academy Press.
Lenz, R. and M. Reichert. (2005). “IT Support for Healthcare Processes,” in Proceedings of the 3rd International Conference on Business Process Management (BPM). Lecture Notes in Computer Science Vol. 3649, W.M.P. van der Aalst, B. Benatallah, F. Casati, and F. Curbera (eds.), Nancy, pp. 354-363.
Magruder, C., M. Burke, N. E. Hann, and J. A. Ludovic. (2005). “Using Information Technology to Improve the Public Health System,” Journal of Public Health Management and Practice (11)5, pp. 123-130.
Mast, P., U. Ochs, W. Loewe, and K. Weise. (2004). “Aktueller Stand in der Fallkostenabrechnung nach DRG: Sicht des Finanzcontrollers,” Trauma und Berufskrankheit (6)Supplement 1 May, pp. 95-96.
Object Management Group Inc. (2006). Business Process Modeling Notation (BPMN) Specification 1.0, http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec%2006-02-01.pdf (current 2008-10-20).
Organisation for Economic Cooperation and Development (OECD). (2006). OECD Health Data 2006: How Does the United States Compare? http://www.oecd.org/dataoecd/29/52/36960035.pdf (current 2008-10-20).
Panzarasa, S. and M. Stefanelli. (2006). “Workflow Management Systems for Guideline Implementation,” Neurological Sciences (27)Supplemental 3, pp. 245-249.
Porter, M. E. (1985). Competitive Advantage: Creating and Sustaining Superior Performance, New York, NY: The Free Press.
Pryor, T. A. and G. Hripcsak. (1993). “The Arden Syntax for Medical Logic Modules,” International Journal of Clinical Monitoring and Computing (10)4, pp. 215-224.
Ricks, D. (2007). “Germ Warfare,” Ms. Magazine (31)2, pp. 43-45.
Shwe, M., W. Sujansky, and B. Middleton. (1992). “Reuse of Knowledge Represented in the Arden Syntax,” in Proceedings of the 19th Annual Symposium on Computer Applications in Medical Care, Washington, DC, pp. 47-51.
570 Volume 24 Article 33
Siemens AG. (2007). Soarian®, http://www.soarian.com/ (current 2007-06-20).
Stevens, J. P. (2001). Applied Multivariate Statistics for the Social Sciences, 4th edition, Hillsdale, NJ: Lawrence Erlbaum Associates.
Tao, L. (2001). “Shifting Paradigms with the Application Service Provider Model,” IEEE Computer (34)10, pp. 32-39.
Teich, J. M., J. P. Glaser, R. F. Beckley, M. Aranow, D. W. Bates, G. J. Kuperman, M. E. Ward, and C. D. Spurr. (1999). “The Brigham Integrated Computing System (BICS): Advanced Clinical Systems in an Academic Hospital Environment,” International Journal of Medical Informatics (54)3, pp. 197-208.
The Medical Letter, Inc. (2004). “Choice of Antibacterial Drugs,” Treatment Guidelines from The Medical Letter (2)19, pp. 13-26.
The Medical Letter, Inc. (2006). “Treatment of Clostridium Difficile-Associated Disease (CDAD),” The Medical Letter on Drugs and Therapeutics (48)1247, pp. 89-90.
van der Aalst, W.M.P., A. H. M. ter Hofstede, and M. Weske. (2003). “Business Process Management: A Survey,” in Proceedings of the 1st International Conference on Business Process Management (BPM). Lecture Notes in Computer Science Vol. 2678, W.M.P. van der Aalst, A. H. M. ter Hofstede, and M. Weske (eds.), Eindhoven, pp. 1-12.
von Halle, B. (2001). Business Rules Applied: Building Better Systems Using the Business Rules Approach, New York, NY: Wiley.
Weber, S. G., S. S. Huang, S. Oriola, W. C. Huskins, G. A. Noskin, K. Harriman, F. N. Olmsted, M. Bonten, T. Lundstrom, M. W. Climo, M.-C. Roghmann, C. L. Murphy, and T. B. Karchmer. (2007). “Legislative Mandates for Use of Active Surveillance Cultures to Screen for Methicillin-Resistant Staphylococcus Aureus and Vancomycin-Resistant Enterococci: Position Statement from the Joint SHEA and APIC Task Force,” Infection Control and Hospital Epidemiology (28)3, pp. 249-260.
Wisniewski, M. F., P. Kieszkowski, B. M. Zagorski, W. E. Trick, M. Sommers, and R. A. Weinstein. (2003). “Development of a Clinical Data Warehouse for Hospital Infection Control,” Journal of the American Medical Informatics Association (10)5, pp. 454-462.
Workflow Management Coalition. (1999). WFMC-TC-1011 Ver 3 Terminology and Glossary English, http://www.wfmc.org/index.php?option=com_docman&task=doc_details&gid=93&Itemid=74 (current 2008-10- 21).
zur Muehlen, M. (2004). Workflow-based Process Controlling: Foundation, Design and Application of Workflow- driven Process Information Systems, Dissertation, University of Münster, Berlin: Logos.
ABOUT THE AUTHORS
Dr. Christian Janiesch is a researcher at SAP Research CEC Brisbane at SAP Australia Pty Ltd. He earned his Ph.D. in Information Systems from the European Research Center for Information Systems (ERCIS) at the University of Münster and has an MSc and a BSc in Information Systems also from the University of Münster. Christian visited Queensland University of Technology (QUT) in Brisbane, Università della Svizzera Italiana (USI) in Lugano, and SAP Research CEC Karlsruhe during his studies. He published mainly in the areas of process management, conceptual modeling, and method engineering for Business Intelligence and Enterprise Systems. His work has appeared in AIS Transactions on Enterprise Systems, International Journal of Interoperability in Business Information Systems, International Journal of Information Systems and Change Management as well as various international conferences.
Robin Fischer is a Ph.D. student at Karlsruhe Service Research Institute (KSRI), Universität Karlsruhe (TH), Karlsruhe Institute of Technology (KIT). He holds an MSc and a BSc in Information Systems from the University of Münster. Robin’s research interests are primarily in Business Process Management and Service Value Networks.
Copyright © 2009 by the Association for Information Systems. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than the Association for Information Systems must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or fee. Request permission to publish from: AIS Administrative Office, P.O.
Box 2712 Atlanta, GA, 30301-2712 Attn: Reprints or via e-mail from ais@aisnet.org.