Standardized Representation of Medical Data in AAL
Myriam Lipprandt, Marco Eichelberg and Andreas Hein
OFFIS - Institute for Information Technology, Escherweg 2, 26121 Oldenburg, Germany
Abstract. The Personal Healthcare Monitoring Report (PHMR) is a document
format for representing measurements based on the HL7 Clinical Document Ar-
chitecture (CDA), and thus a suitable document type for the storage of data
from Ambient Assisted Living (AAL) applications. However, the characteristic
of medical data in AAL applications differs fundamentally from the established
view on medical data. Whereas clinical data are mostly single point measure-
ments taken under well-controlled conditions in hospital, medical data in AAL
applications are continuous, of a low sensor quality and often represent dynamic
activities of human behaviour. This leads to a different representation of data in
structured format.
1 Introduction
The many funding programs and research projects have over the last couple of years
developed a lot of new approaches in the field of Ambient Assisted Living (AAL),
which has close links to Ambient Intelligence and and Ubiquitous Computing. These
approaches mostly aim at health related use cases such as tele-rehabilitation or gait
analysis [1]. All of these applications incorporate medical and non-medical sensors
from different vendors and a processing unit like a set-top-box that communicates the
relevant health information to an external service provider such as a doctor or hospital.
The need for a standardized representation of medical information in a semantically
annotated and further machine processable format is crucial for the interoperability
of AAL systems. Therefore, the Personal Healthcare Monitoring Report (PHMR) [2]
specifies a model to represent both measurements captured by devices, and narrative
information. Defining templates for the HL7 Clinical Document Architecture (CDA)
[3] and profiles [4] for monitoring applications is a good step forward, but not sufficient
to integrate the quintessence of human behaviour in such documents. The technical
world of AAL refers to a distributed architecture with loosely coupled components,
sensors and actuators. The aim of AAL is to enable elderly or disabled people to live an
independent life in their home environment. Therefore, the data acquired by the AAL
system are of prime importance for medical care. The state of health is reflected by the
AAL application through continuous measuring, plus knowledge that is rather vague
and context dependent. This health related information gathered in home environments
differs fundamentally from medical information collected in laboratories or hospitals.
The main difference is the lack of knowledge to accurately interpret the data under
Lipprandt M., Eichelberg M. and Hein A..
Standardized Representation of Medical Data in AAL Applications.
DOI: 10.5220/0003879500720080
In Proceedings of the 2nd International Living Usability Lab Workshop on AAL Latest Solutions, Trends and Applications (AAL-2012), pages 72-80
ISBN: 978-989-8425-93-5
2012 SCITEPRESS (Science and Technology Publications, Lda.)
consideration of the situational meaning [5]. Vital parameters like blood pressure and
pulse react to external factors like weather, sport or stress. A medical decision can
only be made when the vital parameters are plausible and when the context is known.
For example, a high blood pressure is normal during a training session but requires a
treatment when it is long-lasting. Document standards must represent on one hand the
raw sesnor data, and on the other hand the semantic information of the AAL context,
which must be mapped into a machine processable format. The aim of this work is
to show that medical document standards need an adaption and extension to fulfil the
needs of medical data in AAL applications.
2 Medical Data in AAL Applications
2.1 Use Case: Tele-rehabilitation
Tele-rehabilitation applications such as the OSAmI [6] or SAPHIRE [7] systems devel-
oped for patients with cardiovascular disease take place in the home environment. To
improve the heart condition of a patient, a full stress test is carried out to identify the in-
dividual performance limits while the patient is still in stationary rehabilitation. Without
this stress test it would not be possible to create an individualized training plan. Fur-
thermore, the patient is introduced to the tele-rehabilitation system. He or she receives
introductions on how to work with the system and how to apply the vital sensors. Upon
discharge from stationary rehabilitation the patient is equipped with an ergometer bicy-
cle and a set of medical sensors like 3-lead ECG, blood pressure and pulse to monitor
the heart rate, blood oxygen saturation and blood pressure. Through a computer sys-
tem the sensor data can be analyzed during a training session to control the ergometer
load and to avoid any overload on the patient. Furthermore, an alarm system provides
feedback about the current health state while exercising. The needs of an individualized
training plan adapted over time makes a connection to the attending rehabiliation clinic
necessary. Training reports including all vital parameters and medical events like alarms
must be transmitted to the clinic after every training session. The training reports rep-
resent the patient’s health status and fitness level, based on which a medical supervisor
reviews every training report and, if needed, adapts the training plan that can be trans-
mitted to the system at the patient’s home. Due to interoperability considerations the
gathered vital parameters should be transmitted through a standardized medical docu-
ment format to make not only reading but also further processing (such as a generation
of trend curves or the combination of AAL data with data from other care processes)
2.2 Structure of Medical Data
Beside the context information, sensor quality is lower in home environments than in
medical environments. Medical staff is trained to perform medical procedures. The vital
parameters like ECG are of high quality when measured in hospital. AAL applications
incorporate vital parameters for usage at home. The users themselves have to carry out
the medical procedure with low-costs sensors. The repeated nature of measurements at
Fig. 1. Evolution of documents in AAL applications.
home to some degree compensate the lack of quality since trends can be derived. This
leads to a different interpretation of home-based information. Not a single measurement
should be interpreted medically, rather than that a trend analysis is needed. Medical in-
formation is provided by AAL applications more or less through the establishment of
behavioural profiles combined with trend information. The fact of measuring discrete or
continuous data over a longer period of time gives a different view on the representation
of medical device observations in a standardized format. Figure 1 depicts the concept of
how the evolution of single point documents leads to a representation of trends. Nowa-
days clinical documents do not take this progression of activities in AAL application
into account.
3 Clinical Documents
Structured clinical documents must fulfil the demands of the healthcare system. That is,
to exchange documents with clinical content easily and to provide a structured mark-
up for representing various kinds of information from patient demographics to sensor
data to make further processing possible. Also, the human readability is a core require-
ment. The legal aspect of storing the health relevant information over 10 or more years
requires maximum backward compatibility.
3.1 Clinical Document Architecture
The Clinical Document Architecture (CDA) is a document standard that defines a syn-
tax and semantics for clinical documents like a discharge summary or laboratory results.
The structure of CDA is not bound to any exact use case, which makes it applicable for
many use cases. Every CDA is a complete information object containing narrative text,
images and other content. CDA has a header and a body encoded in Extensible Mark-up
Language (XML). The header specifies meta-information about the intended use case,
the patient, the author of the document and the custodian. The body is composed of
structured mark-up with one or more sections. These sections contains attributes like
ID, title, text and a coded value. The body can represent information in three levels
of granularity, ranging from simple narrative text (not machine processable) to a com-
pletely structured coding in level 3, where even the narrative text is completely machine
3.2 Templates
Templates are sets of constrains on a CDA document structure and content, intended to
specialize CDA to specific use cases [8]. The Continuity of Care Document [9] (CCD)
is a CDA template that reflects the most relevant administrative, demographic, and clin-
ical information about a patient’s healthcare. It provides, for doctors and medical ap-
plications, an aggregation of all data about a patient that needs to be stored pertinent
to an episode of care or a disease. The primary use case is to provide a snapshot in
time to communicate a clinical summary of a patient. The header defines the docu-
ment meta-data. The body defines sections with semantic coding from ”Systematized
Nomenclature of Medicine - Clinical Terms” (SNOMED CT) such as past medications,
problems, and procedures.
The PHMR is a CDA template that carries personal healthcare monitoring informa-
tion. That encompasses the representation of measurements captured by devices, graphs
that show trends of the users’ health status, notes, summaries, and other kinds of narra-
tive information that can be added by caregivers. The header is based on the specifica-
tion of History and Physical Note (H&P) [10] and the body contains constrained CCD
templates. CCD is constrained by adding some section requirements, and a specifica-
tion of which sections are recommended for use with Personal Healthcare Monitoring
Reports, such as ”Results” and ”Vital Signs”.
3.3 Data Types and Codes
The data carried in a CDA document are structured by data types defined in the HL7
version 3 standard. All data types have a structured format. Every field in CDA has a
defined data type that controls the meaning of the element. Simple data contains a single
value whereas complex data types contain sub-elements, which again can contains sim-
ple or complex data types. Complex data types represent an object of associated data,
such as a person’s name or a period of time with beginning and end. The semantics for
carrying the concepts such as LOINC or SNOMED CT can be stored in the Concept
Descriptor (CD) data type that contains the field code, codeSystem, codeSystemName,
displayName. This data type stores the semantics of the section via a code system (like
<code code="8716-3" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Vital signs"/>
The intended meaning of HL7 data types gives information about their appropriate
usage. Beside the semantics all observations are structured by the situation in which
they are aquired. Context information about the setting and situational meaning are also
data, called context or meta data [11], which are currently not represented in CDA data
3.4 Information Model of PHMR
PHMR is a good step forward for a standardized representation of data gathered from
monitoring devices at home. The characteristics of observed device data can be sepa-
rated into continuous (SpO2) and discrete (Blood pressure, Temperature) vital signs and
data. Single measurements should be represented with the data type ”Physical Quantity”
(PQ), shown in the code example below. The ”value” attribute following PQ contains a
value of the type REAL that represents the magnitude of the quantity measured in terms
of the unit. The unit is specified in the Unified Code for Units of Measure (UCUM).
Representation of Discrete Measurements in PHMR
<observation classCode="OBS" moodCode="EVN">
<id root="fde90f67-529b-49e4-871b-bab296e8d499"/>
<code code="271649006" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Systolic blood pressure"/>
<statusCode code="completed"/>
<effectiveTime value="20080501104033-0500"/>
<value xsi:type="PQ" value="155" unit="mm[Hg]"/>
For continuous measurements, a sub-template named ”Waveform Observation” han-
dles the series of measurements connected with a sample period (see code example).
The sample period is represented through a generic collection that allows for multiple
repetitions of other data types. LIST contains discrete values in a defined sequence. A
GLIST is a periodic sequence of values generated from parameters and used to specify
regular sampling points for biosignals. A GLIST TS is a generated sequence of ”Point
in Time” (TS) and has a beginning (head) and an increment tag for indicating the step
size, that is, the sample period in milliseconds. The SLIST PQ represents the waveform
measurements of physical quantities (PQ). It is a sequence of sampled values scaled and
translated from a list of integer values. The SLIST items can be calculated by a formula
shown as formula 1 below: Am item at an index i is calculated by multiplying the scale
s with the digits d
and adding the origin x
= x
+ s d
Representation of Waveforms in PHMR
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="TIME_ABSOLUTE" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode" displayName="Absolute Time"/>
<value xsi:type="GLIST_TS">
<head value="20071206121000.00"/>
<!-- The sample period is 13.375 ms -->
<increment value="0.013375" unit="s"/>
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="250864000" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Pulse oximetry waveform"/>
<statusCode code="completed"/>
<value xsi:type="SLIST_PQ">
<origin value="0" unit="1"/>
<scale value="1" unit="1"/>
<digits>94 92 92 91 90 90 89 88 86 85 84 82 81</digits>
Figure 2 shows a part of the PHMR data model. The parts are the human behaviour
relevant classes. The vital signs, results, medication, exercise and activity represent the
human model of behaviour in home care circumstances and AAL applications. The
document represents the human model through data types PQ and generic collections.
To meet the needs of a time-oriented trend analysis, which focuses more on the human
behaviour than on raw sensor data, a different view and an extension of CDA and PHMR
are needed.
Fig. 2. The partial PHMR data model.
4 Extension of Clinical Documents
4.1 Training Report
All vital parameters and medical events like alarms must be transmitted to the clinic
after every training session in a training report. A training report should be represented
in a standardized format like PHMR to make a transmission and further processing
possible. The training report represents the patient’s health status and fitness level. The
development of this level is a long-term process: not every training session is of prime
importance, but an upward or downward trend is important to notice. For this reason
the PHMR can integrate a trend of the user’s health status through a graphical repre-
sentation for human reading. The disadvantage of storing continuous data in an XML
structure is the high semantic overhead, which makes the size of a PHMR document
very large. Therefore, a change in data representation should be made.
Training reports represent dynamic aspects of human activities, which can be rep-
resented as a block diagram of control systems. This leads from raw sensor data to a
model-based view of the dynamic vital processes of humans during a training session.
Figure 3 shows a simplified view of dynamic behaviour in tele-rehabilitation.
4.2 Human Models in AAL Applications
A model is a limited ”copy” reflecting aspects of the real world. Three properties denote
a model: mapping, reducing and pragmatism [12]. Models are a mapping of ”some-
Fig. 3. Simplified block diagram of an ergometer training session.
thing” representing just a a few and not all aspects of a real world, targeting a special
purpose (pragmatisms) for e.g. whom, when and why. The adapted SOMA diagram [13]
(Subject–Original–Model–Addressee) consists of a domain (Original) and a model with
a relation that reflects the analogy between a model and the domain.
Fig. 4. The SOMA diagram.
Furthermore, a subject and addressee are included, which reflects the observational
aspects and directive decisions through relations. Figure 4 shows the SOMA diagram.
Figure 5 depicts an adapted diagram showing the relations between the AAL applica-
tions and the medical document. The adaptation shows the two components of intrinsic
and external representation that represent the model of the computer-processable as-
pects (intrinsic) and the human readable content (external).
4.3 Systems in Medical Documents
Modeling aspects of physical correlations in rehabilitation training like heart rate and
ergometer load lead to a system theoretical view. This implies a distinction between
a functional, structural and hierarchical concept of systems [14]. A structural system
contains unstructured elements with relations combining these elements to a meaning-
ful entity. The functional concept represents a system as a black box. These concepts
hide the internal workflow and focuse on the behaviour of input and output. The hierar-
chical concept implies multiple steps of granularity. The important aspect of describing
rehabilitation training is modeling the changes over time, which makes it a ”dynamic
Fig. 5. Adapted SOMA diagram for the PHMR data model.
system”. Therefore, the mathematical description of the dynamic rehabilitation system
is the intrinsic representation of the model in the PHMR document, usable for further
computational processing. The rehabilitation system is a functional dynamic system
with input (ergomater load, weather. . . ), states (e. g. anaerobic threshold) and an output
(vital signs) (see Figure 6).
Fig. 6. Functional dynamic system of a rehabilitation training represented in clinical documents.
The formal model (mathematical equation) of the dynamic rehabilitation system has
to be integrated in a standardized clinical document format such as PHMR. Therefore,
the data types and coded values must be extended to a more dynamic representation
of human behaviour in AAL applications. The data types must be extended to store an
equation that reflects a dynamic system based on human parameters. This leads to a
more integrated view on human behaviour because more parameters can be integrated
without storing the whole raw data. Context information, weather, stress level and vital
parameters can be expressed through a single but complex equation.
5 Conclusions
Medical requirements in AAL application are based on valid information about the
patient’s health state. Theses states are received through vital sensor data and higher
aggregated information combining context knowledge with sensor data. For an inte-
grated health care, the use of medical document formats makes interoperability pos-
sible. CDA documents are a medical standard format with a machine-processable and
human-readable part. The data gathered in cardiac tele-rehabilitation are pulse, ECG
and SpO2 and have low sensor quality. The meaning of a medical document derived
from CDA is provided by the HL7 Version 3 data types, which are defined with regards
to their semantics independent from their operational context. An integrated view on
the human behaviour in AAL applications is not possible yet. The many use cases of
AAL are difficult to represent in CDA PHMR. An integrated process of medical re-
quirements and medical content in health related documents should be developed to
cope with challenges in AAL applications.
1. Thomas Frenken, Enno-Edzard Steen, Melina Brell, Wolfgang Nebel, and Andreas Hein.
Motion Pattern Generation and Recognition for Mobility Assessments in Domestic Envi-
ronments. In Proceedings of the 1st International Living Usability Lab Workshop on AAL
Latest Solutions, Trends and Applications. In conjunction with BIOSTEC 2011., pages 3–12.
SciTePress, 28-29 January 2011. ISBN 978-989-8425-39-3.
2. Liora Alschuler, Calvin Beebe, Keith W. Boone, and Robert H. Dolin. Implementation Guide
for CDA Release 2.0 Personal Healthcare Monitoring Report (PHMR). Technical report,
Health Level Seven, Inc., 2008.
3. Robert H. Dolin, Liora Alschuler, Sandy Boyer, Calvin Beebe, Fred M. Behlen, Paul V.
Biron, and Amnon Shabo (Shvo). HL7 Clinical Document Architecture, Release 2. J Am
Med Inform Assoc, 13(1):30–39, 2006.
4. IHE. Technical Framework Volume I Revision 5.0. Technical report Final Text.
5. Axel Helmer, Myriam Lipprandt, Thomas Frenken, Marco Eichelberg, and Andreas Hein.
3DLC: A Comprehensive Model for Personal Health Records Supporting New Types of
Medical Applications. Submitted to the Journal of Healthcare Engineering, 2011.
6. Myriam Lipprandt, Marco Eichelberg, Wolfgang Thronicke, Jan Kruger, Isabell Druke,
Detlev Willemsen, Clemens Busch, Christoph Fiehe, Elmar Zeeb, and Andreas Hein.
OSAMI-D: An open service platform for healthcare monitoring applications. In Proc. 2nd
Conference on Human System Interaction HSI ’09, pages 139–145, 2009.
7. O. Nee, A. Hein, L. Ludwig, D. Willlemsen, C. Busch, and T. Scheffold. Cardiac tele-
rehabilitation with the SAPHIRE system. In Med-e-Tel, Luxembourg, April 2008.
8. Tim Benson. Principles of Health Interoperability HL7 and SNOMED (Health Informatics).
Springer, 1 edition, December 2009.
9. HL7. Implementation Guide: CDA Release 2 Continuity of Care Document (CCD), 2007.
10. HL7. Implementation Guide for CDA Release 2: History and Physical (H&P) Notes.
11. Leland Wilkinson. The Grammar of Graphics (Statistics and Computing). Springer-Verlag
New York, Inc., Secaucus, NJ, USA, 2005.
12. Herbert Stachowiak. Allgemeine Modelltheorie. Springer, Wien [u.a.], 1973.
13. W. Steinm
uller. Informationstechnologie und Gesellschaft: Einf
uhrung in die angewandte
Informatik. Wissenschaftliche Buchgesellschaft, 1993.
14. G
unter Ropohl. Allgemeine Technologie : eine Systemtheorie der Technik. 2010.