Standardized Representation of Medical Data in AAL

Applications

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 ﬁeld 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]

speciﬁes a model to represent both measurements captured by devices, and narrative

information. Deﬁning templates for the HL7 Clinical Document Architecture (CDA)

[3] and proﬁles [4] for monitoring applications is a good step forward, but not sufﬁcient

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 reﬂected 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 fulﬁl 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 ﬁtness 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)

possible.

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 proﬁles 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 fulﬁl 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 deﬁnes 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 speciﬁes 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

processable.

3.2 Templates

Templates are sets of constrains on a CDA document structure and content, intended to

specialize CDA to speciﬁc use cases [8]. The Continuity of Care Document [9] (CCD)

is a CDA template that reﬂects 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 deﬁnes the docu-

ment meta-data. The body deﬁnes 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 speciﬁca-

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 speciﬁca-

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 deﬁned in the HL7

version 3 standard. All data types have a structured format. Every ﬁeld in CDA has a

deﬁned 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 ﬁeld code, codeSystem, codeSystemName,

displayName. This data type stores the semantics of the section via a code system (like

LOINC or SNOMED CT).

<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

types.

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 speciﬁed in the Uniﬁed Code for Units of Measure (UCUM).

Representation of Discrete Measurements in PHMR

<code code="271649006" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT"

displayName="Systolic blood pressure"/>

</observation>

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 deﬁned 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

(1)

Representation of Waveforms in PHMR

<code code="TIME_ABSOLUTE" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ActCode" displayName="Absolute Time"/>

</value>

</observation>

</entryRelationship>

<code code="250864000" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT"

displayName="Pulse oximetry waveform"/>

</value>

</observation>

</entryRelationship>

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 ﬁtness 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 simpliﬁed view of dynamic behaviour in tele-rehabilitation.

4.2 Human Models in AAL Applications

A model is a limited ”copy” reﬂecting aspects of the real world. Three properties denote

a model: mapping, reducing and pragmatism [12]. Models are a mapping of ”some-

Fig. 3. Simpliﬁed 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 reﬂects the analogy between a model and the domain.

Fig. 4. The SOMA diagram.

Furthermore, a subject and addressee are included, which reﬂects 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 workﬂow 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 reﬂects 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 deﬁned 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 difﬁcult 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.

References

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.