Introduction

The Intensive Care Unit (ICU) of a hospital is an extremely data intensive environment. With the emerge of information technology the monitoring data from medical devices, laboratory results, electronic prescriptions and therapeutic decisions, clinical observed values by physicians and nurses are captured in electronic medical records in clinical information systems. In Flanders, Belgium 65% of all ICUs used an electronic patient record, 41.3% a computerized physician order entry system, and 27% a computerized medication administration record in 2008 [1]. Initially electronic records were only used to store the registrations and for financial and administrative purposes. According to Lin et al. physicians’ resistance to adopt health information systems was driven by low involvement in the design of user interfaces and the documentation of the systems [2]. A study to benchmark electronic medical records initiatives in the US, showed an increased adoption of medical records between 2005 to 2007 [3]. With the presence of high data volumes of clinical data, automated decision support, infection surveillance and antibiotic management have become important challenges.

Automated clinical decision support, based on the individual patient’s conditions in the electronic records, can support the physicians in their medical actions. Examples of existing services include a service to alert for kidney dysfunction [4] based on laboratory parameters, a service calculating the Sequential Organ Failure Assessment Score (SOFA) as outcome score [5] and a service giving antibiotic advice [6]. Infection surveillance comprises on-going, systematic collection, analysis and interpretation of health data [7]. Especially in ICUs, infections are an important concern. The ICU is clearly the epicenter of the nosocomial infection (NI). In Belgium the prevalence of NIs in the ICU is estimated on 25% based on the number of infections [8]. A nosocomial infection is an infection for which there is no evidence that the infection was present or incubating at the time of hospital admission [7]. Symptoms usually appear after 48 hours of admission. These infections are highly associated with antimicrobial resistance.

Antibiotic resistance is the resistance of micro-organisms against several antibiotic medications. Policy regulations were introduced to reduce the improper use of antibiotics in several hospitals. An example is the adjustment of the antibiotic dosage.

The existence of electronic records facilitates the automation of clinical decision support by replacing the manual time-consuming analysis. However, current information systems do not offer an integrated view and analysis of all data present in the ICU, as data exists in stand-alone vendor-specific applications. As such, the physician has to consult all applications before being able to make a decision. There is a lack of an integrated patient record, and still the metadata and therapy intentions of the physician are missing in the electronic record, making clinical handover difficult. During clinical handover, the conditions and therapies of the patients are discussed between physicians. This diagnosis for infection and initiated therapy is not captured by the information systems.

The COSARA research project (Computer-based Surveillance and Alerting of nosocomial infections, Antimicrobial Resistance and Antibiotic consumption in the ICU) aims at the registration and integration of infection-related data of the individual patient. COSARA targets the extraction and integration of clinical data and provides a visually attractive presentation of infections, antibiotics and clinical results of the ICU patient in real time. Moreover, it offers data analysis for clinical studies. The client application consists of modules with infection overview, chest X-ray, antibiotics overview, microbiology results, linking and registration, catheters overview. A management view is created for statistics and quality improvement. This secondary use of data was previously not possible because existing electronic medical records typically do not track ICU-specific syndromes, care processes or outcomes [9].

The related work is summarized in Table 1. It includes recent research in which the focus is on infection control. Most of these research prototypes also prefer a service-oriented architecture in their design, in which independent functionality is designed as a service. Few ICUs have developed an integrated data warehouse [10, 11]. The COSARA service platform integrates the clinical sources, provides decision support and presents all relevant processed data on bedside client or nurse workstation.

Table 1 Related work of recent infection surveillance platforms
Full size table

This paper presents the COSARA research project at the ICU of Ghent University Hospital, an ICU with 56 beds and around 4,000 annual admissions. The objective of this paper is to address the integration of heterogeneous patient data sources in ICU in one system, create an overview for infection control and daily follow-up and a complete data warehouse for clinical research. This paper addresses the following research questions: What are the functional requirements of the integrated service platform? What platform components are necessary in its design? What are the evaluation results of the deployment at the hospital? The multidisciplinary involvement of physicians and software engineers in the development process, with the use of web services and client modules led to a successful implementation with promising initial results [5].

This paper is structured as follows. In section 2 a functional overview of the platform is given, section 3 describes the platform components and implementation details are described in section 4. Platform scenarios are presented in section 5. Evaluation results of data performance and validation are shown in section 6.

COSARA functional overview

This section provides an overview of the main functional requirements of COSARA in order to deliver monitoring, follow-up and decision support at the patient level and extended management and reporting facilities at the unit or management level. Figure 1 shows the ICU setting of COSARA.

Fig. 1
figure 1

Overview of the COSARA ICU setting with data flow from clinical sources and physician’s registrations, processing in the services platform and output to smartphone, bedside PC and nurse workstations

Full size image

  • Automatic Integration of Clinical Data: Data from a range of different data sources is continuously automatically extracted and integrated in a clinical data warehouse COSARA, including the Intensive Care Information System (ICIS), the LabView-interface with access to the GLIMS Laboratory System, the X-ray photos in the Picture Archiving and Communications System (PACS). ICIS stores all data from monitors (ex. heart frequency, blood pressure), ventilators, observations (ex. placement of dialysis catheter, temperature measurement, urine output). Laboratory results (such as results of blood samples, detected bacteria, antibiogram) can only be accessed in the LabView application. Every patient’s X-ray chest photos are requested from PACS. Previously, multiple existing vendor-specific applications had to be accessed before the physician was enabled to make a complete diagnosis and decisions. With COSARA, additional metadata of the antibiotic prescriptions is also collected. Each time an antibiotic prescription is made, the physician’s motivation for starting a therapy is registered in real-time by using a pop-up screen. COSARA permits the physician to review the microbiology history of the patient. Laboratory results from the patient’s ICU admission as well as results from outside the ICU are collected (for example, results from up to 10 days before admission are also available in COSARA).

  • Presentation and Clinical Interpretation: Infections and antibiotics data are presented in an up-to-date client as charts, visual bars on time lines and graphs. It gives the physicians an attractive real-time overview of all infections, the chosen antibiotic therapy and associated microbiology with cultures and antibiograms. Physicians can link the data and reconstruct their decision making process in the application. Links between all data that influenced the therapy decisions are made.

  • Clinical Decision Support Services: The decision support logic is available as services and rules in a service-oriented architecture. Guidelines form the basis of the service logic [16]. The decision support services include a service to identify patients who receive prolonged antibiotic therapy (AB Prolonged), who receive inappropriate drug doses (AB Dose), who can switch from intravenous to per os antibiotics (AB IV/PO). These services assist the physician with suggestions on mail or in text message to optimize antibiotic management in the ICU.

  • Autonomous System Detection and Recovery: Data gaps and unusual parameter values are detected in the extracted data. Data gaps can be caused by a link outage, communication failure, or failure in the services or originating system. A monitoring interface (of for example antibiotic prescriptions) shows if platform support is needed. Data and service recovery mechanisms have to be taken into account to limit possible downtime and to recover all data.

  • Alerting of Alarming Trends: Timely interventions are crucial in the ICU. Therefore physicians should be alerted if patient conditions show an alarming trend.

  • Management and Reporting: With the presence of a new integrated database, data can be used for reporting, research and data mining. This may lead to the discovery of new infectious patterns or new insights in therapy decisions

Platform design

The COSARA platform components are shown on Fig. 2, structured in components for the COSARA client, the platform services, data mashup services, the data resources and the business logic. COSARA integrates different data sources in one single application. First, data is continuously collected and transferred to the COSARA platform by the Data Collection Services. These services invoke the Data Lookup Service (DLS). The DLS web service allows transparent access to the data sources (ICIS, GLIMS). It uses logic names for all data retrievals and hides the specific queries from the end user. The different database structures require a preprocessing step in the Transformation Services before storing the values in the relational database COSARA. The process differs from direct replication because only a selection of relevant values related to infections and antibiotic therapy are included. Other results such as microbiology reports and antibiograms need a parsing transformation step from text-based report to structured format of the susceptibility tests. The synchronization between the originating sources and the newly created database is a continuous real-time process. To ensure data quality in the client application, the database has to match the originating sources at all time. The Data Synchronization component periodically invokes the data collection services to gather the data. Synchronization is performed through a polling mechanism in which the databases are checked for new data in a recent time window. Polling was chosen because the vendor-specific external systems did not provide an interface for triggers as push-based mechanism. The chest X-rays are also retrieved with a polling mechanism which retrieves metadata and thorax photo. The synchronization service also checks if the data remains constantly in sync. If not, Recovery Tools provide a recovery mechanism of the data services or platform services and in case of detected failures it recollects all missed data.

Fig. 2
figure 2

Design of the COSARA platform with client, platform services, data sources, data mashup services and business logic

Full size image

The COSARA client provides access to a complete patient overview. This client is composed of Modules, such as infection overview, which is discussed in detail in section 5 in the platform scenarios. When the client is started from bedside PC or nursing workstation, the modules are loaded from the Module Manager on the client. In the Client Configuration the availability of modules can differ depending on the workstation or physician’s specialization. For example, the management module is only shown to the medical staff while this module is hidden from nurses and physicians.

The client modules interact with the server-side Business Logic Services, which include thorax service, microbiology service, infection linking and registration, admission comorbidity, admission reason and admission diagnosis and antibiotic service. The Thorax Service calculates the CPIS score and handles the integration with the PACS database by requesting and filtering all ICU patient studies. The service queries for X-ray chest photos using the Digital Imaging and Communications in Medicine (DICOM) standard and caches the photos with its meta-data, after transforming them into JPEG-format. The Microbiology Service stores the sample orders, specimen, detected culture and antibiograms. The Infection Linking and Registration Service handles the linking of all related data in the system. The Comorbidity and Admission Reason and Diagnosis Service allows the registration of admission information, data that is not available today. The Antibiotic Service handles the processing of the prescriber’s intentions in the antibiotic pop-up.

The Desktop Integration component integrates the COSARA client with the bedside ICIS client. When these two applications (COSARA and ICIS-client) are running, a switch in the patient selection in ICIS, automatically changes the selected patient in COSARA. This minimizes the client interactions. The patient selections are handled in the Subject Manager.

The platform services also include Monitoring and Logging and Event Notifications. These services can both be used for medical actions and for maintenance of the platform. Interruptions of the antibiotic pop-up service or interruptions in data from external sources can be monitored on a web-based display that shows the rate of complete antibiotic prescription pop-ups and data gaps in the system.

Implementation details

For the platform design the service-oriented architecture (SOA) was chosen due to the advantages of reuse, rapid integration and flexibility. The services are deployed on a JavaEE Application server Glassfish. The application container contains Enterprise Java Beans (EJBs), Web Services and Business Process Execution Language (BPEL) interaction flows. EJBs are modular components that encapsulate business logic of the application at the server-side. The application server, on which these components are deployed, provides a persistence mechanism that stores entities (data objects) directly in the database through a persistence mapping. As such the data instances of objects are mapped on records in a database table. The application server also offers a security service, timer service and transaction processing. The server has already been widely used in eCommerce applications. A detailed description of the Enterprise Service Bus (ESB), that defines the communication infrastructure between services for routing medical data is given in [17].

The COSARA client is composed of modular components. OSGi (Open Service Gateway Initiative) offers a programming model in which the modules are loaded at runtime, without restart of the application and platform. Benefits of OSGi are the hot-swappable plug-in architecture, high reusability and efficiency [18]. The OSGi Base is Apache Felix, which implements the OSGi R4 Service Platform. OSGi is the framework for Java in which units of resources (referred to as bundles) can be installed. Bundles export services or run processes, and have their dependencies managed. A bundle can be expected to have its requirements managed by the container. Each bundle can serve as an independent unit. This modular update mechanism minimizes the maintenance effort on the 56 bedside PCs and nurse workstations. Using OSGi, updates of the programmed modules can be installed across all bedside PCs with minimal or no human interaction.

The clinical data is stored in a MySQL database. The amount of data of one year is shown in Table 2, which presents the data categories in COSARA, number of records and originating source. The Intensive Care Information System (ICIS) stores data in a Sybase database, the Laboratory system stores data in an Oracle database, and the Picture Archiving and Communication System (PACS) stores the thorax images in files that include also meta-data of the patient and the image.

Table 2 Yearly number of data records in COSARA (April 2010–2011)
Full size table

Platform scenarios

This section details scenarios of the application of COSARA in the ICU of Ghent University Hospital.

Daily patient-specific follow-up of infections and therapy

Figure 3 shows the patient-specific overview, as consulted on the bedside screen or central nursing workstation. It has graphs (with thrombocytes and temperature (A), CRP and WBC count (B), SOFA scores (C)), time line (D) with antibiotics, infections and microbiology access icons, and a details view (E) which displays extra information when the cursor if moved over the timeline. The physician has access to the complete history and current parameters of the patient. When a new antibiotic is prescribed in the intensive care information system, a pop-up appears on the screen to register the prescriber’s motivation for starting or changing the antibiotic therapy. In the pop-up the diagnosis is associated with laboratory results such as new detected bacteria or the antibiogram with antimicrobial susceptibility tests of antibiotic resistance. Immediately after prescription, a time bar with the antibiotic prescription is visually shown on the screen. Both antibiotic therapies and infections can be seen in one view. With a few clicks all other related data (microbiology, antibiogram and responsible culture) can be linked with the current therapy. During handover between physicians, all previous decisions can be reconstructed easily.

Fig. 3
figure 3

Screenshot of the infections and antibiotics overview in the COSARA client on the ICU bedside PC with graphs (thrombocytes, temperature (A), CRP, WBC count (B), SOFA scores (C)), a time line (D) and details (E)

Full size image

Daily patient-specific follow-up of patient’s chest x-rays

The thorax module shows the patient’s chest X-rays (Fig. 4(A)). It has a timeline (C) which includes all photos transcoded from the PACS system. During weekly photo staff meetings all photos are discussed. Based on the input (B) from the physician, such as if a new or grown infiltrate and if the acute respiratory distress syndrome (ARDS) is observed, the thorax service automatically calculates the Clinical Pulmonary Infection Score (CPIS) and presents it in the client (B). Besides visual symptoms of pneumonia, part of this score is calculated based on clinical signs [19]. The following parameters are taken into account: temperature, leukocytes, presence and aspect of tracheal secretion (sputum), oxygenation, culture of tracheal aspirate (microbiology) [19, 20]. These parameters are automatically collected from the clinical information database by the COSARA platform. By interpreting the X-rays during the photo staff meeting clinicians enter the visual observation of infiltrates on the application. The Clinical Pulmonary Infection Score (CPIS) has been used in ICU as a decision research tool for initiation of antibiotics in suspected ventilator-associated pneumonia (VAP) and also for discontinuing antibiotics if the CPIS is lower than 6 on day three of the therapy, relying on the available clinical, radiographic observation and microbiology criteria, but is not common in clinical use [20].

Fig. 4
figure 4

Screenshot of the chest X-rays (A,C) with feedback form (B), retrieved from the PACS system, in the COSARA client

Full size image

There are also modules for microbiology, antibiotic therapy, admission cause with comorbidity and admission diagnosis, infection linking and registration, feedback and catheters overview. The microbiology module shows the antibiotic susceptibility reports (antibiograms) and a list of lab sample results. The antibiotic therapy module provides a historical overview of all given antibiotics to the patient. In the linking module, the physician can link the patient’s infections with the found micro-organisms and the given antibiotics. Feedback about the application can be collected in the feedback module. The catheters module provides an overview of all catheters.

Infection management on ICU unit

The management client (Fig. 5) offers statistics on the incidence of infections. Besides the graphical view, advanced queries of antibiotic consumption and microbiology results are executed on the COSARA database for clinical academic research. An example of an advanced query is: ‘give the patients which were admitted to the medical ICU in 2010 and had a pneumonia infection for which the bacteria pseudomonas was identified, and where an antibiotic therapy with Glazidim was started’. The queries can be refined through the SQL viewer or with Crystal reports. By using data mining techniques patterns of infections and antibiotic therapies can be discovered, leading to new insights for the ICU. For example, if infection transmission across patients should be detected in a ward, new policy restrictions concerning hygiene can be applied very fast.

Fig. 5
figure 5

Screenshot of the COSARA management module with graphs displaying the division (A) and statistics of infections in the ICU wards in the last 6 months (B)

Full size image

Evaluation results

Performance evaluation

The COSARA platform is running on AMD Dual-core Opteron Processor 2216 2.00 GHz, with 8 GB RAM and an installation of Windows Server 2003 R2 Enterprise Edition SP2. Figure 6 shows the daily total execution time of the queries in the DLS for the display of the graphs in the infection overview module (Fig. 3a-c) across all running clients (invoked by refresh or patient switch in the client). The graph includes the execution times of the data retrievals of thrombocytes, temperature, CRP, WBC and SOFA score. Fluctuations in these values can be an indication of an infection. Each individual query has an average execution time of 3 ms.

Fig. 6
figure 6

Total execution time in the Data Lookup Service (DLS) for the Infection overview graphs over one day, measured in time frames of 2 hours

Full size image

Figure 7 shows the number of invocations in the DLS to ICIS, GLIMS Lab and COSARA database spread over one day. The daily morning retrieval of grouped values such as maximum and minimum of monitored values and retrieval and checks of all data is noticed in the ICIS line. At 3 AM the number of COSARA queries is lower because a maintenance procedure runs. Both graphs display the average daily measurements. Continuous synchronization of clinical data between the systems ensures that COSARA is near real-time in sync with the originating system. Data is retrieved within a few seconds, dependent on the periodicity of configured data retrievals.

Fig. 7
figure 7

Number of logical query invocations in the Data Lookup Service, grouped by retrievals from ICIS, Laboratory Database GLIMS and COSARA

Full size image

Study nurse validation

Since April 2010, the COSARA application has been evaluated. The study nurse compared the electronic records, stored in COSARA, with the records in the originating databases. To ensure data quality, manually, a selection of patient records were compared. Feedback of usage of the application was collected from the ICU staff, and the application was used as part of the clinical workflow, and during weekly staff meetings when patients’ conditions are discussed.

Figure 8 shows the impact of reported issues by the study nurse to the developers. The issues included data inaccuracy, integration mismatches, human registration inaccuracy, slow system response, link failures, software server crash, hardware and power failures. Most issues were recorded on data inaccuracy as a result of external configuration changes. This has already resulted in changes in the synchronization service (changes in the frequency of retrievals, additional retrieval of parameters). Figure 8 shows the issues importance in 3 months from April–July 2010 (outer line) and from January–April 2011 (inner line). It is shown that less issues are now recorded. Data inaccuracy could only be tackled for 50% due to configuration changes in the external systems which were still affecting the COSARA client. These issues include for example the intention of antibiotics which could not be registered due to a pop-up that did not appear as result of user rights which were not given to the application. Also sudden changes in structure of data strings led to parsing issues. COSARA hasn’t led to erroneous decisions, because the inaccuracies were immediately noticed by the physician when the antibiogram did not appear entirely or as intention details were missing. Communication with the IT administrators of the external system minimized these issues. It is important to validate data where possible and to be informed of changes in data or external configuration. The COSARA development has been a continuous iterative process.

Fig. 8
figure 8

The relative number of issue reports by the study nurse split up in categories for data inaccuracy, integration mismatch, human registrations, low system response, link failures, server crash, hardware or power failure

Full size image

During the study nurse evaluation it was noticed that a thorough domain study of the ICU with all available infrastructure and dependencies for systems and data is essential. In order to replicate the platform to other ICUs, integration points with existing computer systems should be clearly identified. The queries in the Data Lookup Service can be replaced if databases have other structures, and the synchronization configuration such as timing and data variables and names should be changed. However, logic in automated decision support should be replicated with care, as the guidelines in the antibiotic services might be an implementation of local or regional guidelines.

Benefits

Although the availability of information systems, in which clinical parameters of laboratory and clinical condition are stored, before the introduction of COSARA a complete infectiological record of the patient could not be provided without consultation of all clinical software applications by the clinician. Unfortunately, not even in an ICU that utilizes advanced computerization, when the physician returned to work, all infectiological details had to be investigated in a way a detective does. The physician faced questions such as ‘What was the chosen antibiotic therapy? Why was a therapy changed? What was the infection focus? Was it a firm diagnosis or suspicion? Are there cultures? What is the resistance? What is the radiological evolution?’ With COSARA all data regarding infections, antibiotics and microbiology are brought together so that the physician can link these together in order to create new infectiological information. This reduces time for clinical handover between physicians. In addition, it also provides a high-quality database that supports infection surveillance and control policies and acts as a source to test research hypotheses. By linking the data to the intention of the physician is immediately registered in the system. Moreover, describing the clinical practice of prescribing antibiotics in ICU will be helpful in two ways: (1) to identify antibiotics overuse, (2) to contrast clinical perception of infection or non- or poorly resolving infection with a set of objective clinical or laboratory parameters and scores, including outcome. The multidisciplinary development of COSARA with cooperation of the department of Information Technology (IT) and the department of Intensive Care, makes the platform tailored to the specific detailed needs of clinicians and recent IT techniques are incorporated in the iterative design and development of the system.

Conclusion

In this paper we presented the COSARA research project, deployed in ICU of the Ghent University Hospital. The Computer-based Surveillance and Alerting of nosocomial infections, Antimicrobial Resistance and Antibiotic Consumption enables physicians to make clinical decisions provided with a complete view on infection parameters, antibiotic usage, microbiology results, the physicians therapy decisions and thorax photos.

In a multidisciplinary team of software engineers and physicians, the functional requirements were captured and agreed upon. These requirements include (i) automatic integration of clinical data, (ii) presentation and clinical interpretation of infections, antibiotics and pathology-related data on a bedside screen, (iii) provisioning of clinical decision support services that automate clinical practice guidelines, (iv) autonomous system detection and recovery mechanisms to maintain the platform, (v) alerting of alarming trends and (vi) management and reporting facilities for clinical research. In the design of the COSARA platform a layered service-oriented architecture was preferred. The design has platform services to access the different clinical data sources of laboratory (GLIMS), Intensive Care Information System (ICIS) and the Picture Archiving and Communication System (PACS). Due to the different data formats preprocessing services are necessary. The data processing has a Data Lookup Services, Data Collection Services, Transformation Services. Services such as Monitoring and Logging, and Recovery Tools support the maintenance. In the business logic clinical services that support the data flow in the modules on the client are included.

Three clinical scenarios were described in detail. At patient level COSARA is used for the daily patient-specific follow-up of (a) infections and therapy, and (b) the follow-up of chest X-rays. At the ICU level the management module offers statistics in the incidence if infections in the ward. The service platform offers daily value in the clinical workflow of physicians in the ICU. The clinical data integration of different databases and electronic registrations of physicians’ intentions and decisions creates a unique source for daily bedside follow-up and infection surveillance with antibiotic management for the complete ICU.

In the evaluation, a performance evaluation and study nurse validation were included. Individual queries have an average execution time of 3 ms, and the execution time for the display of an infection related graph varies from 16 to 763 ms, depending on retrieval time. It is shown that most logical query invocation occurred during 6 and 9 AM, for data synchronization. In two validation periods of 3 months, a study nurse reported issues of the application. The platform had a continuous iterative development which resulted in less reported issues during the second period in 2011.

Future research of this COSARA platform will be devoted to the extension of the autonomic system monitoring and detection of changes in system performance through anomaly detection which signals abnormal behavior and data pattern changes of platform services. The platform is currently being extended with autonomic components in such a way that the system can self-maintain and self-govern the services. The study nurse validation process shows that data quality was perceived as the most important driver to adopt the full platform in the ICU setting. In future extensions, the role of the human operator should be reduced from taking recovery actions to changing policy rules or configuration settings.