Ongoing problems in healthcare supply make it imperative to establish telemedicine as a feasible concept to ensure the quality of medical treatments and reduce costs. With TiEE, the Telemedical ILOG Event Engine, Fraunhofer ISST fosters the research to process streams of vital signs in telemedical scenarios using Complex Event Processing (CEP) in an Information Logistics (ILOG) manner. ILOG means to reduce the amount of information by preprocessing existing data and to route high-grade decision at the right time to the right person. As basic building blocks we developed the concepts of telemedical events (TE), Telemedical ILOG Listener (TIL) and TIL-Profiles on top of the event processing engine Esper [20-23]. TiEE analyzes the incoming patient specific streams of telemedical events and tries to detect relevant trend patterns. In a second step these got aggregated to higher level decisions.
The continuous measuring of vital signs results in an unmanageable amount of data and furthermore information that could be deduced. Physicians therefore complain about the problem of information overload, which means that the information processing requirements exceed the information processing abilities [12]. Investigating solutions for solving the problem of information overload in telemedical scenarios at first means to reduce the amount (quantity) of data. Second, the time for acquiring information has to be reduced by distributing the right information, at the right time to the right place.
To cope with the problem of information overload in telemedical scenarios of continuous monitoring of vital signs we investigated the Telemedical ILOG Event Engine (TiEE). TiEE is based upon scientific outcomes of the following two research areas: Information Logistics (ILOG) and Complex Event Processing (CEP). The former is always related to the metaphor of transporting the right information at the right time to the right place [6, 14]. The latter enables one to process so called events in realtime by filtering, aggregating and transforming them into more complex events. Why is CEP an appropriate technology for ILOG processing in telemedicine? Every vital sign monitored by a telemedical application is some kind of event. Such an event could be related to additional information like the time of generation or the value of the vital sign itself. By analyzing all data and information related to such an event, under consideration of the history and order, we are able to reduce the amount of irrelevant vital signs. Furthermore we can aggregate events to higher order decisions, so called complex events.
Thus, the purpose of the paper is to show how information demand can be mapped on concepts of event processing to optimize information supply in telemedical scenarios by reducing the amount of information overload. In the following we will give an overview of the state of the art in ILOG and CEP. Furthermore we’ll discuss the basic concepts we investigated to implement TiEE, which are telemedical events, Telemedical ILOG Listener (TIL) and Telemedical ILOG Listener Profiles (TIL-Profile). At the end we’ll show first evaluation results based upon two different use cases. 2
TiEE is focused on the two research areas complex event processing and information logistics to foster a fast, on-time processing of telemedical values. Basic definitions and concepts of CEP were developed and defined by Luckham, Chandy and Bates [2, 3, 18]. Citing them, an event is „an object that is a record of an activity in a system“. A detailed overview about open questions and the current state of research in CEP is discussed in the Dagstuhl Seminar on „Event Processing“ in 2010 [4]. In [17, 25] Lowe and Weber present ongoing work on applying CEP to health data using the event processing engine Esper in the context of the Stride project „Stanford Translational Research Integrated Database Environment”. One basic open question is how to cope with the problem of heterogeneity of medical data to achieve an overall processing.
The need for information logistics is caused by an increasing number of situations of information overload. According to Wilson [27, 28] information overload expresses „that the flow of information […] is greater than can be managed effectively“. ILOG is viewed as a research area to deliver the right information, in the right format at the right time to the right place and is partially used for information filtering or with context-models to optimize communication in the healthcare domain [7, 15, 26]. A broad overview of the state-of-the art research in information logistics is given by Haftor et al. [9] by analyzing 102 scientific publications. The link between CEP and ILOG is given by Chandy [4] by mentioning that „Disseminating and distributing is also about getting the right information to the right consumers at the right time.“.
Alternative approaches to the usage of CEP and ILOG could be found in the research area of data streams. They could be used for real-time processing of data like shown within STREAM [1]. Geesen [8] gives an introduction how data streams could be used to process high frequent data in the area of Ambient Assisted Living. All approaches cope with the problem that data or information isn’t standardized, developed concepts are not that modular and they don’t take ILOG into account. Therefore many papers in both research areas give an outlook on using events and event based processing for real time data optimization. 3
The reduction of information overload in telemedical scenarios requires to process telemedical information in the sense of aggregation, filtering as well as analysis of causal and temporal relationships. There are three basic requirements for the processing of vital signs in telemedical scenarios one should take into account [21]: Sensors for measuring vital signs act in a highly distributed manner. Every type, e.g. blood pressure or blood sugar concentration, is a result of a single sensor or telemedical application. The prospective solution should be able to process telemedical values from different sources to achieve an overall monitoring and decision making. This requires an overall description of a telemedical value, in sense of a vital sign, as well as methods to modular process different types of telemedical values depending on the actual medical situation of a patient. Monitoring of vital signs in telemedical scenarios produces a high amount of data which has to be processed in real-time. Not every single vital sign represents an important medical situation. The relevance depends upon the temporal ordering as well as the coincidence of different types of vital signs. So, a solution has to aggregate a set of those to higher order decisions. The delivery of those decisions mentioned above should be done in an intelligent way. So, a derived decision should be transported at the right time to the right place, e.g. prior to a physician a notification should be emitted to a family member. With TiEE, the Telemedical ILOG Event Engine, Fraunhofer ISST investigated methods for event based processing of vital signs in telemedical scenarios considering the requirements mentioned above. We’ll start by giving a broad introduction to the information logistics processing within TiEE. Afterwards we’ll describe the three basic concepts telemedical event, TIL and TIL-Profile in more detail. 3.1
We started our discussion about information overload in telemedical scenarios by stating that it is not possible for a physician to deduce relevant information out of a stream of thousands of vital signs. Thus, realizing a support for clinical decision making one has to reduce the amount of data and deduce higher level, relevant information. Delivered relevant information should fulfill a given information demand, thus a physician needs a possibility to express its demand.
With TiEE we investigated a graphical demand modeling approach (Demand Modeling Language) upon the Clinical Algorithm Standard (CAS) [24] which is well known in medicine. Within CAS we have five elements (see Fig. 1): a start node (oval), a condition (rhombus), an activity (rectangle), a terminal node (circle) and a connector (arc). A condition is the evaluation of a given expression, like pulse higher than 150. The logical AND concatenation is modeled by writing conditions from left to right and the OR concatenation is realized by writing conditions down. The result of the evaluation of a set of conditions could be the terminal node, thus nothing will happen, or a red or green colored activity. An activity symbols the necessity to inform about a relevant situation. Relevance is divided into critical (red) and uncritical (green) situations.
Measure of blood pressure yes
Measure of pulse yes c1 yes a1 Start: Patient with obesity yes
a2 Measure of weight yes yes yes
a4 c4 a3 c2 c3
Regarding the figure shown above we have a patient coping with obesity. He has to measure weight, pulse and blood pressure. Condition c2 is only valid in case that the pulse isn’t measured otherwise condition c1 is valid which would lead to action a1 or a terminal node.
The graphical model has to be transformed into processable data structures, thus we defined a set of structures upon the Extended Backus-Naur Form (EBNF) in such a way that the Demand Modeling Languages ⊂ is a subset of an Event Processing Language and further can be mapped to the extending concepts like TILs and TIL-Profiles. Below we sketched up the EBNF specification of the formalize demand and afterwards in Table 1 examples according to Fig. 1. demand = “DEMAND” (condition | condition “” condition) “ACTION” activity “ELSE“ activity “;“ CRLF ; CRLF ;
bloodpressure.BP1 = INCREASING AFTER pulse.BP1 = INCREASING INFORMATION Critical increase of blood pressure and pulse. Please stay in contact with the patient.;
RELEVANCE 80; CTITICALITY 90;
RECIPIENT ID1 | Servicemitarbeiter | JMS | service_in | DIRECT;
Now, the above expressed and formalized demand has to be mapped on the concepts of TILs and TIL-Profiles bearing the Event Processing Language used within TiEE in mind. At first, an incoming telemedical event will be processed by a patient-specific TIL-Profile, like described in chapter 3.4. Afterwards a set of TILs is trying to detect characteristic patterns within the stream of telemedical events, so called Complex Trend Pattern Events (CTPE). A CTPE is an abstraction of a set of telemedical events (see also Fig. 2) and characterizes the progression of the measured values. Based upon the research of Charbon et al. [5, 10] we distinguish five basic types of trend pattern: slope, slope reverse, saltus up and saltus down steady.
t h g i e w e s l u p Thus, we derive an abstraction, the pattern, from a set of underlying measurements to reduce the amount of data and cope with the problem of information overload. The derived pattern is described using different types of parameters, e.g. the statistical spread or the amount of increase/decrease. As a basic feature of the TIL concept one can use any kind of algorithm for trend calculation as long as it fulfills the formal definitions of a TIL. CUSUM (cumulative sum) or ARIMA (autoregressive integrated moving average) based approaches are examples for processing time related data.
In summary, every TIL derives CTPEs for a specific telemedical event, i.e. a type of vital signs, and forwards them up to the referring TIL-Profile. Now, this TILProfile has to detect higher order, demand fulfilling patterns within the set of forwarded CTPEs. By using the formalized demand the processing within a TIL-Profile is organized as follows: Trends of same underlying types of vital signs: The repeated increase, decrease etc.
of a set of vital signs could be abstracted to a single trend pattern. Trends of different underlying types of vital signs: It is obvious that there is a relation between weight and blood pressure in cases of cardiac decompensation. A TIL-profile has to detect the increase of both during a given time window and derive a new abstraction, emitting a new trend pattern.
Upon rules registered in the TIL-Profile, information logistics decisions are made to generate and send relevant information to a person. 3.2
Within telemedical scenarios you’ll find a lot of different sensors from various manufacturers to measure vital signs. The overall processing of vital signs using TiEE requires some concept to standardize the input. While TiEE is based upon the idea of complex event processing, every vital sign should be interpreted as an event. Therefore we defined the term telemedical event as a measurement of a telemedical value and an instance of a telemedical event type, formatted in the HL7 Telemedical Event Format [20]. The HL7 Telemedical Event Format is a message format we investigated to achieve an interoperable transportation of Telemedical Events. The refinement of this format is done by combining elements of the HL7 standard with such from the IEEE 11073 standards. HL7 is a widespread international standard for data exchange in the healthcare sector [11]. All HL7 V3 data types are based upon the HL7 Reference Information Model (RIM). In turn IEEE 11073 is a family of standards to harmonize the output of sensors using the IEEE 11073 Domain Information Modell (DIM) [13]. Using both standards we modeled a format that takes all attributes for complex event processing and ILOG processing of vital signs into account. Formally a telemedical event is an n-tuple ∶= ( , 7 ) where: ∶= ⋃ ∈
is the set of all telemedical events. is an event based upon a telemedical event type ∈ .
: → is a transformation into the HL7 Telemedical Event Format. 7 Two telemedical events
are identical and 7 ( ) = 7 . 7 event into the HL7 Telemedical Event Format. 3.3
≡ if and only if = is a function to transform a given A TIL-Profile realizes a patient specific filtering of the incoming telemedical events. The second step of filtering the high amount of events is done within the concept of a TIL. Related to CEP a TIL is some kind of Event Processing Agent, specialized for processing one type of telemedical values e.g. blood pressure events [23].
Besides the operation of filtering, a TIL encapsulates methods to detect patterns of interests in the stream of incoming events. Therefore different types of rules could be instantiated. Thus, a TIL is a modular piece of concept to encapsulate algorithms which are highly specialized to process one type of vital sign but is not specialized to a patient. That enables an easy reuse.
Formally a Telemedical ILOG : = ( , , , ):
Listener is defined as an n-tuple as follows ∶= ⋃ is the set of all TILs. etin: The event type on which all instances ( ) = are based upon. Initially this is the telemedical event type ∶= . ETout: Analogous to the definition of etin, ETout is a set of event types | | ≥ 1 which are permitted to be emitted as output. fin: The filter function is based upon a boolean function → ∶ (, ).
Given to functions and it is imperative that ≡ are identical if and only if ( ) = ( ) that is, both functions relate to the same type of vital sign. Two mutually different functions ⊓ = ∅ are disjoint. VL: Every TIL consist of processing logic VL which is a set of rules in terms of: ∶= | = ≡ Two TILs are identical and ≡ .
≡ Every medical situation represents an individual moment in lifetime. Thus, TiEE has to offer functionalities for a patient specific processing of incoming telemedical events, which very fast can be adapted to a new situation. Therefore we investigated the term TIL-Profile. A TIL-Profile realizes a patient specific filtering of telemedical events thus it reduces the amount of data. Afterwards the event is processed, depending on the type of vital sign, by one of the TIL’s (see section 3.3) connected to this profile. For every type of vital sign one has to register one TIL. In the following the output of the TIL’s is processed within the TIL-Profile by additional filtering, pattern detection and transformation into higher order decisions. That means that a TILProfile correlates the progression of different types of vital signs, e.g. blood pressure and weight, detects a medical situation of relevance and derives a higher order medical decision.
Formally a Telemedical ILOG Listener Profile is defined as an n-tuple as follows : = ( , , , , ): ∶= ⋃
set of all TIL-Profiles. etin: The event type on which all instances ( ) = are based upon. Initially this is the telemedical event type ∶= . ETout: Analogous to the definition of etin, ETout is a set of event types | | ≥ 1 which are permitted to be emitted as output. fin: The filter function is based upon a boolean function → ∶ ( , ).
Given to functions and it is imperative that ≡ are identical if and only if ( ) = ( ) that is, both functions relate to the same patient. Two mutually different functions ⊓ = ∅ are disjoint. TIL: The set of registered TIL’s ∶= , ⋯ , in the TIL-Profile where | | ≥ 1, so at least one TIL has to be registered. VL: Every TIL-Profile consist of processing logic VL which is a set of rules in terms of: ∶= | = The architecture of TiEE is based upon the event processing engine Esper which is commonly used in many commercial products. Fig. 3 gives a broad overview about the main components and concepts like described in the past sections.
Starting at the bottom we have some kind of vital sign sensors from different manufactures. The sensors are connected to TiEE through Bluetooth HDP, supporting the IEEE 11073 standards family. To achieve an overall processing a single vital sign is interpreted as a telemedical event and will be encapsulated in the HL7 Telemedical Event Format. All events get transported to the event channel ordered by time. Above the channel we build the engine, introducing TIL-Profiles and TIL using Esper core and Esper queries of the Esper engine.
To realize a patient specific filtering like required by the TIL-Profile we extended Esper with the concept of PES, a patient-individual event stream. A PES formally represents an individual event stream that supports and bundles all types of events of one single patient. Thus there is a bijection between the patient and PES. Accordingly, any PES are pairwise different, in other words all PES are distinct, as each PES is characterized by a different patient, ≠ ∀ , where ≠ . The concept of a PES is based on the Variant Stream of Esper. All events of one single patient will be redirected in separate PES, with the help of a filter criterion, which checks for an individual patient identification. Likewise, a PES serves as the event source for all TILs in one TIL-Profile.
Furthermore we implemented methods and services to administrate TiEE. The developed services serve the purpose to modify the current system afterwards. So it is possible to add or remove main components like TIL and TIL-Profiles. In more detail the services allow to add, modify and remove patients, TILs and statements. Also, the services provide information about the components within the system. All services are designed as REST services and work with JSON objects. 4
The evaluation of TiEE is done upon two different data sets gained from two different projects. The first project is FitPit, the Fitness Cockpit, a solution to optimize preventive and rehabilitative trainings developed at Fraunhofer ISST [19]. Pulse and oxygen saturation as well as weight and blood pressure will be measured at the beginning and at the end of the training. In total we recorded 2450 measurements gained from 10 patients in terms of a long term measurement. The second project is the Vital Signs Dataset of the University of Queensland [16]. They recorded over 10 vital sign parameters from 32 patients undergoing anesthesia. The data was recorded with a solution of 10ms. Thus, in total we have around 240.000 measurements per patient, depending on the duration of the surgery. Now, before we can apply the datasets above, we have to define the main questions that have to be evaluated using TiEE:
Question 1: Is TiEE capable of reducing the amount of incoming data and process them according to the defined information demand? Question 2: Is TiEE capable to process long-term trends as well as high frequent data? Question 3: Does the usage of TiEE reduce the overall implementation efforts for an analytical infrastructure? What we won’t try to answer at this point is, if TiEE is capable of being better in decision making compared to a physician. To answer the first question we started with modeling the information demand using CAS like mentioned before. Thus, we can prove that it is possible to map some kind of formalized demand to processing rules. To show the amount of data reduction we calculated the percentage of CTPEs per Minute. Within the FitPit scenario we had 1/11520 CTPEs per minute, respectively one trend within eight days. This very low value is caused by the long-term characteristic of the use case. In Fig. 4 we show the ratio of incomings events and fired activities. Thus, there is a recognizable reduction of data or irrelevant information because activities are only fired according to a formalized information demand. 1200000 1000000
The high-frequent data of the second use case produces 8.3 CTPEs per minute. It is possible to optimize or modify the percentage of CTPEs by configuring the underlying algorithm. Thus, we can also show that TiEE is capable to process long-term as well as high-frequent data. We also evaluated the performance of TiEE including routing and algorithmic processing of the incoming events. The average duration is around 15ms per event. The third question is implicitly proven by the usage of TiEE within two different scenarios. We were able to reuse once defined TILs within both scenarios in terms of a repository. Thus, the only effort was to model the information demand and map it to a TIL-Profile. Furthermore with TiEE a basic infrastructure for communication I/O is already given. Summarized we can point out that TiEE supports an optimization of information supply by reducing the amount of data. 5
With TiEE, the Telemedical ILOG Event Engine, we investigated a solution to cope with one main problem in telemedical scenarios: information overload. Especially the continuous measuring of vital signs requires an intelligent reduction and processing of data in real-time. Since a medical situation changes very often over time, TiEE uses TIL-Profiles and TILs as a modular concept to facilitate the reuse of once developed rules and algorithms. Like described above, trend detection is an important class of algorithms for pattern recognition in streams of vital signs. At the moment TiEE is based upon trivial calculations using the CUSUM method to detect critical increasing, decreasing and stagnation of them. To show the technical feasibilities of TiEE we executed a first evaluation of the conceptional and implementational insights. TiEE need around 15ms per event and is capable to reduce the amount of date by generating CTPEs. In the future we’ll start to evaluate also the medical evidence of TiEE. 6 1. 26. 27. 28.
IEEE: ISO/IEEE 11073-10201:2004: Health informatics Point-of-care medical device communication Part 10201: Domain information model. (2004).
Koch, O.: Process-based and context-sensitive information supply in medical care. Proceedings of the CIR’07 Workshop on Context-Based Information Retrieval in conjunction with CONTEXT-07. (2007).
Koch, O., Rotaru, E.: Using Context to Improve Information Supply in the Medical Sector. In: Abramowicz, W. et al. (eds.) Business Information Systems Workshops - BIS 2010 International Workshops. pp. 192–203 Springer (2010).
Liu, D. et al.: University of Queensland Vital Signs Dataset: Development of an Accessible Repository of Anesthesia Patient Monitoring Data for Research. Anesthesia & Analgesia. (2011).
Lowe, H.J. et al.: STRIDE--An Integrated Standards-based Translational Research Informatics Platform. AMIA. 2009, 391–395 (2009).
Luckham, D.C.: The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley, Boston (2002).
Meister, S. et al.: FitPit – Fitness cockpit: information system to optimize training Schedules in Rehabilitation. ECIS 2013 Proceedings. 106, (2013). Meister, S.: Telemedical Events: Intelligent Delivery of Telemedical Values Using CEP and HL7. In: Niedrite, L. et al. (eds.) BIR Workshops. Springer (2012).
Meister, S.: Usage of CEP and HL7 to Solve Information Logistics Problems in Telemedicine. 4th International Workshop on Information Logistics and Knowledge Supply for Viable Enterprises (ILOG 2011). (2011).
Meister, S., Koch, O.: Using Complex Event Processing and Context for Intelligent Information Filtering and Supply. In: Schilling Klaus and Leutert, F. (eds.) 1st IFAC Conference on Embedded Systems, Computational Intelligence and Telematics in Control CESCIT 2012. (2012).
Meister, S., Stahlmann, V.: Telemedical ILOG Listeners: Information Logistics Processing of Telemedical Values Using CEP and HL7. In: Wichert, R. and Eberhardt, B. (eds.) Ambient Assisted Living - Advanced Technologies and Societal Change. Springer (2012).
Society for Medical Decision Making: Proposal for Clinical Algorithm Standards: Society for Medical Decision Making Committee on Standardization of Clinical Algorithms. Medical Decision Making. 12, 2, 149–154 (1992).
Weber, S. et al.: Implementing a Real-time Complex Event Stream Processing System to Help Identify Potential Participants in Clinical and Translational Research Studies. AMIA. 2010, 472–476 (2010).
Willems, A. et al.: Information Logistics Research Report - Frameworks in Healthcare Industry. (2009).
Wilson, T.D.: Information Overload: Implications for Healthcare Services. Health Informatics Journal. 7, 112–117 (2001).
Wilson, T.D.: Models in information behaviour research. Journal of Documentation. 55, 3, 249–270 (1999).