Towards an Integrated Approach to Monitor and Analyse Health Care
Data using Relational Databases
Philip Schmiegelt
1
, Jingquan Xie
2
, Gereon Sch
¨
uller
1
and Andreas Behrend
3
1
Fraunhofer FKIE, Fraunhoferstr. 20, 53343 Wachtberg, Germany
2
Fraunhofer IAIS, Schloss Birlinghoven, 53754 Sankt Augustin, Germany
3
University of Bonn, Institute of CS, R
¨
omerstr. 164, 53117 Bonn, Germany
Keywords:
Patient Monitoring, Phase Analysis, Declarative Programming, Domain-specific 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 find high-level information in
an efficient 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 efficiency 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 efficiently preprocess
low-level data to provide high-level information and
even useful knowledge to doctors have been gaining
much attention.
A first 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
Copyright
c
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-
sified using some domain-specific labels (e.g. nor-
mal, guarded, serious, or critical). Labelled phases
provide a high-level means to support doctors to find
the most relevant information more efficiently. If a
patient is in a critical phase, various vital signs like
blood pressure, heart rate, temperature and oxygena-
tion etc. may exceed pre-defined 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 first 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-defined sig-
nificant 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 specified 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 define 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 first 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 notification of the same condition how-
ever should be avoided and the determination of the
patient’s phase (no notifications for the same phase)
would be much more appropriate.
Another problem arises if we want to find 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 defined in
(Sch
¨
uller et al., 2012). In this section, we will briefly
recall the core ideas of phases and more details about
the formal definitions 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
fixed 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
defined as a n-tuple p =
h
o,n,b,e,a
1
,...,a
n
i
, 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
a
i
phase-related attributes.
(1)
where b < e. The a
i
are attributes attached to a phase.
In case of “fever” this could be the temperature of the
patient.
With this definition, 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
definition 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 definition:
Exclusivity. Two types of phases P
1
,P
2
are called ex-
clusive if and only if the condition
o :¬∃p
i
, P
1
, p
j
P
2
:
(p
j
.b p
i
.b p
i
.e p
j
.e)
(p
i
.b < p
j
.b p
i
.e > p
j
.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 difficult 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 define 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
1
and p
2
on the same object o can be defined by:
p
1
t
p
2
p
1
.b p
2
.b (
def 3.2
p
1
.e p
2
.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
1
, p
2
,..., p
n
) =
true, if p
1
t
p
2
t
...
t
p
n
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
1
, p
2
,..., p
n
) =
true, if p
1
t
p
2
t
...
t
p
n
@p
j
/ {p
i
, p
i+1
},i N : 1 i < n :
p
i
t
p
j
t
p
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 find deeper insight in (Cadonna et al.,
2011). The functions defined 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 defined
in (5). Obviously previous and next can only be used
on exclusive functions. The next function can be de-
fined analogously:
next(o,t) = min({P|p.b > t p.o = o}) (9)
4 ADVANTAGES OF PHASES
Provenance. In all places where difficult, 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-
ficient. 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: filtering 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 flu 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 first 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-
ficult, 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 sufficient 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 flexible 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 first. The attributes belonging to those phases have
to be displayed, while all others, even if they might
be abnormal, can be ignored at first. 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 definitions 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
ID
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 definition. 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 “undefined”. It is only defined 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 definition 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 identifiers 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 fixed time interval (Kr
¨
amer and Seeger,
2004). In contrast, phases are typically long lasting
and the end point of a phase maybe undefined 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 defined 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 specifications. The
matching of such pattern without time interval has
been already discussed in some literatures (Cadonna
et al., 2011). Algorithms for efficiently 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 fixed 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.
Kr
¨
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