Towards computerizing intensive care sedation guidelines: design of a rule-based architecture for automated execution of clinical guidelines

Abstract

Background: Computerized ICUs rely on software services to convey the medical condition of their patients as well as assisting the staff in taking treatment decisions. Such services are useful for following clinical guidelines quickly and accurately. However, the development of services is often time-consuming and error-prone. Consequently, many care-related activities are still conducted based on manually constructed guidelines. These are often ambiguous, which leads to unnecessary variations in treatments and costs.The goal of this paper is to present a semi-automatic verification and translation framework capable of turning manually constructed diagrams into ready-to-use programs. This framework combines the strengths of the manual and service-oriented approaches while decreasing their disadvantages. The aim is to close the gap in communication between the IT and the medical domain. This leads to a less time-consuming and error-prone development phase and a shorter clinical evaluation phase.

Methods: A framework is proposed that semi-automatically translates a clinical guideline, expressed as an XML-based flow chart, into a Drools Rule Flow by employing semantic technologies such as ontologies and SWRL. An overview of the architecture is given and all the technology choices are thoroughly motivated. Finally, it is shown how this framework can be integrated into a service-oriented architecture (SOA).

Results: The applicability of the Drools Rule language to express clinical guidelines is evaluated by translating an example guideline, namely the sedation protocol used for the anaesthetization of patients, to a Drools Rule Flow and executing and deploying this Rule-based application as a part of a SOA. The results show that the performance of Drools is comparable to other technologies such as Web Services and increases with the number of decision nodes present in the Rule Flow. Most delays are introduced by loading the Rule Flows.

Conclusions: The framework is an effective solution for computerizing clinical guidelines as it allows for quick development, evaluation and human-readable visualization of the Rules and has a good performance. By monitoring the parameters of the patient to automatically detect exceptional situations and problems and by notifying the medical staff of tasks that need to be performed, the computerized sedation guideline improves the execution of the guideline.

Figure 1

High level overview of the framework to semi-automatically translate clinical guidelines.

Figure 2

High level overview of the architecture. Gives a high level overview of the complete architecture. The top left part of the figure represents the components responsible for translating XML-based flow charts into Drools Rule Flows. These components were designed by the authors. The components surrounded by a gray shade visualize the different modules of a Rule-based system such as Drools. These are external components which exist independently. Every possible Rule Engine could be inserted as long as a Post-processing module exists for it. This module translates the intermediate language to the specific language of the Rule Engine. The authors have designed a Post-processing module for Drools. The components at the top right of the figure illustrate the communication of the proposed architecture with the existing ICSP platform. The ICSP platform and the IZIS database were constructed by the co-authors.

Figure 3

A simple example of a Drools Rule Flow.

Figure 4

The class diagram of the Combined Reasoning (CR) module. Visualizes the second ADD iteration of the semi-automatical translation architecture. It represent the Combined Reasoning module through the blackboard pattern. The light blue classes represent Knowledge Sources, such as the ontologies with accompanying SWRL Rules and the Diagram Reasoner. The yellow class represents the Blackboard, which contains the flow chart that is currently being translated. The purple class represent the Coordinator which organizes all the activity. The dark blue class functions as the general entry point to the Combined Reasoning module and contains methods that can be called by other modules.

Figure 5

The sequence diagram of the Combined Reasoning (CR) module. Represents how all the components of the Combined Reasoning module interact with each other and how the data flows between them. The same colors for the classes are used as in Figure 4. Note that all the function calls are synchronous, which means that the next action cannot be started before the previous one is ended.

Figure 6

Interaction view of the integration framework. Represents how all the components of the integration framework interact with each other and how the data flows between them. The modules in white represent the Rule Engine Service and its utilitary services. The gray modules depict a random Client Application which uses the Rule-based system and the ICSP components. The DataLookupService allows the ICSP platform to retrieve data from a database. The RuleDataService is used as a persistent container for reusable model data. The RuleEngineService offers the actual Rule-based functionality. The JobSchedulerService allows to automatically retrieve data from a database. The DistributorService an event handling service which provides access to the existing services in the ICSP platform.

Figure 7

Average execution time of the different implementations of the BMI application.

Figure 8

Analysis of loading times of the working and production memory of a Rule Flow application.

Figure 9

Loading time of a Rule Flow as a function of the number of decision nodes.

Figure 10

Manually constructed UML and Drools Rule Flow of the sedation guideline.

Figure 11

Example of XML filtered by the Pre-processing Module.

Figure 12

The Diagram Ontology. Represents a part of the Diagram Ontology. The yellow squares represent the classes. Blue arrows indicate subclass relationships. Red arrows and lines indicate relations between classes (object properties). Green Ovals represent attributes of classes (datatype properties).

Figure 13

GUI of the sedation application. The Graphical User interface (GUI) which allows nurses to easily interact with the sedation application and input the needed information about the patient, the RASS score and the medication. The "Input patient information" screen is shown at the start of the application. It allows the nurses to input information about the patient (weight, age and sex) and which type of sedation (short vs. normal vs. deep/long-term) guideline should be used. If this information is already available in the database, the fields will be filled in with the data found in the database. The nurse can then adjust or confirm this data. The "Medication notification" screen is an example of a message that is displayed on screen when the medication of the patient should be adjusted. The "Input current Rass" screen prompts the nurses to input the current RASS of the patient. The time points, at which these RASS scores should be collected, are prescribed by the sedation guidelines. For example, in the normal sedation guideline, the RASS score needs to be updated every four hours. This means that this screen will automatically be shown every four hours, unless the RASS score has already been inputted in the database through another interface.

Figure 14

Analysis of the loading times of the sedation guideline Drools Rule Flow.