Detection of Infectious Outbreaks in Hospitals

0 downloads 0 Views 62KB Size Report
Lecture Notes in Computer Science 1. Detection of Infectious Outbreaks in ... 2 Department of Medicine, Microbiology and Public Health Laboratory, Cardiff, UK.

Lecture Notes in Computer Science

1

Detection of Infectious Outbreaks in Hospitals through Incremental Clustering Timothy Langford1, Christophe Giraud-Carrier1, and John Magee2 1 Department

of Computer Science, University of Bristol, Bristol, UK {langford,cgc}@cs.bris.ac.uk 2 Department of Medicine, Microbiology and Public Health Laboratory, Cardiff, UK [email protected]

Abstract. This paper highlights the shortcomings of current systems of nosocomial infection control and shows how techniques borrowed from statistics and Artificial Intelligence, in particular clustering, can be used effectively to enhance these systems beyond confirmation and into the more important realms of detection and prediction. A tool called HIC and examined in collaboration with the Cardiff Public Health Laboratory is presented. Preliminary experiments with the system demonstrate promise. In particular, the system was able to uncover a previously undiscovered cross-infection incident.

1 Introduction Nosocomial infections are estimated to affect 6-12% of hospitalised patients. These infections have significant effects on mortality, mean length of hospital stay and antibiotics usage, and result in many hundreds of thousand pounds annual cost to the National Health Services in the UK. Outbreaks, i.e., multiple nosocomial infections caused by the same bacterial strain (e.g., the infamous multi-resistant Staphylococcus aureus or MRSA), can result from many factors, including lapses in good practice, changes in procedure that introduce a new route of transmission, or the movement of patients between wards in the same hospital and between different hospitals. Most detected outbreaks are limited to a single ward, a single medical/surgical team or a single treatment procedure. Detection and advice on treatment and control of infections (including nosocomial infections) are largely the responsibility of the local microbiology laboratory, run by the hospital or sometimes (in England and Wales) by the Public Health Laboratory Service. These laboratories receive specimens from the local hospitals and analyse them for bacteria. The bacteria are identified at the species level (there are about 4500 known species, of which about 500 cause human infection), and their susceptibility to a range of antibiotics (usually 3 to 12) appropriate to that species is assessed. These findings are then recorded and reported to the ward. Outbreaks of nosocomial infection that are detected are typically first recognised by a laboratory worker, who, over a relatively short period, has handled several specimens yielding the same unusual species of bacterium, or a common species with an

Lecture Notes in Computer Science

2

unusual pattern of antibiotic susceptibility. A possible cross-infection situation is recognised and records are searched for previous similar findings. This search often reveals that other closely similar or identical bacteria have been detected previously, and that all these infections are from either the same ward or same medical/surgical team. The cross-infection team then investigates the incident, and attempts to determine and rectify its cause. In a common alternative detection method, recent infections for a few species of particular interest are noted routinely on a board depicting the wards, and the board status is reviewed at each update, looking for anomalous concentrations of similar infections. Both methods are limited, labour-intensive and highly dependent on subjective interpretation. Furthermore, modern hospitals may have more than 500 beds and laboratories may receive in excess of 100,000 specimens per annum. This means that clues to incidents are easily lost in the vast amount of data generated; no single member of the laboratory team sees all reports, and it is less likely that a single staff member will handle several specimens from an outbreak. In addition, the range of species that may be involved has increased markedly over the years. Outbreaks involving common species with “normal” susceptibility patterns are unlikely to be detected, and those outbreaks that are detected are often found late in their progress. What is required is a systematic and ongoing search for structured anomalies in the report flow. Well established statistical techniques as well as recent advances in Artificial Intelligence, especially in the area of Data Mining, open up new possibilities for this kind of analyses in large bodies of data. This paper describes a procedure and software system, which support the automation of nosocomial infection detection through incremental clustering. The system, called HIC, has been trained and tested with data obtained from the Cardiff Public Health Laboratory (CPHL). The paper is organised as follows. Section 2 outlines our case study with the Cardiff data. Section 3 shows how the raw data is transformed by HIC using clustering and sliding aggregation techniques to improve the design of detection and prediction mechanisms. Section 4 discusses the current implementation of outbreak detection based on thresholding the transformed data and reports on promising preliminary results obtained within the context of the Cardiff data. Finally, section 5 concludes the paper and highlights areas of future work.

2 The CPHL Data: A Characteristic Case Study The CPHL currently holds about 7 years of historical diagnostic data, and new data is recorded daily. Each record or case corresponds to a particular sample collected on a given patient and is represented by a set of features as follows: CASE_DATE : ORG_LOC : WARD : FIRM : SEX : AGE : HSP : LSN : where, CASE_DATE The date at which the specimen was submitted to the Laboratory ORG_LOC The anatomical origin of the case specimen (HJ, urine, blood, faeces) WARD The infected patient’s ward FIRM The patient’s assigned medical team SEX The patient’s sex

Lecture Notes in Computer Science AGE HPN LSN

3

The patient’s age The Hospital Patient Number, a unique identifier for each patient The Laboratory Specimen Number, a unique specimen identifier The sample’s antibiograms, including the species of organisms found and their antibiotic susceptibility patterns (see below)

The first 8 features define the context of the antibiograms. From the viewpoint of infection detection, the antibiograms can be regarded as the “core” data of each case since they provide information about bacteria found. Cases where no organism has been found constitute a good proportion of the recorded data, but these uninfected patients are not particularly relevant to detection of cross-infection. Each antibiogram is represented as follows: LSN : ORG_TYPE: ORG_ASP where, LSN The corresponding case’s LSN (see above) ORG_TYPE The type of the organism (HJ, coliform, (VFKHULFKLDFROLMRSA) ORG_ASP The antibiotic susceptibility pattern of the organism, LH, a list of the organism’s resistance to a predefined set of 27 antibiotics, recorded as untested (no entry), sensitive (S), resistant (R) or intermediate (I)

The LSN feature serves only as a means to identify cases. The two other features carry the information that determines the type of organism. There are three main issues regarding the CPHL data that must be addressed by an automatic detection system. They are as follows. 27 • Sparseness. ORG_ASP has 4 possible values. Although a reasonable amount of data is collected (bacteria from around 100 infections are identified and recorded each day), the fact that there are so many possibilities within each strain of bacterium means that the data is rather sparse. Hence, any direct attempt at clustering bacterial strains based on a symbolic comparison of their ORG_TYPE and ORG_ASP will lead to a large number of small clusters. This problem is further compounded by the fact that not all of the possible antibiotics are tested on every sample. Normally, only 6 to 12 tests are performed and recorded. The choice of tests performed reflects the organism species, the site and severity of the infection. In some cases, during a known outbreak, additional antibiotics may be tested to extend the possibility of identifying an outbreak-associated organism from an extended antibiogram pattern. • Test variation. Two organisms with the same ORG_TYPE, but with different ORG_ASP should theoretically be regarded as distinct. However, test variations can cause small differences in the ORG_ASP between repeat analyses of the same organism. Similarity between ORG_ASPs can not require strict identity, but must account for “errors” in test reproducibility. • Time Dependency. The sample data represents only one instance of the bacterium. The data contains no knowledge about how long the bacterium was present in the hospital environment before the data was obtained, or how long it remains in the hospital environment after it has been detected. Hence, the recorded data does not strictly provide an accurate representation of the actual frequencies of bacteria in the hospital environment. However, because each case has an associated date, the cases can be “trended” over time.

Lecture Notes in Computer Science

4

To accommodate the above characteristics and render the data more amenable to analysis, a number of transformations are applied, as detailed in the following section.

3 Data Transformation This section deals with how the data can be utilised in a daily incremental way to allow a greater understanding of the distribution of infections in the hospital. The aim is to transform the data, using the concept of sliding aggregation, to make it more amenable to our selected data analysis methodology. Note that other methodologies may require different (or no) transformations. 3.1 Antibiograms Expansion Antibiotic susceptibilities tend to follow rules. For example, a penicillin-sensitive Staphylococcus aureus will invariably also be sensitive to methicillin, and an ampicillin-sensitive E. coli is normally susceptible to co-amoxiclav and cephalosporin. Such rules can be used to fill in some of the missing susceptibility values based on recorded ones. In order to do so, the following meta-classes and corresponding classes of antibiotics were formed. A PENICILLIN A PENICILLIN 0: PENICILLIN A PENICILLIN 1: AMPICILLIN, PIPERACILLIN A PENICILLIN 2: AUGMENTIN, (FLUCLOXACILLIN for 6WDSKDXUHXV) A PENICILLIN 3: IMIPENEM A QUINOLONE A QUINOLONE 0: NALIDIXIC ACID A QUINOLONE 1: CIPROFLOXACIN A MACROLIDE A MACROLIDE 0: ERYTHROMYCIN A TETRACYCLINE A TETRACYCLINE 0: TETRACYCLINE A CEPHALOSPORIN A CEPHALOSPORIN 0: CEPHRADINE A CEPHALOSPORIN 1: CEFUROXIME A CEPHALOSPORIN 3: CEFTAZIDIME, CEFOTAXIME AN AMINOGLYCOSIDE AN AMINOGLYCOSIDE 0: NEOMYCIN AN AMINOGLYCOSIDE 1: GENTAMICIN AN AMINOGLYCOSIDE 2: TOBRAMYCIN A GLYCOPEPTIDE A GLYCOPEPTIDE 0: VANCOMYCIN A GLYCOPEPTIDE 1: TEICOPLANIN UNGROUPED UNGROUPED: FUSIDIC ACID, TRIMETHOPRIM, NITROFURANTOIN, COLISTIN, CHLORAMPHENICOL, METRONIDAZOLE, RIFAMPICIN, MUPIROCIN

Within a meta-class (except for UNGROUPED), each class has an associated “level”, where the higher the level the more potent the corresponding antibiotics with respect to bacterial tolerance. For example, within the A PENICILLIN meta-class, PENICILLIN,

Lecture Notes in Computer Science

5

which belongs to the class A PENICILLIN 0, is a “weaker” antibiotic than which belongs to the class A PENICILLIN 2. With this classification, it is possible to design a simple set of rules expressing dependencies between antibiotic susceptibility and to use this to expand an ORG_ASP to explicitly reveal information that is implicit in the original patterns. For example, an original --SI--SRI... pattern may become R-SI--SRI... after expansion. A single (meta-)rule, instantiated as needed, is as follows.

FLUCOXACILLIN,

IF A BACTERIUM IS RESISTANT TO AN ANTIBIOTIC IN GROUP *B/$%(/1 THEN IT IS RESISTANT TO ALL ANTIBIOTICS IN GROUPS *B/$%(/0FOR 0≤1

Pattern expansion is attempted for all cases but only applied if the antibiotic in the original antibiogram is untested. If the antibiotic has been tested, the originally recorded result takes precedence even if it contradicts the expansion rule’s suggestion. By reducing sparseness, pattern expansion also facilitates clustering by improving the reliability of symbolic comparisons between patterns as discussed below. 3.2 Antibiograms Comparison Clearly, the expansion rules discussed above limit the amount of symbolic mismatch between ORG_ASPs that should be treated as originating from the same organism. However, even then it is unrealistic to rely on exact symbolic matching. What is needed is a clustering mechanism based on some reasonable measure of similarity. The similarity measure implemented in our system, combines a rather simple similarity coefficient with a user-defined threshold as follows. In order to be comparable, two antibiograms must have the same ORG_TYPE. If they do, the entries of their ORG_ASP patterns are compared in a pairwise fashion. Comparisons involving an I result or an empty entry in either pattern are ignored. The number of exact matches (i.e., S-S or R-R) and the number of mismatches (i.e., S-R or R-S) are used to compute the following similarity coefficient.

6LP&RHI

=

# RI PDWFKHV # RI PDWFKHV + # RI PLVPDWFKHV

For example, the following two ECOLI antibiograms of length 15 ECOLI: ECOLI:

R S

S S

I S

R R

R

R R

S

S S

S R

S S

S I

S R

S I

S S

S

give rise to 6 matches and 3 mismatches, and thus to a similarity coefficient of 0.67. A user-defined threshold can then be used to determine whether two organisms may be considered the same. For example, if the threshold is 0.6, the two ECOLIs above are deemed to be indistinguishable. Armed with SimCoef (and an associated threshold), it is possible to cluster antibiograms. This is accomplished in our system using a sliding aggregator as detailed in the following sections.

Lecture Notes in Computer Science

6

3.3 Sliding Aggregation Sliding aggregation is a method that clusters data at two points in its operation in an incremental manner. Essentially, the mechanism is based on a period of time t, with a sliding window of n components (the fixed window size) in which the ordered data is placed. There must exist data for at least n time periods before the aggregator can be used. At the start, the leftmost compartment of the window contains data from the time period t-n+1 and the rightmost compartment of the window contains data for the time period t0. The window then “slides along” the data, so that when data from a subsequent time period ti (i≥1) is added to the window, the oldest element (i.e., t-n+i) is removed from the window and all other elements occupy a new position directly to the left of their last position. The operation of the sliding window can be used to implement a filter across any ordered set of data, although its performance is highly dependent on t, n, the size of the set of ordered elements and the ability to efficiently order the elements. With respect to the diagnostic data, it makes sense to set the time-period t to 1 day, hence each component of the window is the case data for the day it represents and incremental daily updates to the sliding window are possible. As the elements here are naturally ordered by time, the next critical choice is the value of the fixed window size n. The application domain suggests that n can be set to any value representative of the estimated time that organisms remain present in the hospital environment after detection. Currently, this is set to 35 days. (i.e., t=1, n=35). Note that the use of the sliding window helps to compensate for the fact that the data represents investigated instances and does not account for the length of time that the bacteria remain in the hospital environment after detection (see section 2). By clustering the case data within each component of the window with respect to their antibiograms, one may compare equivalent infections on a daily basis (section 3.3.1). Furthermore, one can also cluster daily clustered data within a window (section 3.3.2). By taking these results for each window on the data as a whole (i.e., as the window slides or is updated with new data each day), the data can be transformed into a set of sequences for each bacterial type that is the aggregate of the data as the window slides along. The transformed data is more representative of the bacteria causing infections, more amenable to subsequent analysis, and can be readily presented for intuitive visual inspection by laboratory staff. Also, further transformations can be made readily. For example, one may consider an exponentially weighted modifier giving new data in the window a greater effect than older data. 3.4 Incremental Clustering This section shows how antibiograms are clustered as data from the laboratory is added to the sliding aggregation system on a daily basis. For horizontal clustering, it is assumed that the aggregator window is full (i.e., at least n=35 days’ worth of data are available).

Lecture Notes in Computer Science

7

3.4.1 Vertical Clustering. Raw daily data is clustered using the above procedure and a threshold provided by the laboratory staff. Antibiograms of bacteria of the same organism type are compared to one another in turn until all have been compared. Each antibiogram has two frequency values associated with it: the “actual” frequency of the antibiogram and its “clustered” frequency. The actual frequency of an antibiogram is the number of times it occurs identically (i.e., same ORG_TYPE and same ORG_ASP) in a day. The clustered frequency of an antibiogram is based on SimCoef (see section 3.1) and its associated threshold. Every time two antibiograms are considered sufficiently similar, their respective actual frequencies are added to each other’s clustered frequencies. The following are two examples. Organism: CNS Actual Daily Frequency: Clustered Daily Frequency:

RRSS SR 1 7

SR

SS S

Organism: MRSA Actual Daily Frequency: Clustered Daily Frequency:

RRRS SR 12 13

SR

SS S

As vertical clustering is applied to all bacteria in the day’s data, no information relating to the antibiograms’ actual ORG_ASPs is lost, which is important to the subsequent horizontal clustering of the incremental process. 3.4.2 Horizontal Clustering. Clustered daily data make up the contents of the day’s component in the sliding aggregator. Once the sliding aggregator has been updated, a further clustering operation is performed on the data. Here, the system tries to create the “highest clustered frequency” path through the sliding aggregator possible for each clustered antibiogram in the sequence. The output here is a sequence of both actual and clustered frequencies for each unique antibiogram within the window. This is achieved by beginning with the first cell and iteratively clustering each instance of the same organism/antibiogram type within it against all those in the next cell, then picking the first highest frequency antibiogram that satisfies the similarity measure. As progress through the window continues new previously unique antibiograms may be uncovered; for these new antibiograms a backward search through the aggregator window is performed before proceeding to ensure that each unique antibiogram in the window has its complete highest clustered frequency pattern enumerated. The following are two examples. Organism: CNS RRSS SR S R SS S Actual Trended Frequencies: 0:0:0:0:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 Clustered Trended Frequencies: 0:0:0:0:0:0:0:0:0:0:0:7:2:1:2:1:6:4:2:3:2:0:5:2:6:4:6:4:2:1:1:1:5:5:1 Actual Trended Summation: 1 Clustered Trended Summation: 73 Organism: MRSA RRRS SR S R SS S Actual Trended Frequencies: 2:6:4:3:2:2:1:0:9:12:3:4:2:1:0:4:3:4:7:3:1:1:4:4:2:4:2:0:0:9:4:6:0:6:6

Lecture Notes in Computer Science

8

Clustered Trended Frequencies: 2:9:8:9:4:6:2:1:10:13:9:10:2:3:0:6:9:8:9:5:1:1:7:7:6:11:4:2:3:11:5:8:2:6:6 Actual Trended Summation: 121 Clustered Trended Summation: 205

At this point, the focus of the data has shifted from that of the original case data as a whole to that of the antibiogram. The system now has the opportunity to analyse the data with respect to particular organism/antibiogram type. Probability distributions over the other features in the cases can be calculated to provide a context to these infection levels. Also the summation of frequencies within the sliding aggregator can be obtained and used to construct higher-level sequences with respect to particular bacteria (filters, e.g., exponential decay could also be applied to these).

4 Data Analysis – Detection The data transformation methods of section 3 have been implemented in a software system, called HIC [5]. This section now details the detection mechanism used by HIC to uncover potential outbreaks and outlines a method to perform prediction. Once a sequence of clustered frequencies has been obtained for each organism/antibiogram type, HIC can attempt to discover anomalous bunching of similar infections. The system could carry out this stage of the process in a variety of ways, either supervised or unsupervised. Currently, HIC relies on a rather simple thresholding method. First, the stored “total” frequency for the organism/antibiogram is obtained. The expected frequency is then calculated from the date range over which the system data was collated and the size of the sliding aggregator window. This value can then be compared against the clustered value obtained from the sliding aggregator frequency total for the organism. The user defines a threshold, and if the sliding aggregator total is greater than the threshold times the expected frequency for the given organism, then this is noted as an anomaly and presented to the user for inspection. The following is a simple example. Threshold = 1.8 (80%) !! Possible Anomaly Detected !! Sequence Frequency - 13 System Frequency 7 Organism: KPNE R RS SSSS S SSS S 0:0:0:0:0:0:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:1:0:0:0:0:0, sum = 2 0:0:0:0:0:0:0:0:0:0:0:0:0:1:0:1:0:0:0:0:0:0:1:0:0:2:1:1:0:3:0:1:1:0:1, sum = 13

This is a fairly intuitive way of determining whether or not a specific organism has exhibited anomalous bunching. Yet, it has proved successful in detecting known outbreaks in the historical laboratory data. It is also suitable for unsupervised detection of anomalies in a data stream, with a default threshold that may be amenable to automatic adjustment by machine-learning methods in later versions of the system. It is also readily adapted to interactive supervised training of the system.

Lecture Notes in Computer Science

9

Details of the implementation of the HIC system are in [5]. The data provided by the Cardiff laboratory was used to train and test HIC. The experiment, which focused on detection, proved successful in highlighting a possible outbreak that remained undetected by the laboratory. There is an ongoing infection problem with Klebsiella at the University Hospital of Wales. Briefly, there have been sporadic clusters of colonisation with a few cases of infection from 1995 to 1999. The strains involved were mostly identified to the species Klebsiella aerogenes and showed resistance to multiple antibiotics. The data downloaded as input for development of the cross-infection detection program included one of these clusters. This was not actually called as an outbreak, because small numbers of patients were involved, and the organisms were identified as multiresistant Klebsiella oxytoca, rather than Klebsiella aerogenes. However, in retrospect, these organisms had closely similar antibiograms and biochemical patterns, and probably represented a cluster of nosocomial colonisation/infection. This cluster was strikingly obvious in the teaching set output from the detection program. There has not been sufficient time for fuller inspection of the output outside the Klebsiella group, where research interests engendered greater familiarity with the ongoing infection status. However, this result was promising, particularly as the cluster had not been recognised as such in the laboratory at the time the data was downloaded. In another experiment extending HIC, automation was taken further as several methods of detecting outbreaks using thresholding techniques were tested [2]. The results have yet to be validated by the microbiologists.

5 Conclusion This paper describes a system of automatic nosocomial infection detection and prediction, based on AI methods. The system uses clustering and sliding aggregation techniques to build sequences of data containing the actual and clustered frequencies centred on the organisms involved. This methodology is intended to transform the raw data into a form that takes into account the sparseness of the data, its instance based nature when gathered and the fact that values contained within it are subtly interchangeable. It maintains implicit information on the evolution of bacterial strains and their changing resistance to antibiotics over time. It also makes the data more amenable to subsequent analysis by, for example, Case-Based Reasoning, where it is possible to store higher-level aggregated sequences and feature-bound probability distributions of organisms that have previously led to outbreaks and to use them for the prediction of similar future outbreaks. Preliminary experiments with data from the Cardiff Public Health Laboratory on detection demonstrate promise, as in at least one situation, the system was able to detect a possible outbreak that had remained undetected by the laboratory. The system’s functionality could be extended as follows. Rather than using fixed, user-defined thresholds, the system must be capable of learning and adapting its thresholds for reporting anomalies on the basis of operator feedback based on “level of

Lecture Notes in Computer Science

10

interest”, “confirmed outbreak”, “possible seasonal variation” and “antibiotic test variability”. Other essential feedback items may be added in the light of development work. Changes in detection parameters should be checked automatically to see if these would have affected detection of previously confirmed outbreaks, or would have revealed previously undetected anomalies. Where an outbreak has occurred, but not been detected by the system, the operator should be able to specify the specimen numbers, species and susceptibility pattern involved. The system should then test modified parameters, optimising detection of the new and previously detected outbreaks, and reviewing the database. Previous parameters must be available for re-institution if the optimisation process fails, or if the new optimum is rejected by the user. It may be necessary to operate the system with several distinct threshold levels or interest profiles, particularly if other potential uses, such as detection of factors influencing frequencies of specific infections, are pursued.

Acknowledgements The first author was supported in part by the MRC Health Services Research Collaboration and a British Council/JISTEC scholarship to IBM Tokyo Research Laboratory.

References 1. Althoff, K., Auriol, E., Barletta, R. and Manago, M.: A Review of Industrial Case-Based Reasoning Tools. AI Intelligence (1995) 2. Bouchoux, X.: HIC Dataset Report. Unpublished Manuscript, Advanced Topics in Machine Learning, University of Bristol, Department of Computer Science (1999) 3. Bull, M., Kundt, G. and Gierl, L.: Discovering of Health Risks and Case-based Forecasting of Epidemics in a Health Surveillance System. In Proceedings of the First European Conference on Principles and Practice of Knowledge Discovery in Databases (PKDD’97). LNAI, Vol. 1263, Springer (1997), 68-77 4. Kolodner, J.: Case-Based Reasoning. Morgan Kaufmann (1993) 5. Langford, T.: A Prototype System for Hospital Infection Control. Technical Report PR4-9909, University of Bristol, Department of Computer Science (1999) 6. Leake, D. (Ed.): Case-Based Reasoning: Experiences, Lessons, and Future Directions. AAAI Press (1996)

Suggest Documents