1 Introduction

Infections caused by bacteria and other microorganisms are one of the most relevant health issues at the present time. The best clinical solutions to this problem are antibiotics, which are unique drugs owing to their high efficacy in terms of the reduction of morbidity and mortality resulting from this kind of affections. However, they are also the only drugs in whose case the use of an agent with one patient can affect its use with others, since resistant microorganisms may be developed and transmitted by contagion.

When exposed to an antibiotic environment, bacteria are quickly able to develop resistance because of their short growth cycle and their multiple adaptation mechanisms. In fact, resistant microorganisms have been discovered against almost every antibiotic deployed [1]. What is more, the development of new antibiotics is decreasing owing to several factors, such as shortage of public research resources as a result of the economic crisis, the extensive regulation process of new drug compounds and large pharmaceutical companies’ perceived lack of return on investment [2, 3].

Fig. 1
figure 1

ASP team, including department representative and attending physician

Full size image

The antibiotic resistance problem has been highlighted by several health organisations around the world. The Center of Disease Control and Prevention indicates that at least 2 million people become infected with resistant bacteria in the USA each year and that at least 23,000 people die as a direct result of these infections [4]. In a similar way, the European Centre for Disease Prevention and Control estimates that infections caused by multidrug-resistant bacteria result in a cost of 1.5 billion Euros and about 25,000 deaths per year [5]. Furthermore, the World Health Organization (WHO) claimed in 2014 that antimicrobial resistance is a global health threat, reaching alarming levels in many parts of the world and requiring coordinated actions from governments and society as a whole. The problem is so serious that they even state: “A post-antibiotic era—in which common infections and minor injuries can kill—is a very real possibility for the twenty first century” [6].

One of the solutions to the global threat of antibiotic resistance that has been proposed is the development of Antimicrobial Stewardship Programmes (ASPs) in hospitals [7–9]. These programmes should follow several recommendations, including the constitution of a multidisciplinary stewardship team composed of physicians, pharmacists, microbiologists, epidemiologists and managers. This team should improve collaboration and communication among all the different hospital services to achieve a rational use of antibiotics. The overall structure of this team is illustrated in Fig. 1.

First experiences with ASP teams have proved useful as regards improving patient outcomes, reducing the use of antibiotics and controlling costs [10, 11]. Initiatives adopted by these groups are not only applicable in a hospital environment but also in primary care and even in veterinary care. Developing the best means to share evidence-based prescribing regimens and promoting education regarding correct antibiotic use are important to the success of ASPs.

The University Hospital of Getafe, located in Madrid (Spain), has recently implemented an ASP programme denominated as Programa de Atención Multidisciplinar en el Asesoramiento y control de la Terapia Antimicrobiana (PAMACTA). This is a medium-size hospital (approx. 600 beds), covering most medical specialties (including a burns unit, although there is no cardiac surgery or transplant unit); its occupancy rate is 83.35 %, with an average length of stay upon admission of 6.64 days.

The PAMACTA team is composed of 9 members: 1 pharmacist, 2 microbiologists, 1 surgeon, 2 internists, 2 intensivists and 1 infection preventionist. In the current context of the economic crisis, resources are limited and all specialists have a modest amount of time that can be dedicated to the project. This team has been formed to address two organisational proposals: (a) to include a representative of each service, and (b) to involve all the physicians as part of the system. The intention of these two proposals is to reduce the time spent on distributing the task among departments and the integration of individual clinical expertise with the best available external clinical evidence, a basic principle of evidence-based medicine (EBM) [12].

Clinical decision support systems (CDSSs) may be a key issue for the success of ASPs. These systems have proved to be useful in several clinical tasks, from diagnosis support [13, 14] to guideline adherence [15, 16]. Furthermore, some recent studies suggest that the combination of electronic health records (EHR) and CDSSs has a positive impact on appropriate antimicrobial use [17–19], and CDSSs are therefore becoming an inherent part of medical practice [20], in spite not having met several challenges [21, 22].

At the same time as the PAMACTA team was created, a CDSS development project, denominated as wise antimicrobial stewardship program support system (WASPSS), was proposed to fulfil the requirements of the new group. After researching literature related to CDSSs and previous implementations, three fundamental characteristics have been identified and used to guide the development of the new system. Several artificial intelligence (AI) techniques are also proposed to solve the major technological challenges confronted in the forthcoming development.

The remainder of the paper is as follows: Sect. 2 shows a brief analysis of common CDSS purposes and their application within the ASP scenario. An analysis of some of the CDSSs that are focused on antimicrobial infections and antibiotic stewardship is provided in Sect. 3. In Sect. 4, we explain the main functional objectives used to guide the WASPSS project development. This project is explained from two perspectives: the AI techniques selected to achieve our proposed objectives, which are described in Sect. 5, and the system architecture and software methodology proposed for its development shown in Sect. 6. Finally, Sect. 7 provides a summary of our work and indicates future lines of work within each topic. Other CDSS related problems, such as implantation and validation, are not covered in this paper.

2 Purposes of clinical decision support systems

A CDSS can be defined as “the use of information and communication technologies to bring relevant knowledge to bear on the health care and well-being of a patient” [23]. This definition is sufficiently broad to include both simple information retrieval utilities and complex multi-module diagnostic systems, without limiting either the technology used to provide decision support or the clinical scenario in which it is needed, and multiple classification perspectives are accordingly permitted.

A decision support system could help an ASP group in various ways, and these aspects have been identified using the analysis of Greenes [24], which focuses on the purposes of the CDSS. This analysis states that CDSSs have five general purposes.

2.1 Answering questions

One of the ways in which a clinician could be helped is by providing him/her with all the relevant information concerning a concrete topic when needed. The simplest way to deliver this information is by means of a hyperlink, while a more complex method is that of using infobuttons [25] or even advanced natural language processing techniques [26].

In the ASP scenario, before answering a question we must take into account who is asking it. Despite pursuing a common objective, ASP groups are multidisciplinary teams, and each member might therefore need a different kind of information about a similar topic. For example, when given the name of a concrete microorganism, a microbiologist might be interested in the laboratory techniques needed to detect it correctly; an epidemiologist could need the latest local epidemiological reports; and a clinician might require the antibiotics to which it is intrinsically resistant. The information must therefore be obtained from different sources and presented in different ways according to the user.

2.2 Making decisions

One of the typical purposes of a CDSS is that of providing information that will help a clinician to make a decision. One of the first clinical problems that researchers attempted to resolve with a decision support system was diagnosis, which led to the appearance of, for example, the Leeds abdominal pain system [27] which was based on Bayesian reasoning, or DXPlain [13, 28], which proposed ranked diagnoses obtained from a set of clinical findings. Other similar decision tasks have also been studied, as is evidenced by the use of MYCIN [29] to select the best antibiotic therapy and that of Iliad [30] to choose the most relevant test during a differential diagnosis process.

With regard to the problem studied herein, clinicians could be helped with the diagnosis of an infection and its assessment (nosocomial, colonisation, etc.). Another crucial decision point is the selection of an antibiotic treatment before any laboratory test results have been received. Several factors such as antibiotic spectrum, costs and the prevalence of microorganisms have to be taken into account. Once again, different knowledge sources should be used to perform this kind of tasks.

2.3 Optimising process flow and workflow

Clinical processes usually have multiple steps that must be orchestrated efficiently to ensure good health care quality at a reasonable cost. Clinical guidelines (CG) are commonly used as reference frames for these processes and are adapted to local protocols when needed. CDSSs can help clinicians to adhere to these protocols, indicating the next tasks to be performed or the different paths resulting from a decision. The field of CDSSs has produced multiple studies based on guidelines, and multiple proposals with which to facilitate the maintenance and sharing of this kind of knowledge [31].

Guidelines are also available for the diagnosis and treatment of infectious diseases, with several tasks that must be performed within time restrictions. A CDSS could help the clinicians to follow them in different ways by, for example, showing the next recommended steps for a concrete therapy or scheduling future control tests to monitor antibiotic levels in the bloodstream.

2.4 Monitoring actions

Another usual purpose of a CDSS is that of generating alerts and reminders for clinicians under the relevant circumstances, such as a laboratory test result that is not within the normal range.

Alerts and reminders are crucial in our scenario. When a lab test detects a microorganism that is resistant to a currently prescribed antibiotic, action must be taken as quickly as possible to avoid aggravating the infection or even prevent its propagation to other patients, and the system should therefore take the initiative to communicate this information as soon as possible. It is also necessary to consider that relevant alerts and reminders could be different according to the users for whom they are intended. While the previous example is important for a clinician, a microbiologist might be interested in the discovery of a rare pathogen, or a common microorganism but with an unexpected resistance pattern.

2.5 Focusing attention and enhancing visualisation

Although this is sometimes ignored, the capabilities of a CDSS to group similar elements and structure data visually are relevant in many situations [32].

As with many other clinical tasks, the data related to antibiotic stewardship are quite complex. They are gathered from multiple sources, and different users need to focus on different aspects of them. The clear organisation and presentation of data are fundamental if optimal decisions are to be made.

3 CDSSs in relation to antibiotic stewardship

Several CDSS developments have focused on similar scenarios, but few of them have dealt with the global problem of antibiotic stewardship. It is, however, possible to extract common characteristics from these developments, which can be reinforced with the previous analysis and thus considered as requisites for future CDSS developments in this area.

The MERCURIO system [33] was designed for the validation of microbiological data and the creation of a real-time epidemiological information system. It was intended for different kinds of users, such us laboratory physicians, clinicians and epidemiologists, and included knowledge from several sources, such us antibiotic hierarchical definitions and international guidelines for microbiological laboratories.

In [34], the HASIS information system is explained. It implements the guidelines for hospital-acquired infections (HAI) published by the Centers for Disease Control and Prevention (CDC) and includes algorithms for the detection of suspicious cases, using a service-oriented architecture (SOA) to integrate surveillance data.

The COSARA platform [35], which focuses on infection surveillance in intensive care units (ICUs), provides functionalities for the automatic integration of clinical data, clinical decision support and alerts to alarming trends, among others.

In the Detecting and Eliminating Bacteria UsinG Information Techinology (DebugIT) European project [36], a system was developed using ontologies and other semantic web technologies to gather information from heterogeneous sources [37] for use in data analysis [38].

4 Mandatory need to deliver decision support in the antibiotic stewardship scenario

On the basis of the initial purpose analysis and the main characteristics of the previous examples, it is possible to suggest that in an antibiotic stewardship scenario a CDSS should take three representative factors into account.

The first factor is a multi-user perspective. As described in the previous sections, the multidisciplinary essence of the ASP groups requires a CDSS that is capable of filtering, abstracting and summarising knowledge among several user roles. Alerts, reminders and plans must deliver concise information to the proper user in a timely manner. Improving the communication between different users and promoting the sharing of experts’ knowledge are, moreover, a must in this scenario.

The second aspect is to have both reactive and proactive behaviour. Most previous CDSSs have fundamentally been reactive and have require a user interaction to provide a diagnosis or certain events to generate alerts and warnings. However, this scenario requires proactive actions, such as helping the physicians to follow complex clinical guidelines or detecting resistance patterns that could lead to the outbreak of an epidemic. The CDSS must therefore be designed to support the different methodologies used by the ASP and focus on the knowledge needed in all the stages of infectious disease management.

The last one is the integration of hybrid knowledge sources. As a mandatory requisite derived from the previous points, the CDSS must be able to acquire both knowledge and data from different kinds of sources. Expert knowledge is essential in several situations. For example, published rules about intrinsic microorganism resistances can be used to enrich laboratory test results and help physicians to select a more effective treatment. CGs are a fundamental source of knowledge, not only as regards proposing plans to the physicians but also providing the ASP group with information about CG adherence. The results obtained may also help improve in CGs or the training strategies for the medical staff. Finally, knowledge mined from the current epidemiologic data can help the ASP group to foresee future problems, such as outbreaks of epidemic or resistance development.

Other requisites, which are common to other CDSSs, are also fundamental in this scenario. The integration of a CDSS into the clinical workflow is a key issue for its acceptance and use [39]. Improving the human–computer interface by showing relevant alerts only or using the best visualisation techniques is similarly still a challenge for CDSSs at present [22].

5 Proposed methods for CDSS in antibiotic stewardship

In this section, we are going to expose our decisions regarding the technique aspects of the development of our CDDS, that is, knowledge representation, knowledge discovery, and visualisation.

5.1 Modelling the expert knowledge

We propose that the main knowledge representation technique in this scenario should be production rules. Rule-based decision support systems have been successfully used in other clinical scenarios [40], and we are thus of the opinion that rules can be used to model the majority of the clinical knowledge needed in WASPSS. Nevertheless, rules have some disadvantages, such as the maintenance of large rule knowledge bases, the lack of an intuitive representation of guidelines and the difficulty involved in modelling ambiguities inherent to the clinical environment [41]. We consequently propose several additional techniques that should be able to minimise these drawbacks while maintaining production rules at the core of the knowledge base.

Some concepts and relationships are easier to model and maintain using other techniques different from production rules. For example, expert knowledge in this field makes use of complex taxonomies that are easier to model as ontologies than directly as rules. We therefore propose to support the definition of production rules through the use of ontologies.

Several previous works have addressed the interoperability between ontologies and production rules in complex decision environments. In [42], ontologies are used to represent the domain knowledge and production rules mixed with fuzzy logic to represent behaviour knowledge when applied to decision support in space mission control rooms. In [43], process management is tackled using a framework and a methodology in which ontologies, rules and processes are mixed. In [44], ontologies, production rules and fuzzy logic are used for decision support in eTourism scenarios. Finally, in [45] Sottara et al. discuss how the combination of ontologies, rules, workflows and predictive models could be useful in environmental decision support systems.

The interoperability between ontologies and rules has also been tested in clinical environments. In [46], several approaches are considered for a telecardiology decision support system, and the conclusion is reached that the combination of the simplicity of implementing and maintaining ontologies and the expressiveness of the production rules could be a direction worth exploring.

One of the relevant knowledge sources to be used in WASPSS is the EUCAST expert rules in antimicrobial susceptibility testing [47]. This document contains rules for intrinsic resistances of isolated bacterial species and rules with which to infer other susceptibilities and resistances from tests. These rules are defined not only for concise bacterial species and antibiotics but also for families and large groups of them (i.e. Enterobacteriaceae family, Gram-negative and Gram-positive bacteria groups, macrolides family of antibiotics, \(\ldots \)). In this context, it is easy to see how simply an ontology can model these complex taxonomies, rather than the direct use of production rules.

In WASPSS we have already carried out a first experience in mixing ontologies and production rules for the representation and usage of some EUCAST rules. We have used OWL 2 [48] as an ontological modelling language, OWL Api [49] and Protégé [50] for ontology management and Drools [51] as a rule engine.

Fig. 2
figure 2

Steps followed to use ontologies in Drools. The original ontologies are populated with individuals obtained from the master tables of microorganisms and ATCs in our operational database. In the next step, these individuals will help to generate all the traits and rules needed to assign each basic fact with all its traits. This will result in the generation of a knowledge base that can be used with Drools when operating on a fact extracted from the operational database

Full size image

Both antimicrobials and microorganism relationships have been modelled using public taxonomies. In the first case, we have used an OWL model [52] of the Anatomical Therapeutic Chemical Classification (ATC) hierarchy, published by the WHO [53], while in the second, we have chosen the National Center for Biotechnology Information (NCBI) taxonomy [54, 55]. Both ontologies have been adapted to our requirements, signifying that in the first case the only aspects to be maintained were antibiotic related concepts, while in the second those maintained were the microorganisms needed in our scenario. Some of the concepts required, such as Gram-positive, Gram-negative and non-fermenting groups, have also been added.

To be able to use these concepts in Drools, its capacity to define traits [56] has been used. Drools permits the assignation of any number of traits to facts, thus allowing their classification from multiple grouping levels. For example, the fact that represents a concrete microorganism can be given the corresponding traits of its species, family, group and order, thus allowing rules to be defined for these predefined traits. With this approach, the ontologies must be translated into a set of trait declarations and a set of rules so as to assign traits to the correct basic facts.

A summary of the whole process is shown in Fig. 2. Source ontologies are too broad for our scenario, and the first step therefore consists of pruning these ontologies and leaving only the concepts used in our domain. This is done by populating the ontology with individuals generated from the most specific concepts of our system, which are stored in our master tables of antibiotics and microorganisms. These individuals are directly typed with the most narrow class that can possibly be used to define them (i.e. the Escherichia Coli individual is typed as Escherichia Coli instead of Bacteria). All the classes that do not have individuals between their descendants are removed. In the next step, we generate a set of trait definitions and rules. All the individuals are extracted from the ontology, the classes to which they belong are calculated using an ontological reasoning engine (HermiT [57]), and all this information is employed to generate the definition of traits and rules. The entire process could be carried out in a single step without the need for intermediate populated ontologies. However, these ontologies represent our real conceptual knowledge model and we expect to use them directly in the future, taking advantage of their simplicity to improve the system maintenance. Drools is shortly expected to be able to incorporate ontological functionalities [51], signifying that the entire process could be improved. Figure 3 shows an example of the code generated and how it may be useful in our scenario.

Fig. 3
figure 3

Example of our integration between ontologies and rules. a Shows a screenshot with the definition of the ‘Escherichia_coli’ individual in our ontology. This definition is employed to generate the code in b, which defines the traits for the fact representing the E. coli microorganism. We shall use a similar ontology for the generation of code related to antibiotics. This code makes it possible to generate rules like those in c, which operate on the entire ‘Enterobacteriaceae’ family to add a fact to represent their intrinsic resistance to fusidic acid. Thanks to this knowledge, we can define rules with which to enhance microbiological tests in which a concrete antibiotic is not tested on a concrete microorganism (d), or to alert microbiologists about a possible mistake in a test (e)

Full size image

5.2 Modelling clinical guidelines

If adherence to clinical protocols is to be supported and measured, then CG must be elicited and included in the knowledge base. This kind of knowledge tends to be composed of several steps that must take place or be checked sequentially, with rules that are only valid for certain steps and/or under certain conditions.

Arden Syntax [58], a rule-based language designed to share medical knowledge, would appear to have had the greatest impact on industry as regards guideline implementation, since it is included in standards produced by several organisations, such as the American Society for Testing Materials (ASTM) and Health Level 7 (HL7). It is still being used in decision support research and was employed in MONI [59], a system for monitoring nosocomial infections whose rules are written in MLM, the Arden medical knowledge representation scheme. Some work has also been done to adapt these rules to new rule engines like Drools [60].

However, Arden Syntax was not intended to be used to encode complex guidelines composed of multiple steps [61]. Many other CPG generic models have been proposed [31], along with some other more particular models, such as ONCOCIN [62] for oncology guidelines and T-HELPER [63] for HIV protocols. Despite differing in many respects, they have similarities as regards their control-flow strategies, which are very similar to those achieved by the common workflow management systems [64].

Fig. 4
figure 4

Partial guideline implementation using Drools

Full size image

Focusing on its sequential nature, we propose the use of a generic process representation, the business process model (BPM), to incorporate this kind of knowledge into WASPSS. Furthermore, Drools own BPM engine is integrated into the rule engine, thus facilitating the use of rules in BPM tasks. As suggested in other CPG related works [65, 66], we do not intend to represent the guidelines in depth but only those steps in which users might be helped with some kind of decision support, or those that are considered critical and must therefore be planned and reminded.

A first modelling attempt has been performed for a typical process, common to multiple guidelines: the recommendation of laboratory control tests to ensure that the levels of an antibiotic or toxic substance belong to a range during a treatment. In particular, the levels of Vancomycin, an antibiotic used in some bloodstream infections, should be checked for certain patients, such as those who have an unstable renal function, both to prevent the development of resistant microorganisms and to avoid toxicity problems in the patient [67]. It is supposed that Vancomycin tests should be performed between 72 and 96 h after starting the treatment or after the previous test.

The primary objective of this CG implementation is to advise the physician that it is necessary to follow up of his/her patient, and the CDS should therefore remind or warn the user when an action may be considered. If there is sufficient time before the next control test, a plan notification fact will be included in the knowledge base. If this time is short and the physician should be advised as soon as possible, a reminder will be added. Finally, if the control test should have been done previously, a warning or an alarm will be generated, depending on the time that has elapsed. The GUI will decide the best way to show these facts to the clinician, for example as events on a calendar, reminders in a to-do list or warnings/alerts in an alerts window.

This process has been modelled as a workflow comprising several tasks and gateways, as shown graphically in Fig. 4. The most relevant tasks are:

  1. 1.

    Start Treatment The treatment with Vancomycin starts. This task obtains the start date to be used in the following tasks.

  2. 2.

    Order initial test Some time after the start of the treatment, it is necessary to carry out a control test for Vancomycin levels. The objective of this task is to discover the first control after the start of the treatment, asserting a fact with its date or a ‘no-initial-test’ fact.

  3. 3.

    Continue treatment If we have a previous test, we must check whether the patient has continued with the Vancomycin treatment after that test. If not, it is possible to simply stop monitoring. This task basically ensures that a previous test has been found and that the treatment is continuing after it. If it is not necessary to check for more tests, a flag is raised which is used by the next gateway to decide whether or not to stop the process.

  4. 4.

    Order control test If the Vancomycin treatment continues, another test must be carried out after the previous one. If it has already carried out, we assert a fact containing the date. If not, we assert a ‘no-last-control-test’ fact.

Other important tasks are Check Constraints-1 and Check Constraints-2, which are responsible for generating the notifications related to the current guideline status. These tasks recover the facts asserted by the previous tasks and check the time constraints to decide whether a notification must be asserted. For example, Check Constraints-1 seeks the facts asserted from Start Treatment and Order Initial Test. If the test has not yet been carried out, a plan, reminder, warning or alert can be asserted, depending on the temporal constraints. If it has already been carried out, this step can be ignored, or if it did not occur within the recommended time gap, we can store a ‘guideline non-fulfilment’ fact for later posterior analysis. The remaining tasks, Initialize and Clean, are included to perform implementation related processes.

An effort has also been made as regards reusability. The process implementation can be parametrized with the episode and treatment to be monitored, the test values to be checked and the time constraints, for reuse in other guidelines. The Check Constraints tasks are in fact reused processes that have been parametrized with the concrete time constraints and the facts that must be checked.

The whole process is intended to being executed automatically, without requiring inputs from a human or another clinical system. This means that, for example, rather than waiting for the Order Initial Test task until a lab test is ordered, the task will simply end by asserting a ‘task-not-completed’ fact, which can be used by the Check Constraints-1 task to decide whether a warning must be sent immediately to the clinicians or whether it is only necessary to silently included on their calendar. An example scenario and a log (no graphical representation has been implemented as yet) of the notifications generated for each treatment day can be seen in Fig. 5.

Fig. 5
figure 5

Notifications obtained after executing the test workflow for a real patient episode. After starting treatment on 5th of February, the notifications are generated every day at midnight. Planning notifications are obtained on the initial three days, and a reminder on the same day on which the test should be carried out. Similar results are obtained for the control test

Full size image

5.3 Modelling the mined knowledge

General antibiotic resistance varies over time and is influenced by the use of antibiotics. One of the ASP groups’ main tasks is to minimise the development of resistance at the community level [7] by means of the use of local information along with the international CG. In this sense, it would be useful to discover patterns in our local data so as to foresee possible outbreaks of resistance, detect antibiotic resistance occurrence patterns or even incorrect treatment patterns that could lead to an increase in the efforts made in team training or CG refinement.

These patterns must be easy for experts to understand and verify, and allow them to decide whether they are simply trivial associations or are in fact relevant knowledge. It might also be useful to formulate them as rules, thus allowing them to be incorporated into our knowledge base and used in many other decision support tasks.

There are many works related to data mining in the antibiotic stewardship scenario. In [68], production rules are used to detect urinary tract infections from data present in electronic health records (EHRs). Association rules have been used to detect inappropriate antibiotic prescriptions [69], interesting patterns in hospital infection control [70] and alarm rules with which to validate microbiological test results [71], and fuzzy rules have been used in infection surveillance [59]. Another widely studied problem is that of the prescription of antibiotics, using retrospective analysis [72], causal probabilistic networks [73] or dual cross-table antibiograms [74].

We consider that an appropriate solution in our scenario could be subgroup discovery techniques [75, 76]. The main objective of these techniques is to discover interesting statistical patterns related to a target objective as opposed to seeking a global model. They are therefore considered to be between the predictive techniques, which are based on supervised learning, and the descriptive techniques, which are based on unsupervised learning.

Moreover, thanks to both their descriptive and their predictive aspects, these algorithms can be evaluated using both descriptive (coverage, support, \(\ldots \)) and predictive (accuracy, area under ROC curve, \(\ldots \)) measures, depending on the concrete problem and the clinicians’ preferences.

In addition, the results of the subgroup discovery are rules that can be directly incorporated into our knowledge base. Their descriptive perspective allows these rules to be easily criticised by clinicians before their assertion and even to be a basis on which to update or tune clinical guidelines.

Some subgroup discovery techniques have already been used in clinical environments: clustering techniques to characterise femoral neck fractures [77], CART and PRIM to group Intensive Care Unit patients into severity-of-illness levels [78], active subgroup mining for patients with a high risk of suffering a coronary disease [79], fuzzy rules and evolutionary algorithms to identify Influenza A virus subtypes [80], and many others [75].

An example of our first approach to illustrate how this kind of knowledge is integrated into our system is provided below. We suppose that during a plan to prevent Streptococcus pneumoniae, which is responsible for several respiratory infections, an increment in control tests is proposed. Subgroup discovery can be used to identify some interesting groups in which to intensify these controls.

Fig. 6
figure 6

Example with the results obtained from a subgroup discovery technique and how easy it is to incorporate them into a rule-based system. In a we show a basic description of the datasets used for training and test purposes. The values of age are the mean age for each class and its first and third quartiles. The remaining values represent the frequency of each factor within each class. In b, the parameters used in the MESDIF algorithm are shown. In c we show the resulting rules and in d a possible codification in our system

Full size image

We have prepared a dataset for this approach. Our objective feature, hasMicroorganism is ‘true’ if the patient was found to have S. pneumoniae in any of his/her cultures, or ‘false’ if not. Each row also contains the final service where the patient was admitted and five boolean attributes, related to commonly used antibiotics (amoxicillin, levofloxacin, cefazolin, vancomycin and ceftriaxone) that are ‘true’ if the patient has been treated with them previously to the discovery of the pathogen, or during his/her entire episode if the microorganism was never found. This dataset has been split in two, for training and test purposes, using episodes from two different years for each group.

This test was carried out using R with the SDR package [81], which includes several algorithms with which to perform subgroup discovery. We have specifically used MESDIF [82], a multi-objective evolutionary algorithm, for subgroup discovery.

The algorithm results are shown in Fig. 6. They are canonical rules, which can easily be incorporated into our Drools knowledge base, and can also be easily evaluated by a clinician. In this example, the first rule suggests performing the test for all the patients not treated with Vancomycin, which is unaffordable but obvious, because this pathogen tends to be sensitive to Vancomycin. Moreover, the second rule suggests performing the test for all the patients in the pneumology service, which is also obvious because this pathogen is known to cause several respiratory diseases. The third rule relates a combination of treatments that should be studied by clinicians to check whether they are commonly used in the treatment of respiratory diseases or could have some relation to the patient health status.

As commented on previously, the intention of this first test is merely to show how easy it is to incorporate the results of a subgroup discovery algorithm into a rule-based system and is not a real study of S. pneumoniae infections. Furthermore, the dataset does not include all the useful data needed to detect relevant clinical patterns, such as days of treatment or nursing data. A comparison of several algorithms will be performed in the future, and a more concise definition of the data available and the target objectives will be provided.

5.4 Visualisation techniques

One very relevant aspect of clinical decision support systems is visualisation [32]. The aim of using techniques for the visual analysis of data is to exploit human perception so as to help in the understanding, analysis and communication of data, models and concepts.

The National Research Council of the National Academies [83] diagnosed that the extra time required to introduce data into review systems for decision making is largely owing to the lack of adequate cognitive support when interacting with clinicians. In fact, in 2012, the US Institute of Medicine recommended solving this problem through the use of visualisation models with scenarios of interdisciplinary clinical practice [84].

Visualisation models in the clinical context are mainly focused on two aspects: the custom visualisation of a single patient health record and the visualisation of groups of patients [85].

For example, the goal of IPBC [86] was to improve the therapeutic adjustment in haemodialysis using a three-dimensional visualisation. KHOSPAD [87] was designed to identify temporal relationships between primary care doctors, the patient and hospital stays. The objective of KNAVE-II [88] is to visualise oncological treatment information, while the VISITORS system [89] combines intelligent temporal analysis and information visualisation techniques to integrate, process and visualise information concerning multiple patients and information sources.

With regard to the visualisation of groups of patients and their characteristics, we can highlight sequence visualisation models such as lifeLines2 [90] and viscareTrails [91], along with techniques based on a single temporal axis like IPBC [86] and InfoZoom [92].

Nevertheless, little attention has been explicitly paid to clinical decision support systems for empiric treatment or healthcare associated infection, and very few specific works on the visualisation of epidemiology statistics [93] have been used to detect the outbreak of infections.

In this respect, we propose the use of visualisation techniques of the cumulative antibiograms to assist clinicians in the prescription of empiric treatment [94].

There is no established or accepted methodology for the development of visualisation models, and it is considered to be a heuristic expert-based development. In general, it could be said that the basic aspects of the development of visualisation models as a decision support tool are the correct representation of the concepts and efficiency needed to solve the clinical task for which they are defined.

In the decision support for antibiogram-based antibiotic selection in empiric treatment, the underlying clinical concepts behind the visual models are prevalence, sensitivity, resistance and efficacy. In clinical practice, the sensitivity of a microorganism to an antibiotic is proved by means of a laboratory test which concludes that the microorganism is sensitive to the antibiotic if it can defeat it, or resistant otherwise. Prevalence shows the probability of a microorganism being the cause of an infection, while efficacy is a general measure that combines sensitivity and resistance.

Three models were included in our initial proposal: Tree, Sunburst and Bipartite. Tree is a natural representation that allows a sequence of relations to be represented and permits the user to explore different situations. The Sunburst model has a hierarchical circular multilevel representation that is commonly used in bioinformatics [95]. Each of the levels is divided into parts in different sections to show the relationships between them. The Bipartite model is a type of graphic that allows the amount of relationships between two set of separate elements, in this case the microorganisms and antibiotics, to be represented by means of a channel of different width. In all these models the clinical concepts and their relationships have been represented through the use of visual properties, such as colour, intensity, area, width, length, position and sorting.

We evaluated the models in two ways: by analysing their representation capabilities and the user’s performance and experience [96]. The users at the clinic responded to a survey carried out to evaluate the users’ performance and experience, and were requested to solve the clinical tasks needed for the empiric treatment previously identified. With regard to the intrinsic characteristics, the only model to accomplish all the items identified was the Bipartite model. However, the users preferred the Tree model for the task of identifying the most active antibiotic, which may be because they are used to a hierarchical representation. They showed no preferences for any particular model in the remaining tasks.

6 First steps in CDSS implementation

6.1 System architecture overview

Fig. 7
figure 7

Representation of the WASPSS system architecture. A relational database contains the operational data obtained from the Hospital Information System (HIS) using ETL processes and, in the future, using an HL7 interface. The Drools rule engine plus its attached modules apply the knowledge stored in these data, thus providing the ASP group with decision support by means of a web-based interface

Full size image

Our proposed system has five main components (see Fig. 7): (1) a relational database with raw data; (2) a knowledge base with compiled rules; (3) a rule engine with several helping modules; (4) a hospital system front-end employed to interact with other clinical applications and (5) a web-based user interface.

Despite new advances in big data, traditional relational databases continue to be an efficient solution when dealing with a relatively small amount of data [97]. In our project we have chosen to store the raw data (patients, treatments, etc.) in a relational database. The main hospital databases are also relational, signifying that it is easier to integrate data into our database than using other approaches. However, in the latest project steps we plan to complement it with certain big data solutions such as Hadoop [97] or Spark [98], if the volume of data stored becomes too large.

The knowledge base contains the compiled rules along with other knowledge representations needed for the system support capabilities. As discussed above, ontologies and business process models will be included in it to support rule definition, activation and management.

A rule engine will manage the knowledge and raw data needed to generate reminders, alerts, plans and other decision support results. As explained previously, it will have to be helped by other modules when dealing with other knowledge representations or extracting mined knowledge. Drools has been chosen as our rule engine owing to its flexibility as regards incorporating new functions, integration with BPMs and the fact that it is a mature software solution.

Our proposed CDSS will not be an isolated application but rather another piece of the hospital software system, and it therefore needs a communication front-end with other clinical software. The hospital data are currently being dumped into the relational database using Extract, Transform and Load (ETL) processes. However, we plan to migrate to HL7 [99] messaging as soon as the other applications have been updated to support it.

Finally, a web-based Java application has been developed to act as the system GUI. Depending on the user, it will present different data aspects to avoid irrelevant information being shown. A snapshot of this GUI is shown in Fig. 8.

Fig. 8
figure 8

Two WASPSS GUI snapshots are presented here. In a there is a list of alarms related to one patient, with the capability of shorting them by level (relevance). In b an alarm detail is presented, with a summary of the alarm and the patient’s data

Full size image

6.2 Software lifecycle adopted

The software lifecycle adopted for the CDSS development is often overlooked in many works. However, we have made an effort to define it because we consider that CDSS software development is an interesting research topic.

The most frequently extended and studied methodology for CDSS software development is CommonKads [100], which focuses on system modelling and gives priority to problem analysis rather than coding. The use of this methodology results in a very long analysis process, and coding is left until the later development phases. This vision is also commonly extended in the contemporary software engineering methodologies.

Nevertheless, everything has changed since the appearance of agile methodologies [101]. These methodologies propose an iterative software development, with short cycles and the final user’s close implication. Despite the multiple agile methodologies proposed, they continue to be a hot research topic and state the need for more empirical research and a more robust theoretical support [102].

Although there are some works in which both CommonKads and agile methodologies are applied simultaneously [42], new trends in CDSS development use the latter only. In [16], a CDSS for opioid treatment is developed following an iterative process of design, testing and revision. In [103], a business rule design framework for a pharmaceutical validation and alert system is presented, based on an agile methodology.

Furthermore, the use of an agile methodology for rule-based decision support systems is proposed by Zacharias [104], who states that CommonKads imposes an excessive workload for this kind of projects, and proposes the use of an adaptation of eXtreme Programming (XP) [105] in their development. He defines three new guiding principles:

  • Programme first, knowledge second In this complex environments there may be no method with which to affirm that all the knowledge has been completely and correctly captured. In addition, these kinds of systems are designed to solve a task, and the knowledge is merely a guideline as to how this task is to be solved.

  • Interactive rule creation The environment used for system development should allow a new rule to be tried instantly and should evaluate how it reacts with the rest of the knowledge base.

  • Explanation is documentation Rule-based systems usually include an explanation of the rule coded in them to provide the final user with justification for a concrete output. This kind of information should be considered and managed as the main part of the system documentation.

We have followed this trend and have based our development on agile principles. The project has been planned following an iterative method for a solution proposal and an incremental model built for CDSS software development. At each iteration, a new specific infection or clinical problem is chosen, the sources of knowledge are selected, and the AI techniques needed to implement the CDSS are studied. A pilot experiment is conducted at the end of each iteration. The users will therefore be involved in the project and we will have continuous feedback about the use of the system.

7 Conclusion

In this paper, we have shown the needs of a CDSS oriented towards helping ASP groups with the task of antibiotic stewardship. Production rules are proposed as the knowledge core of the system and are supplemented by ontologies, workflows and subgroup discovery techniques. The architecture and methodology used to develop the WASPSS project, in which all these techniques are going to be tested, have also been explained.

The three most important requisites identified as being very interesting in our scenario are: a multi-user perspective so as to adapt the response and functionalities of the CDSS to each user profile; the ability to work both reactively, after a user’s request, and proactively, by giving the system the initiative to communicate relevant information to the users; and the ability to incorporate knowledge from different kinds of sources, such as clinical guidelines, expert knowledge and even results from data mining processes.

Despite the fact that we have proposed production rules as the core of our knowledge base, we also consider the use of other techniques with which to model, extract and maintain part of our knowledge. We have therefore chosen the Drools rule engine because of its flexibility as regards incorporating new operators and its integration with a general programming language, such as Java.

Ontologies have been widely used for knowledge modelling, and we also propose their use to maintain the complex taxonomies found in our scenario. Our chosen reference taxonomies, NCBI taxonomy for microorganisms and ATC for antibiotics, appear to fulfil our knowledge representation needs. However, it might be possible to use other ontologies such as SNOMED-CT [106], which are more usual in this scenario, and this might lead to a future better integration in other hospitals.

We have proposed BPMs as a technique for modelling the task orchestration that is usually included in antibiotic stewardship CPGs. Only a simple example has been developed, and this technique might be insufficient for modelling more complex guidelines. However, we trust that the flexibility provided by the Drools engine will allow us to make any improvements needed in the future.

The means proposed to find relevant knowledge in antibiotic stewardship is that of subgroup discovery techniques, and an example of their use and integration has been provided. However, we have not as yet studied the relevant patterns that must be sought, and an exhaustive analysis of available search algorithms should be performed for this scenario.

With regard to visualisation techniques, the current lines of work are based on developing a more complex stratification system that will enable the more accurate selection of parameters. We are also working on the creation of dual cross antibiogram visualisation.

Uncertainty management has yet to be addressed, but is a key issue in the clinical environment that will be dealt within the near future, since it is expected that Drools will soon have the capacity to do so. In the meantime, we shall study the best uncertainty measure approach for our scenario, ever seeking a descriptive way in which to present it so as to allow clinicians to make their decisions consistently.

We have already developed a basic platform for antibiotic stewardship on which to test all these techniques. This platform is being tested and evaluated by clinicians, which will help us to continue improving our knowledge regarding the scenario. Improvements to the system architecture, such as migrating to a big data database, will also be studied in the future.

Another topic to be studied in the future must be the system evaluation. The strategies to be followed must to be planned with the clinicians and based on methodologies previously used in the clinical domain [107–109].