Towards an Integrated Approach to Monitor and Analyse Health Care

Data using Relational Databases

Philip Schmiegelt

, Jingquan Xie

, Gereon Sch

uller

and Andreas Behrend

Fraunhofer FKIE, Fraunhoferstr. 20, 53343 Wachtberg, Germany

Fraunhofer IAIS, Schloss Birlinghoven, 53754 Sankt Augustin, Germany

University of Bonn, Institute of CS, R

omerstr. 164, 53117 Bonn, Germany

Keywords:

Patient Monitoring, Phase Analysis, Declarative Programming, Domain-speciﬁc Architecture, Data Manage-

ment, Decision Support Systems.

Abstract:

In modern patient monitoring systems a tremendous amount of data is gathered, stored, and analysed to support

doctors in making important decisions in a timely manner. To this end, different types of data from different

sources have to be processed such as sensor readings of patients vitals, meta-data like the age and weight of

a patient, and historical data like performed treatments or therapies. Most of the data is low-level and has

an intrinsically temporal nature which need to be preprocessed for doctors to ﬁnd high-level information in

an efﬁcient way. In monitoring scenarios however, aside from the detection of critical situations of patients,

medics are often interested in the phases in which their patients are most probably in. In this paper, we show

how phase analysis can considerably reduce the syntactic complexity of continuous queries as provided by

the Continuous Query Language (CQL). Such phases provide an advanced and higher level of abstraction

enabling effective and intuitive formulation of queries comparing to classic CQL. This can greatly improve

the development efﬁciency and reduce the maintenance complexity of patient monitoring system.

1 INTRODUCTION

In the clinical context, especially at the intensive care

unit, various sensor data are continuously collected,

e.g. heartbeat, temperature, blood pressure, oxygen

saturation, and more. These values have to be care-

fully supervised and analysed by doctors for correct

diagnosis. They also indicate whether further exami-

nations have to be carried out to diagnose or exclude

a particular illness. On the other side, due to the

technological advances, sensor types and their data

rate and precision have greatly increased in recent

years. The amount of data a doctor has to observe

becomes overwhelming. Thus decision support sys-

tems which can effectively and efﬁciently preprocess

low-level data to provide high-level information and

even useful knowledge to doctors have been gaining

much attention.

A ﬁrst attempt to assist doctors was the MYCIN

(Shortliffe, 1976) system, developed in 1972. It was,

however, not ready to be fully integrated into daily

hospital routine. MYCIN was designed as a deci-

sion support system. It generates a list of the most

possible illnesses and proposes appropriate therapies

based on several simple (mostly yes/no) questions.

Nowadays, the (automatic) capturing of various pa-

tient data as EMRs (Electronic Medical Records) has

been widely used. The potential of applying EMRs

for automatic diagnosis and therapy support is how-

ever far from being exhausted. One important rea-

son is that the employed database systems provide

only limited analysis functionality for data streams.

In particular, SQL lacks a comprehensive support for

the temporal aspect, which is one of the most im-

portant requirements in the clinical context. For ex-

ample, the orders of certain symptoms or the occur-

rences of certain vital recordings within a given time

interval are relevant for reaching a “correct” diagno-

sis. Besides of that doctors usually want to be in-

formed about phases with temporal constraints such

as “patient has higher temperature for more than three

minutes”. Because of the streaming nature of EMR-

based systems, real-time analysis is the prerequisite

for time-critical continuous queries. In fact, queries

for (fast) changing vitals or laboratory data have to be

timely re-evaluated based on the current and the his-

torical medical records.

For practical applications like (Sch

uller et al.,

407

Schmiegelt P., Xie J., Schüller G. and Behrend A..

Towards an Integrated Approach to Monitor and Analyse Health Care Data using Relational Databases.

DOI: 10.5220/0004326204070412

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2013), pages 407-412

ISBN: 978-989-8565-37-2

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

Figure 1: From Events to Phases.

2010), a huge number of continuous queries have to

be evaluated on top of a highly dynamic data volume.

This leads to a considerable amount of changes or up-

dates to the derived information. Doctors, on the other

hand, cannot continuously observe the entire list of

dynamic query results. Instead, they are more inter-

ested in seeing the latest changes of the most rele-

vant phases the patients are currently in. To this end,

observed data and detected phases have to be clas-

siﬁed using some domain-speciﬁc labels (e.g. nor-

mal, guarded, serious, or critical). Labelled phases

provide a high-level means to support doctors to ﬁnd

the most relevant information more efﬁciently. If a

patient is in a critical phase, various vital signs like

blood pressure, heart rate, temperature and oxygena-

tion etc. may exceed pre-deﬁned threshold values at

the same time. For a doctor however, it is usually

clear from the current phase, which symptom has to

be addressed at ﬁrst by an appropriate treatment. A la-

belling of phase transitions (e.g. getting better, wors-

ening, etc.) would be helpful for characterising the

change of the patient’s condition over time. For in-

stance, doctors usually want to know whether a pa-

tient is deteriorating overtime or how fast the patient’s

vitals have deteriorated from a guarded to a critical

phase. The way from events to phases, as shown in

Fig. 1, has already been outlined in the KIDS model

as a kind of high-level information (Liu et al., 2012).

The sensor data streams on the left are analysed con-

tinuously by the phase engine. If a pre-deﬁned sig-

niﬁcant change about patients situations is detected, a

new phase will be derived and the current phase will

be terminated.

2 MOTIVATING EXAMPLE

In this section, we give an example about the determi-

nation of the risk of a cardiac arrest and the patient’s

state of Hemodynamic Instability. An indication for a

possible cardiac arrest is that the heart rate is greater

than 120 for more than one hour and in the meantime

the blood pressure is higher than 100 (Guerra et al.,

2011). This could be speciﬁed in standard SQL as

follows:

CREATE VIEW Cardiac_Arrest_Sign1 AS

SELECT patientId, heartRate,

bloodPressure, timepoint

FROM patientData pd

WHERE bloodPressure > 100

AND heartRate > 120

AND NOT EXISTS (

SELECT * FROM patientData

WHERE patientID = pd.patientID AND

bloodPressure <= 120 AND

timestamp > NOW() - 1 hour)

If the blood pressure decreases by 20% to a value be-

low 60 mmHg within a six-hour window and the heart

rate increases by more than 50%, a Hemodynamic In-

stability might be entered by a patient (Lehman et al.,

2007). We could formally deﬁne this using the fol-

lowing SQL statement:

CREATE VIEW Hemodynamic_Instability AS

SELECT patientId, heartRate,

bloodPressure, timepoint

FROM patientData pd

WHERE bloodPressure < 0.8*(

SELECT max(bloodPressure)

FROM patientData

WHERE patientId = pd.patientID

AND timestamp > NOW() - 6 hours )

AND heartRate > 1.5*(

SELECT min(heartRate)

FROM patientData

WHERE patientId = pd.patientID

AND timestamp > NOW() - 6 hours )

Due to the declarative nature of SQL, the resulting

queries remain quite simple and readable. In the

stream context, however, the risk of a cardiac arrest is

redundantly derived by the stream engine. The stream

processing system does not consider the current state

of a patient. The doctor, on the other hand, usually

wants to be alerted on the ﬁrst occurrence of this con-

dition. After that, the doctor should immediately start

with an appropriate therapy and ought to be informed

as soon as the risk for a cardiac arrest ends. The

continuous notiﬁcation of the same condition how-

ever should be avoided and the determination of the

patient’s phase (no notiﬁcations for the same phase)

would be much more appropriate.

Another problem arises if we want to ﬁnd out situ-

ations where an Hemodynamic Instability is immedi-

ately followed by a Cardiac Arrest. The timestamps

encoded in the timepoint attribute have to be com-

pared to determine whether the two critical situations

follow each other. The complexity of these queries

increases dramatically as soon as more temporal rela-

tionships have to be considered.

Note that there are many conditions which prob-

ably indicate a cardiac arrest. The query above just

represents a particular constellation. If there are sev-

eral database views that contribute to the detection of

a possible cardiac arrest (such as Sign2, Sign3, etc.),

HEALTHINF2013-InternationalConferenceonHealthInformatics

408

it is necessary to rank the corresponding derived in-

dications based on their priorities. This priority de-

pends on the degree of urgency with which a critical

condition has to be treated. Therefore, we propose

to employ a priority value for each phase allowing to

order phases according to their relative importance.

In addition, provenance is a key functionality in this

scenario meaning that all derivations and their inter-

connections are stored (see Section 4).

3 PHASES

The concept of phases has been formally deﬁned in

(Sch

uller et al., 2012). In this section, we will brieﬂy

recall the core ideas of phases and more details about

the formal deﬁnitions and semantics can be found

there.

3.1 Semantics

A phase is used to describe the general, abstract state

a patient has in a certain interval of time, e.g. “hav-

ing fever”. This interval does not necessarily have a

ﬁxed end, instead its end can be continuously evalu-

ated, e.g. the “fever” phase ends when a normal tem-

perature has been observed. Formally, a phase p is

deﬁned as a n-tuple p =

o,n,b,e,a

,...,a

, with

o the object to which the phase belongs

n the name of the phase

b the time of begin of the phase

e the time of end of the phase

phase-related attributes.

(1)

where b < e. The a

are attributes attached to a phase.

In case of “fever” this could be the temperature of the

patient.

With this deﬁnition, the following queries become

easily possible:

• Which phases did/does a patient have?

• Which patient was/is in a certain phase?

• At which point in time did/does a certain phase of

a patient begin or end?

3.2 Phase Properties

Transitions. One of the key functionalities is the

deﬁnition of possible transitions between two phases.

This enables the treatment of all other transitions as

“forbidden” indicating that these transitions are ab-

normal and should not happen. For example the

changing from the tachycardia phase to the bradycar-

dia phase should not be allowed. Instead, if the sensor

readings of a patient indicate that such a phase tran-

sition is occurred, an alarm should be triggered. All

observed phases and phase transitions form a phase

transition graph.

Exclusivity. Phases can be either exclusive or non-

exclusive. For example, a patient can either be in the

state “Bradycardia” or “Tachycardia”. It is not possi-

ble to have both phases at the same time. However, a

patient can have a phase “Bradycardia” along with a

phase “Fever”, as these two phases are not exclusive.

This leads to the following formal deﬁnition:

Exclusivity. Two types of phases P

are called ex-

clusive if and only if the condition

∀o :¬∃p

,∈ P

, p

∈ P

.b ≤ p

.b ∧ p

.e ≤ p

.e)∨

.b < p

.b ∧ p

.e > p

.e) (2)

holds.

Ranking of Phases. Another very important con-

cept is the possibility to rank phases, e.g. based on

their importance. If a patient is in the phase “Fever”

and “Hemodynamic Instability”, the Fever has low

importance. Of course, the assessment can change

dynamically. One of the attributes assigned to each

phase can be used to store a numerical value, repre-

senting its importance. It is important to note that the

importance of a phase cannot be evaluated itself, in-

stead all other currently active phases have to be taken

into account. If, for example, Fever and Tachycardia

are observed at the same time, the Tachycardia might

have a higher importance. If, however, signs of a virus

infection arise, the importance of the Fever might rise

above the importance of the Tachycardia. The assess-

ment of a state also depends on other phase attributes

. A Fever phase with a temperature of 38 degrees Cel-

sius is of little importance, whereas a temperature of

42.3 degrees Celsius indicates a very critical situation

resulting an higher importance.

Non-events. Another problem difﬁcult to express

with standard SQL is the non-occurrence of events

within a given time interval. Consider e.g. the appli-

cation of an antipyretic drug, where the temperature

is expected to decline over a certain period of time.

If the desired effect does not occur (non-event), then

appropriate measures have to be taken. An automatic

mechanism to support the detection is especially use-

ful in the clinical context, where doctors work in shifts

and the reaction to a medication needs not be visible

during a single shift.

TowardsanIntegratedApproachtoMonitorandAnalyseHealthCareDatausingRelationalDatabases

409

3.3 Functions on Phases

At this point, it is useful to deﬁne some functions

on phases. They will serve for a later discussion on

querying phases.

isInPhase. This boolean function returns true if and

only if the object o is within a phase named n at a

certain point in time t:

isInPhase(o,n,t) =











true, if ∃p ∈ P :

p.b ≤ t ≤ p.e∧

p.o = o ∧ p.n = n

false, else

(3)

Duration. The duration of a phase p is given by

duration(p) = p.e − p.b (4)

A temporal order for exclusive phases p

and p

on the same object o can be deﬁned by:

≤

⇔ p

.b ≤ p

.b (⇔

def 3.2

.e ≤ p

.e) (5)

Sequence. This boolean function returns true if and

only if two phases were active on an object in tempo-

ral sequence:

sequence(o, p

, p

,..., p

) =











true, if p

≤

... ≤

false, else

(6)

The strict sequence can be used to ensures that no

third (or more) phase was active between two phases:

strictSequence(o, p

, p

,..., p

) =











true, if p

≤

... ≤

∧@p

/∈ {p

, p

i+1

},i ∈ N : 1 ≤ i < n :

≤

i+1

false, else

(7)

Of special interest are methods which allow for

an advanced pattern matching, possibly on unlimited

regular expressions. A detailed discussion is, how-

ever, out of the scope of this paper. The interested

readers can ﬁnd deeper insight in (Cadonna et al.,

2011). The functions deﬁned there can be applied

analogously for the handling of phases.

Previous/Next. Both functions return the previous

and the next phases that are recorded in the history

for a given object at a certain point in time:

prev(o,t) = max({P|p.e < t ∧ p.o = o}) (8)

with the max function and the temporal order deﬁned

in (5). Obviously previous and next can only be used

on exclusive functions. The next function can be de-

ﬁned analogously:

next(o,t) = min({P|p.b > t ∧ p.o = o}) (9)

4 ADVANTAGES OF PHASES

Provenance. In all places where difﬁcult, possibly

life-threatening decisions have to be made, prove-

nance is of a high importance. The concept of phases

can help to identify the chain of causes and effects

which lead to a phase transition. Simply storing all

sensor readings, medications, or meta-data is not suf-

ﬁcient. Due to the vast amount of data, accumulat-

ing even over a short period of time, a comprehensive

analysis becomes not feasible. Instead, by the appli-

cation of phases the amount of data to search and to

interpret can be dramatically reduced. Therefore the

higher-level analysis becomes more applicable and

scalable. This is where common Complex Event Pro-

cessing (CEP) (Luckham, 2002) solutions fall short.

They are designed to have a very high throughput, but

in the clinical context the delay of writing data persis-

tently to disks is too high. On the other hand, storing

all sensor readings, as favoured by systems based on

relational database, is also not a good solution: as a

single sensor reading is not interesting any more after

a few minutes. This is where our concept of phases

can be used: ﬁltering the whole data stream, discard-

ing the low-level sensor readings while keeping the

relevant “phases” and their transitions persistent.

Consider the example of a patient suffering from

a hemodynamic instability as a consequence of stent-

ing. Looking at the raw sensor data will not give any

clues why the stenting was done. However, if a phase

of “artery stenosis” is stored, provenances can be eas-

ily established on based on this high level informa-

tion.

Historic patient data and their relationships or

causality can be analysed in an easier way. Some ill-

nesses, such as various kinds of ﬂu encountered in the

past years, are unpredictable and usually only occur

within a short period of time. When a new mutation of

the virus arises, the symptoms might be wrongly in-

terpreted due to the lack of knowledge about the new

mutation. As this knowledge evolves over time, it be-

comes interesting to re-read the data with a “what-if”

analysis, e.g. what would have changed if we had

known the virus before the ﬁrst outbreak.

Prediction. It is of great value to have a better

overview about the current situations of a patient. A

HEALTHINF2013-InternationalConferenceonHealthInformatics

410

prediction about the future trends about a patient’s

phase is in many cases more interesting for doctors.

Phases especially phase transition graphs provide a

foundation for a high-level prediction. While it is dif-

ﬁcult, if not impossible, to forecast sensor readings,

the prediction (with certain probability) of the next

phase is possible. This can be achieved based on the

analysis of the phase transition graph. In most cases,

it is even sufﬁcient to predict a general trend as a fore-

cast, e.g. will the fever become lower or higher in the

next hours, or will the heart rate continue to decrease

or stay at a low level.

Focusing on Important Values. For applications

where software products are used as decision support

systems, the effective displaying of the most promi-

nent parameters plays a central role. At the layer of

Graphical User Interface (GUI), information which

should appear on the screen is ultimately decided.

This is sometimes not a good choice. Visual appear-

ances are mostly hard-coded within the application

and are not ﬂexible enough to be adjusted directly

by the user at runtime. Having the abstract concept

of phases available solves this problem. For exam-

ple, when a doctor is called to come to a patient’s

bed, phases with the highest importance are shown

at ﬁrst. The attributes belonging to those phases have

to be displayed, while all others, even if they might

be abnormal, can be ignored at ﬁrst. For example,

in the case of a Hemodynamic Instability, these at-

tributes are heart rate and blood pressure. All other

sensor readings, like oxygenation, can also be viewed

on request, but the most important values have to be

highlighted automatically. Transferring this knowl-

edge from the GUI to the underlying system is a great

advantage, since it can be adapted in a more intuitive

and less error-prone way.

5 MOTIVATING EXAMPLE

REVISITED

After having outlined the deﬁnitions and advantages

of phases in the clinical context, we come back to the

example given in the beginning of this paper. The

solution is provided by using phases instead of the

classical SQL.

A sample phase tuple is depicted in Figure 2. s

is the id of the given phase. It must be unique. p ID

is the id of a patient which is denoted as an object in

the phase deﬁnition. A list of attributes attr1 to at-

trN is modelled as payloads providing extra context

information for the given phase. The attributes start

Figure 2: The tuple structure of a typical phase.

and end are timestamps denoting the temporal con-

straints. The start timestamp must always be given

while the end is optional, i.e. the end timestamp can

be “undeﬁned”. It is only deﬁned when a new phase

to the same object has been detected.

The detection of the “hemodynamic instability”

which might be followed by a cardiac arrest can be

rewritten now as:

SELECT patientId,

FROM patientData

WHERE sequence(

HeartPhase.name = ’hemodynamic instability’,

HeartPhase.name = ’cardiac arrest sign 1’)

It is clear that in the sample code above, no times-

tamps are given explicitly. The temporal relationships

which are important for clinical context are embedded

within the phase deﬁnition itself.

The next sample code shows alarms for patients

whose condition gets worse over time. It is assumed

that the importance is a comparable value with partial

or full ordering, e.g. a natural number. To ensure

that only patients in a certain state are returned, the

isInPhase-function is used.

SELECT patientID, ’deteriorating’ AS

FROM patientData

WHERE

isInPhase(patientID, PatPhase2, NOW)

AND strictSequence(PatPhase1,PatiPhase2)

AND PatPhase1.importance <

PatPhase2.importance

As shown above, after the application of phases

the complexity of queries can be reduced quite a

few. For a realistic application with hundreds of or

thousands of queries, the correctness, robustness and

maintainability of the whole system can be greatly

improved.

6 RELATED WORK

There are some extensions of SQL which provide the

syntactic extensions to handle events. One of them is

SARI-SQL (Rozsnyai et al., 2009), which introduces

events with a time interval, where start and end times-

tamps can be queried separately. TSQL2 (Snodgrass,

1995) introduces the concept of states, it does how-

ever, differ from the approach proposed in this paper:

in TSQL2 neither identiﬁers for states are provided

nor methods on the transitions between states are in-

troduced. As phases are started and ended by events,

TowardsanIntegratedApproachtoMonitorandAnalyseHealthCareDatausingRelationalDatabases

411

they are comparable to regular expressions on these

events. Pattern-based event matching has been dis-

cussed in (Cadonna et al., 2011). Likewise, modern

stream processing engines are able to handle a large

number of events. However, these events usually only

have a small duration (Abadi et al., 2003; Chen et al.,

2000) or a ﬁxed time interval (Kr

amer and Seeger,

2004). In contrast, phases are typically long lasting

and the end point of a phase maybe undeﬁned until

other phases become active.

Phases play a prominent role in modern health

care monitoring system (Gawlick et al., 2011). The

assessment of phases and phase transitions are of high

importance for doctors. While in the clinical context

this kind of abstract high-level information is usually

described by the word “state” or “status”, we choose

to use the term “phase” instead. The reason is that

the term state is extensively used in computer sci-

ence, having various deﬁned semantics in different

contexts. To avoid any confusion, a overloaded us-

age should be avoided. Furthermore, the concept of

phases have been used, e.g. in airspace monitoring

(Sch

uller et al., 2010) and has also been discussed in

(Sch

uller et al., 2012) in more details.

Phases can be interpreted as certain event pat-

terns with extended time interval speciﬁcations. The

matching of such pattern without time interval has

been already discussed in some literatures (Cadonna

et al., 2011). Algorithms for efﬁciently detecting dif-

ferent event patterns could also be used for phase de-

tection. For CEP engines, events usually have only

a single time stamp without a duration (Abadi et al.,

2003; Chen et al., 2000). There are however ap-

proaches where each event has a ﬁxed interval in

which it is considered to be valid (Kr

amer and Seeger,

2004). In contrast to phases this kind of interval has

to be determined at detection time of the respective

event.

7 CONCLUSIONS

In this paper we introduced the concept of phases in

the medical context. The application of the phase

concept has numerous advantages over the plain SQL

statements. It still has to be fully investigated, imple-

mented and evaluated to unleash its full potential. A

comprehensive discussion on the syntax and seman-

tics of phases still needs to be done. The underly-

ing phase processing engine is to be developed using

for example database stored procedures or other high-

level programming languages. The concept of phases

is motivated within the medical domain but it can also

be useful for other monitoring scenarios.

REFERENCES

Abadi, D. J., Carney, D., C¸ etintemel, U., Cherniack, M.,

Convey, C., Lee, S., Stonebraker, M., Tatbul, N., and

Zdonik, S. (2003). AURORA: a new model and ar-

chitecture for data stream management. The VLDB

Journal, 12(2):120–139.

Cadonna, B., Gamper, J., and B

ohlen, M. H. (2011). Se-

quenced Event Set Pattern Matching. pages 33–44,

New York, NY, USA. ACM.

Chen, J., DeWitt, D. J., Tian, F., and Wang, Y. (2000). Nia-

garaCQ: A Scalable Continuous Query System for In-

ternet Databases. In SIGMOD, pages 379–390, New

York, NY, USA. ACM.

Gawlick, D., Ghoneimy, A., and Liu, Z. H. (2011). How to

build a modern patient care application. In HEALTH-

INF, pages 427–432.

Guerra, D., Gawlick, U., Bizarro, P., and Gawlick, D.

(2011). An Integrated Data Management Approach to

Manage Health Care Data. In BTW, pages 596–605.

amer, J. and Seeger, B. (2004). PIPES - A Public In-

frastructure for Processing and Exploring Streams. In

SIGMOD, pages 925–926.

Lehman, L., Kyaw, T., Clifford, G., and Mark, R. (2007).

A Temporal Search Engine for a Massive Multi-

Parameter Clinical Information Database. In Comput-

ers in Cardiology, 2007, pages 637 –640.

Liu, Z. H., Behrend, A., Chan, E., Gawlick, D., and

Ghoneimy, A. (2012). Kids - a model for developing

evolutionary database applications. In DATA, pages

129–134.

Luckham, D. (2002). The Power of Events: An Introduc-

tion to Complex Event Processing in Distributed En-

terprise Systems. Addison-Wesley, 1st edition.

Rozsnyai, S., Schiefer, J., and Roth, H. (2009). SARI-SQL:

Event Query Language for Event Analysis. In CEC,

pages 24–32.

Sch

uller, G., Behrend, A., and Manthey, R. (2010). AIMS:

An SQL-based System for Airspace Monitoring. In

IWGS, pages 31–38, New York, NY, USA. ACM.

Sch

uller, G., Schmiegelt, P., and Behrend, A. (2012). Sup-

porting Phase Management in Stream Applications. In

ADBIS, pages 332–345.

Shortliffe, E. H. (1976). Computer-Based Medical Con-

sultations: MYCIN. Annals of Internal Medicine,

85(6):831–831.

Snodgrass, R. T., editor (1995). The TSQL2 Temporal

Query Language. Kluwer.

HEALTHINF2013-InternationalConferenceonHealthInformatics

412