See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4352991

A Software Architecture and Data Model for Community-Based Healthcare

Environments

Conference Paper · January 2008

DOI: 10.1109/PCTHEALTH.2008.4571059 · Source: IEEE Xplore

CITATIONS READS

2 873

3 authors:

Antti Särelä Niranjan Bidargaddi

Tampere University Flinders University
28 PUBLICATIONS   650 CITATIONS    80 PUBLICATIONS   621 CITATIONS   

SEE PROFILE SEE PROFILE

Mohan Karunanithi
The Commonwealth Scientific and Industrial Research Organisation
88 PUBLICATIONS   1,637 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mobile health (mHealth) for diabetes management View project

ManUp: web- and mobile phone-based intervention to promote physical activity and healthy eating View project

All content following this page was uploaded by Mohan Karunanithi on 27 May 2014.

The user has requested enhancement of the downloaded file.

 A Software Architecture and Data Model for Community-Based
Healthcare Environments
Antti Sarela, Niranjan Bidargaddi and Mohan Karunanithi
CSIRO ICT Centre (E-Health Research Centre),
P O Box 10842, Level 20, 300 Adelaide Street, Brisbane 4000, QLD, Australia
[email protected]

Abstract— Major changes in healthcare delivery are needed the vast majority of commercial systems have proprietary
to ease the pressures caused by global increase in ageing popu- communication interfaces and data formats, which makes the
lation and prevalence of chronic diseases. Recent care initiatives integration to other information systems difficult. They also
address these problems by delivering care in community-based
settings, away from hospitals. The community care model record huge amounts of sensor data, that the care workers do
requires that a patient’s health condition is also monitored in not have the time to interpret [6]. By providing large amounts
the home environment to allow assessment and follow-up of the of data, the systems often fail to present optimized and care
health status. specific measures that would help the care workers to manage
Our work presented in this paper aims to design a system their patients efficiently. These issues can be addressed by
architecture and data model that would provide efficient means
to perform essential information management for ambulatory designing optimal health information systems.
monitoring in a home health care setting. We describe a The information systems are the main tools for collecting,
general purpose architecture and data model that is designed storing and analyzing the data and, most importantly, for pro-
for collecting ambulatory data from various existing devices viding essential information to the health care professionals.
and systems, as well as for analyzing, storing and presenting The design principles and architectures of such systems have
clinically significant information to the care personnel.
been described for example in [7] and [8]. It is important
to design standardized external interfaces to address the
I. I NTRODUCTION
communication problem. In a recent work [5], the authors
There is a global need to introduce major changes in proposed an architecture that is based on standardized HL7
healthcare delivery to ease the pressures caused by increase clinical document architecture (CDA) and Arden Syntax to
in ageing population and prevalence of chronic diseases. For develop an interoperable information system. In addition
example, Cardiovascular Disease is one of the leading health to the external interfaces, the internal data structure and
problems in Australia, USA, and other developed countries. architecture of a software system is essential to enable
It still remains the leading cause of mortality in Australia, efficient and flexible data management. Our work aims to
contributing to 18% of the total burden in disability-adjusted develop an architecture and internal data model that would
life years (DALYs) [1]. be practical to the current non-standardized environment and
Recent care initiatives address these problems by deliver- yet be flexible to accommodate any new development or
ing care in community-based settings away from hospitals, emerging standard to ensure the interoperability with other
which requires changes both in work practices and health systems.
information systems [2]. The community care model requires
that a patient’s health condition is monitored in the home en- II. M ETHODS
vironment to allow assessment and follow-up of their health This paper presents a system architecture and internal data
status. The challenge is to optimize the technologies both on model design that provide efficient means to collect, analyze,
the patient’s and the care worker’s side. The unobtrusiveness store and present ambulatory time series data from existing
of home care devices is essential, especially for the patients home monitoring devices and systems. In the first part of
suffering from chronic diseases. The care workers, on the the Section III, we describe the main characteristics of the
other hand, want to receive only the relevant information on architecture and the software structure. In the second part, we
their patients for fast and reliable assessment. present the main features of ambulatory measurement data
There are many measurement devices and systems devel- and describe our data model, that captures these features.
oped for home care and some have already been commer- In addition, we are conducting a clinical trial within a
cialized and sold in modest volumes. Despite many studies Cardiac Rehabilitation program to develop and validate data
done on telehealth applications [3] showing promising results processing algorithms for clinically significant measures and
such as decrease in readmittance [4], the uptake of telehealth to test the developed architecture and data model with real
in practical care processes has been slow. The lack of patient data. In the trial, we are using a waist mounted ambu-
interoperability is claimed to be one of the key factors latory device to collect physiological data from the patient’s
[5]. The standardization to address this is proceeding but home environment. The device measures both movement
 Fig. 1. The CAP software system architecture and external interfaces

activity and single lead ECG. The recorded data needs to from the data and return a new XML file contain-
be translated into clinically relevant measures which show ing the analysed results.
the trends of patients condition and easily understood by 3) Data Services Tier:
health care professionals. An example of the modeling and • Database Engine provides an interface between
presenting of real patient data is described at the end of the Data Parser and the relational database. It
Section III. reads and writes the internal XML files and trans-
III. R ESULTS fers the data in and out the database by using SQL
A. System Architecture commands and queries.
The architecture provides a flexible platform that can
The Care Assessment Platform (CAP) Software system
receive data from any existing ambulatory measurement
architecture follows a three-tier information system design
devices or systems, that have proprietary communication
model [8] and is presented in Figure 1. The architecture has
interfaces. A new device can be added to the system by
the following main modules:
writing a device driver module into the Input Layer that
1) Interface Services Tier:
converts the proprietary data representation to the fixed in-
• Data Input layer connects to external monitoring
ternal XML format. New data types can be added by writing
devices and software systems and converts data the required data definitions in the database. Pre- or post
from a manufacturer specific format to internally processing algorithms modules can also be flexibly included.
used general XML structure (CAP Data Protocol, The interface between the Algorithms and Data Parser is
CDP). The converted data will be stored in a always using the internal XML format. Any algorithm simply
temporary XML Repository. reads the XML file passed by the Data Parser and writes
• User Interface provides a web-browser based
the results to a new file. When the data is permanently stored
view on the measured data and other information in the database or not otherwise needed, the temporary XML
as well as a means to manage and enter new data files are deleted from the repository.
and patient information in the system. The device
specific data files can be fed through the User B. Data Model
Interface and will be passed to Data Input for The main novelty of the architecture is the internal
conversion. All the other communication between communication structure and data model, which uses an
User Interface and Data Parser is done by using optimized XML format and a XML Repository to transfer
the XML files. all the data between the main modules and database. This
2) Business Logics Tier: enables high modularity, flexibility, low coupling, and high
• Data Parser module acts as a relay station admin- cohesion in the software. The same data structure is used
istering raw and analyzed data between Data In- in all the communication between the software modules and
put, Algorithms, User Interface, and Database database to transfer measurement data and other information.
Engines. The measurement data that needs to be presented in
• Algorithms are activated by Data Parser and they XML format and stored in a database has the following
read in the XML format data, calculate measures characteristic features.
 Fig. 2. XML structure for storing the measurement and patient data

1) The data has a wide range of sampling rates, which The DataBlock carries the start time (StartTime) of the
can vary from more than 1kHz for ECG signal to continuous sequence of data samples that are stored in the
one sample a day or less (for example body mass) Data element. The numerical data is stored directly in the
depending on the measured physiological parameter. XML document if the amount of samples in one DataBlock
The analyzed data has often very low sample rates is small. If there are large number of samples, for example
because the clinically interesting feature might be the in case of raw ECG data, it is more efficient to store the
monthly or weekly average of a measured signal. samples in a binary file and reference the file in the DataFile
2) The data does not necessarily have a defined sampling element. The essential information to read the data is stored
rate such as heart rate interval, which may be coded in the BlockFrame attributes: DataType, DataFileFormat,
as beat-to-beat timing values. SamplingRate for fast signals, and SamplingPeriod for
3) The collected data is often highly discontinuous. The slow signals. The DataType attribute is used to identify the
patient might use the activity monitor continuously for data in the BlockFrame and to determine the required data
few days but have several days between the measure- operations. If the sampling rate is not defined, the Data ele-
ment sessions. ment of this data type either includes the timing information
4) The devices might produce very large amounts of raw such as beat-to-beat interval relative to the StartTime or
data or only few values occasionally. event data, which only has the absolute time stamp defined
5) The data might describe an event such as a fall. An in the StartTime. The event codes or diary entries are stored
event is defined with an event code and a timestamp in the Text element and the possible associated data in the
and can be associated with other explanatory data such Data element.
as event duration. Figure 3 illustrates how patient data is stored in the
6) A diary entry which includes textual data, a timestamp XML document. Every continuous sequence of data forms
and may also have numerical data is a special case of one DataBlock element. The StartTime and SamplingRate
an event and can be described with a similar structure. elements fully define the timing of each DataBlock.
The created XML document is a temporary data storage.
The XML format used to capture the data is presented The data is eventually written to a relational database,
in Figure 2. All the patient data is stored within a Main- which has a similar model to store all the data. The Entity
Frame structure. The MainFrame attributes always define Relationship Diagram (ERD) of the database section that
the patient id and name, which is a minimum amount of stores the data is presented in Figure 4. The structure is very
patient identification associated with the patient data in one similar to the XML format, which makes it straightforward
XML document. All the other elements in the document for the Database Engine to convert data to and from the
are optional. For example a XML document containing database. Each DataBlock in the XML document is written
only MainFrames with patient names and IDs without to a table defined in DataType. The DataBlockHeader holds
any other elements can be used to communicate the list the timing information of each data block and relates the data
of patients in the database to the User Interface. The to the information in the Patient, Signal, and optionally the
PatientFrame element in the MainFrame contains detailed Device tables.
patient demographics. The model can be expanded to include The described structure that is based on BlockFrames and
other types of information by appending elements parallel to DataBlocks can capture the characteristics of all the various
PatientFrame and BlockFrame. signal types and features that may be collected in a ambu-
The BlockFrame and DataBlock elements are the key latory setting. Because the mapping between different data
structures that hold the different types of time series and types and related algorithms is also stored in a database table,
event data described above. A BlockFrame contains always it is straightforward to append completely new physiological
at least one DataBlock and optionally a DeviceHeader. time series signals to the model.
 View publication stats

Fig. 3. Sample XML file that stores patient’s activity information and average day time energy expenditure values calculated by an energy expenditure
algorithm. The framed DataBlocks illustrate how discontinuous data is stored

user interface that will present the processed and analyzed

clinically significant information to the care workers. We
are planning to evaluate the complete prototype system in
a community-based cardiac rehabilitation setting. We will
also continue to integrate new devices and data processing
algorithms to the system.
V. ACKNOWLEDGMENT
We would like to thank the project team of North side
Primary and Community Health Services, North side Health
Service District, Queensland Health, Australia for their valu-
able contribution in conducting the clinical trial and provid-
ing the means to develop the Care Assessment Platform. We
are greatly indebted to the patients who are participating in
the study.
R EFERENCES
[1] Theo Vos and Stephen Begg, “The burden of cardiovascular disease in
australia for the year 2003”, Report prepared for the National Heart
Foundation of Australia, July 2007.
[2] Reinhold Haux, “Health information systems - past, present, future.”,
Int J Med Inform, vol. 75, no. 3-4, pp. 268–281, 2006.
[3] Guy Par, Mirou Jaana, and Claude Sicotte, “Systematic review of home
telemonitoring for chronic diseases: the evidence base.”, J Am Med
Inform Assoc, vol. 14, no. 3, pp. 269–277, 2007.
[4] P. deToledo, S. Jimeanez, F. delPozo, J. Roca, A. Alonso, and C. Her-
nandez, “Telemedicine experience for chronic care in COPD”, IEEE
Transactions on Information Technology in Biomedicine, vol. 10, no. 3,
Fig. 4. The database ERD model pp. 567–573, July 2006.
[5] Oliver-J. Bott Mirko Geisler Maik Plischke Wolfram Ludwig Andreas
Hornberger Reinhold Haux Michael Marschollek, Klaus-H. Wolf, “Sus-
tainable ubiquitous home health care architectural considerations and
IV. C ONCLUSION first practical experiences”, in MEDINFO 2007, 2007.
[6] Labb F-Gagnon MP Lamothe L, Fortin JP and Messikh D, “Impacts
We developed a novel software architecture for community of telehomecare on patients, providers, and organizations.”, Telemed J
E Health., vol. Jun, pp. 12(3):363–9, 2006.
care setting. It uses an XML-based data model and com- [7] Wolf KH Bott OJ, Marschollek M and Haux R., “Towards new
munication structure and a relational database to efficiently scopes: sensor-enhanced regional health information systems - part 1:
handle typical features of physiological measurement data architectural challenges.”, Methods Inf Med., vol. 46(4), pp. 476–83,
2007.
and analysis results. The architecture and model is flexible [8] Stephen Chu and Branko Cesnik, “A three-tier clinical information
to accommodate variety of ambulatory devices, handle data systems design model”, International Journal of Medical Informatics,
and utilize a number of data processing algorithms. vol. 57, pp. 91107, 2000.
Our future work will focus on building a web server based