Complex Event Processing in Healthcare IoT Solutions

Eric J. Bruno
January 2016

(Cover image courtesy of Verizon)

The era of complex event processing, especially within IoT solutions, is upon us, and can be  leveraged to promote safety and innovation in many areas of healthcare technology. 

According to the World Health Organization, 80% of chronic disease deaths occur in low-to-mid income countries.
“Preventing Chronic Diseases: A Vital Investment” 
-World Health Organization

The need for improved healthcare with reduced costs is driving innovation in mobile health. Healthcare providers and product vendors are working to deliver solutions for personalized medicine, improve disease management through advanced telemetry, and leverage population health data to better measure the effectiveness of care and treatment. Modern technology is poised to address the related challenges of remote patient care. These challenges include connectivity, security, privacy, advanced analytics, data visualization techniques, and the remote management of monitoring devices.

As more medical devices connect patients to healthcare providers over the Internet, they become an important and growing segment of the Internet of Things (IoT). The vision of IoT is to integrate diverse sets of data from devices and sensors and the rest of information technology (IT) to enable analytics that can anticipate events, issues, and other needs. As a result, software systems and healthcare providers together have a more complete view of their patients’ health regardless of location or time. In this case, the “things” are medical devices and the patients connected to them. 

Mobile health (mHealth) covers medical practice, solutions, and healthcare supported by mobile patient monitoring devices (i.e. fitness bracelets, watches, wireless medical devices, and so on). According to research from Berg Insights, there are five main segments of mHealth: professional healthcare solutions, inpatient monitoring, remote patient monitoring, assisted living and tracking, and personal wellness. Integrated mHealth IoT systems can be used to implement the following innovative solutions:

Solutions across all these segments create a connected care value chain composed of sensors and devices, connectivity providers, monitoring services, and mobile and IoT platforms. This intersection of mHealth and IoT has the potential to reduce waste, lower healthcare costs, and improve the overall level of care without extra burden.

The Risk of Error in Patient Systems

There’s risk from error for each type of mHealth IoT solution, but the severity varies widely for each. For example, a complete failure of a remote monitoring solution might result in inconvenience, with the doctor resorting to traditional methods (such as calling the patient to schedule an appointment). However, even a slight inaccuracy in a closed-loop medical device can result in the administration of an incorrect medication dose, resulting in ineffective care, or worse.

To ensure patient safety in mHealth IoT systems, more than careful programming and testing is required. An entirely different product development approach and paradigm must be used. This is where complex event processing (CEP) can help.

Complex Event Processing for Healthcare IoT

As mentioned, it’s critical to ensure error-free operation of patient healthcare technology systems. Traditional programming practices aren’t always enough to ensure failsafe operation. Engineering healthcare solutions through event processing—using commercial or open-source CEP systems that have been tested across a wide range of use cases—may arguably deliver a higher level of safety. This helps to both mitigate risk and increase the level of patient care.

According to the World Health Organization, chronic diseases include heart disease, cancer, stroke, respiratory illness, and diabetes.
“Chronic Diseases and Health Promotion” 
-World Health Organization

Event processing for healthcare applications, specifically IoT-based applications that combine real-time data streams from medical devices with other patient and community data, offers multiple benefits. First, let’s take a quick look at what event processing is in general.

Event Processing Overview

A typical database management system (DBMS)—such as a relational database—is designed to store, query and manipulate static data stored as rows and columns. Relational databases are mostly not used to process real-time streaming data. Instead, data stream management systems (DSMS) are used to process continuous feeds of data in a method analogous to a database. For example, whereas relational databases often use Structured Query Language (SQL) to query and manipulate static data, stream management systems use a modified form of SQL— such as Continuous Query Language (CQL), StreamSQL, or Event Processing Language (EPL)— to work more efficiently with streaming data. 

Event processing in a DSMS takes place on just one stream of data. Complex event processing (CEP) takes place on more than one stream of data, where the streams may be of varying types. For instance, a CEP system may combine processing of data streams from one or more devices with static data stored in a database. 

Events may also arrive structured or unstructured, each with very different meaning. For example, a CEP system may combine a social media feed (unstructured data) with stock market quotes (structured data) to form a type of algorithmic financial trading system. In such a system, certain combinations of events at the right times may result in a defined action (for example, buying or selling a specific company’s stock). 

Continuous Query Language for Event Processing

CEP systems and CQL both have their roots in research at Stanford University. A CEP system is used to process multiple streams of data or events and reason about them in real-time. The result may be to filter out events as meaningless, combine or aggregate events to form new derived events, or to respond to one or more events as appropriate (if it falls within or outside of a predefined range of values, for example).

Commercial CEP implementations of CQL exist, such as Oracle’s Event Processing, or open-source implementations such as Odysseus.

CEP for Compliance and Risk Management

By monitoring events, then performing simple analytics or just aggregating a record of them, patterns emerge that help define normal and abnormal processes. This can help to improve the  business activity monitoring, which can be used to guarantee compliance with laws and regulations.  In general, event processing can also perform automated error checking based on patterns on complex events and interactions to find errors in billing, record keeping, invoicing, and so on. 

By 2020, it’s projected that chronic diseases will account for almost 75% of all deaths worldwide.
“The Global Burden of Chronic”
-World Health Organization

Specifically for healthcare, it can be used to detect dangerous medication interactions, adherence issues, the need for dosage adjustments, a missed or incorrect medical diagnosis, or oncoming acute medical situations (in real-time) for monitored patients—all before a human might be able to.

CEP Remote Patient Monitoring Deep Dive

Historically, patients with chronic disease such as heart ailments, diabetes, or other illness, may have been required to make frequent trips to their doctor or possibly be hospitalized. This type of care can be inconvenient and expensive. Today, there are chronically ill patients that receive ongoing home-based or other remote healthcare services from a doctor, hospital or other care provider. This form of care involves health-monitoring devices that individually deliver data remotely to the care provider’s information technology (IT) back-end. Periodic review of this data either by healthcare personnel or back-end batch analytics can lead to improved, personalized care, or alert of an acute condition (i.e. pending heart failure).

However, much of this current process leaves the patient at risk if a condition becomes critical before batch analytics are performed, or manual care provider review is completed. Additionally, the raw device data received is absent any anecdotal data gathered about the patient’s well being, such as an answer to the simple question, “How do you feel today?”

Local Personalized Analytics

Incorporating CEP with medical data opens the door for analytics that can be personalized for each patient and the monitoring devices they’ve been given. A rules-based CEP algorithm can  monitor and correlate local device data in real-time to remove the risks that exist in the current batch-based or manual data processing scenario.

For example, looking at slight elevations in a patient’s blood pressure or weight, or a slight decrease in activity alone may not raise any alarms. But aggregated together, these readings may indicate oncoming or acute heart failure, or some other critical situation specific to that patient’s chronic health condition. This example of correlation-based analytics can be personalized and augmented to prompt the user for other information (i.e. the “how do you feel?” question) via a local tablet or other data-gathering device. 

As a result, the care provider will be alerted by automated event processing to potentially critical health scenarios immediately without requiring a (potentially delayed) manual review of the data. 

In short, CEP can be used to predict and administer critical care as needed before it’s too late—all based on the doctor’s prescribed care.

Patient Feedback Loops

The data correlation, personalized device data analytics, collection of patient feedback, and data safekeeping services that CEP-based data aggregation services provide offer more effective disease management scenarios. This also includes a patient feedback loop, helping to avoid false alarms (including alarm fatigue) and rewarding patients who adhere to care provider instructions, such as medication schedules. 

Sample Remote Monitoring CEP Implementation

A proof of concept was developed to illustrate the value and robustness of CEP-based analytics with data correlation services in healthcare. The following outlines the complex event processing scenario implemented, using data aggregation and analytics for remote patient monitoring and alarm fatigue avoidance. 

Important note: this example, while potentially valid for detecting heart failure, is only for illustration purposes and should not be used verbatim in place of an actual medical device or system to monitor a patient with heart disease. As always, consult a healthcare professional before implementing or using a healthcare solution such as the one in this example.

Healthcare Scenario

The goal is to remotely monitor the chronically ill patient (who in this case has chronic heart disease) for signs of acute heart failure by measuring changes in blood pressure, weight, and pulse. If the combination of these measurements, taken multiple times throughout the day, change over a multi-day period by a prescribed percentage, an automated alarm is sent to the healthcare provider. In addition to this aggregation-based event processing, the system looks for other abnormal events—such as a sudden decrease in weight indicating trouble standing without support—to also raise an alarm.

Medical Devices

The following are the medical devices used live or via simulation for the proof of concept:

Overview of Scenario Logic 

The implementation premise is based on a prescribed schedule where the remotely monitored patient is directed to take health readings four times daily. Each day, the system takes the average of the individual readings and compares them to the baseline for the patient or to the running average over time. Here is one potential algorithm:

To properly analyze the data and look for trends, we measure the cumulative change over time (over a two day period). An example of this is shown below in the Measurements section on weight. This event processing Boolean logic formula is how the potential for heart failure will be determined:

If WEIGHT increases by 3% over 2 days
If WEIGHT decreases by 10% over 2 days
 If AVERAGE BP increases by 2% over 2 days (8 readings)
 If AVERAGE WEIGHT increases 2% over 2 days (8 readings)
  If AVERAGE PULSE increases 2% over 2 days (8 readings)
Listing 1 - The algorithm for medical device data trends analysis for heart failure.

This is a complex event processing scenario because it involves multiple event streams:

The following describes how measurements are calculated:

The following measurements will be tracked per day throughout the day:

Sample Device Data Sets

Here are some sample device data sets that trigger the algorithm in Listing 1 to generate an alert event for potential heart failure:

 Inside the CEP Queries

Recall that instead of static data, event processing systems work on streams of dynamic data. A stream is formally defined as a continuous set of elements, where each element belongs to a type (or schema) and has a timestamp. The event data flows are sometimes described as channels, which are the streams that effectively handle the routing of events.

In this implementation, there are two types of streams used. First, there’s an insert stream, or ISTREAM, which adds data into the real-time stream. Next, there’s a delete stream, or DSTREAM, which removes or holds data back (delays) from the real-time stream of data. There exists a third type of stream—although this implementation doesn’t use it—called a relation stream, or RSTREAM. This stream type contains data that match a constraint based on both time and a relationship expression. Here’s a simple example, even though it’s outside the scope of this implementation:

   weight as w
   w > 400
Listing 2 - A relation stream looking for data that meets specific criteria at a point in time.

This CQL query looks for current weight readings that are over a certain value (400 pounds in this case) and generates data only when the criteria are met.

The Event Processing Network Diagram

The full event processing network (EPN) diagram—which visualizes both the data events as channels and the queries on those events—for the implementation of the remote monitoring example is shown in Figure 1.

Figure 1 - The complete EPN for the remote monitoring sample CEP implementation.

Given the size of the diagram, each step will be broken out and described below. Event processing begins on the left side where raw event data arrives from the medical devices, and then ends on the right side with either of one healthcare alert event generated (or none). Healthcare alert events will only be generated if the query processing on the arriving data indicates they should. 

Calculating a Running Average

To calculate a running average, or a moving average of values over a defined time period, the following insert stream is defined as AverageWeightQuery (see Figure 2):

    AVG(weight) AS averageWeight,
   weightInputChannel [ROWS 4 SLIDE 4]
Listing 3 - Calculating the running average weight over two days (with four readings per day).

The keyword AVG calculates the average of all streamed values (in this case, weight values). The ROWS keyword tells the query how many values to use, while the SLIDE keyword indicates how often to calculate a result. In this case, it calculates the average using the last four values, after every four values it receives. The result is a daily average value for each medical device.

Figure 2 - The running average queries and channels in the CEP sample implementation.

The output of this query, as shown in the event processing network diagram, is called the averageWeightChannel. Other queries that want to use the running average weight will accept data from this channel as input.

Next, a channel is defined (for each medical device) where data is delayed by two days so that we can compare the current day’s average value to the average from two days prior. This will be used later to determine a delta percentage. This channel is defined as a delete stream since it removes data from the otherwise continuous stream of values—in this case the averageWeightChannel we just defined. Here’s the CQL for the query, called WeightHistoryQuery:

    averageWeight AS averageWeight
    averageWeightChannel [ROWS 2]
Listing 4 – The WeightHistoryQuery filters out data less than two days old.

The output of this query is called the historicAverageWeightChannel, (see Figure 3).

Figure 3 - Data history channels are defined by delete queries that delay the values by two days.

Tracking the percentage of change of each value, such as weight, requires this channel and the previous channel (averageWeightChannel) along with some basic math. The query, named WeightDifferenceQuery in Figure 4, is shown in Listing 5 below:

   a.averageWeight AS currentAverageWeight,
   h.averageWeight AS historicAverageWeight,
   a.averageWeight - h.averageWeight AS weightDifference,
     (a.averageWeight - h.averageWeight)
         / h.averageWeight
   ) * 100 AS weightChangePercentage
    averageWeightChannel [now] AS a,      
   historicAverageWeightChannel[ROWS 1] AS h
   a.averageWeight > 0 AND h.averageWeight > 0
Listing 5 - Calculating weight change as both an absolute value and a percentage.

Starting with the FROM clause, the average and historic weight channels are selected and named ‘a’ and ‘h’ respectively. The difference between the current average and the historic average is calculated as weightDifference, and the percentage change between the two is calculated as weightChangePercentage. So long as both the average and historic input channels provide data (as checked in the WHERE clause) the output from this CQL are the two calculated delta values from the SELECT clause. These values are shown in Figure 4 as the weightDifferenceChannel, and so on.

Figure 4 - The difference queries determine the trends of medical device readings over time.

Generating Trends-based Events

At this point, with data streaming in, the averages and delta values have been prepared using event processing for trends analysis. There are two trends to watch for: a sudden change in weight (up or down), or a gradual increase of weight, pulse, and blood pressure aggregated together over two days. Either of these two trends can indicate oncoming heart failure for a patient with chronic heart disease.

The two queries (shown as WeightAlertQuery in Figure 5) for the first condition are shown here. The first checks for a sudden increase in weight—possibly indicating retention of fluid—as shown in Listing 6:

   'Weight increase of ' || weightChangePercentage || ' from ' ||
     averageWeight || ' to ' || weight  
    AS alertExplanation            
    weightDifferenceChannel [now] AS wdc
   wdc.weightChangePercentage > 3
Listing 6 - Detecting sudden weight increase by 3% or more.

The second query (Listing 7) checks for a sudden decrease in weight, which indicates the patient may be leaning on something while taking his weight due to weakness:

   'Weight decrease of ' || weightChangePercentage || ' from ' ||
     averageWeight || ' to ' || weight ||
    AS alertExplanation
    weightDifferenceChannel AS wdc
   wdc.weightChangePercentage < -10
Listing 7 - Detecting sudden weight decrease by more than 10%.

Note that both of these queries use the weightDifferenceChannel output channel from the query in Listing 5. The text generated in alertExplanation is the actual event inserted into the data stream that will be used to alert the healthcare provider of the potential for imminent heart failure.

Figure 5 - Health alert processing based on weight alone, as well as all three devices together.

The second condition (Listing 8) is more involved, but still relatively straightforward:

   'Combined Weight, blood pressure, and pulse increase alert. ' ||
    'Weight increase: ' || weightChangePercentage ||
     'Pulse increase: ' || pulseChangePercentage ||
     'BP Sys increase: ' || bloodPressureSystolicChangePercentage ||
    'BP Dia increase: ' || bloodPressureDiastolicChangePercentage ||  
    AS alertExplanation
    weightDifferenceChannel [ROWS 1] AS w,
    bloodPressureDifferenceChannel [ROWS 1] AS b,
    pulseDifferenceChannel [ROWS 1] as p
   w.weightChangePercentage > 1.25 AND
    ( (b.bloodPressureSystolicChangePercentage > 2) OR
      (b.bloodPressureDiastolicChangePercentage > 2) )
   AND p.pulseChangePercentage > 2
Listing 8 - Aggregating weight, pulse, and BP change values to generate new health alert event.

This query takes the latest changes (in percentages) for all three medical devices. If the values increase together by the prescribed amounts, the alertExplanation event is inserted into the data stream (see Figure 6). As in Listing 7 above, this event is used to alert the healthcare provider of the potential for imminent heart failure.

Figure 6 - Either healthcare alert event for heart failure is potentially inserted in the event stream.

Conclusion: Event Processing for Healthcare IoT

As this paper intends to illustrate, complex event processing systems are a strong choice when building critical patient healthcare technology systems that require failsafe operation. Engineering healthcare solutions through event processing may arguably offer a higher level of safety. This helps to both mitigate risk and increase the level of patient care, and it also allows you to easily configure and adjust deployed systems to do the following:

In short, CEP can be used to predict and administer critical care as needed before it’s too late, all based on a doctor’s prescribed care. The era of complex event processing, especially within IoT solutions, is upon us, and can be leveraged to accelerate safe innovation in many areas of healthcare technology.

Pull quote references:
-Preventing Chronic Diseases: A Vital Investment, World Health Organization,
-The Global Burden of Chronic, World Health Organization,
-Chronic Diseases and Health Promotion, World Health Organization,