OPEN PLATFORM FOR e-HEALTH SERVICES
Jaime Mart´ın, Ralf Seepold and Natividad Mart´ınez Madrid
Dep. de Ingenier´ıa Telem´atica, Universidad Carlos III de Madrid, Avda. de la Universidad 30, 28911 Legane´s, Madrid, Spain
Keywords:
e-Health, Telemedicine, Telecare, Domotics, OSGi, HL7.
Abstract:
This paper reviews the state of art of e-health applications and technologies. These solutions usually are pro-
prietary and lack interoperability between them. Our approach describes a system architecture that provides
capabilities to integrate different telecare, telemedicine and domotic services in a smart home gateway hard-
ware independent. We propose a rule system to define the user behaviour and monitor relevant events. Several
use cases and data model for the system are presented.
1 INTRODUCTION
The World Health Organization uses the term e-health
to explain the relations between institutions, public
health, e-learning, remote monitoring, telephone as-
sistance, domiciliary care and any other system of
remote medicine care. Telemedicine is the delivery
of healthcare services at a distance. So e-health is a
broader concept that includes a range of services that
are at the edge of medicine/healthcare and informa-
tion technology. E-health services are experiment a
great advance in the last years because ageing popu-
lation, needle to optimize the health resources and In-
formation and Communications Technologies (ICT)
enhancements.
In spite of technical improvement, health care sys-
tems often lack adequate integration among the key
actors, and also commonly fail to take certain social
aspects into account which slow down the acceptance
and usage of the system. Integrating ICT (e.g. tele-
homecare) in care, living and wellness is a citizens
demand that it should be provide at affordable cost.
To achieve communicate to dependent people (el-
derly or disabled people) with relatives and medi-
cal people in telecare services, integrating electronic
medical record transmission, is an example of integra-
tion challenge. Therefore, multimedia and communi-
cation services should be incorporated in the e-health
system. Telecom companies are spreading use of Res-
idential Gateways (RGW) to integrate different appli-
cations and a platform to manage several services re-
motely is needed. OSGi (formerly known as the Open
Services Gateway initiative) specification provides an
architecture for remote control of a platform and pro-
vides an execution environment for services support-
ing to start or stop a service, update it to change its
behavior and deploy new ones. We propose an open
system architecture based in OSGi that provide ca-
pabilities to integrate different telecare, telemedicine
and automation services in RGW.
2 STATE OF ART
Current State of Art of telecare and telemedicine is
detailed next briefly.
2.1 Related Research on Telecare and
Telemedicine
Several residential telecare and telemedicine plat-
forms approaches are founded currently in the lit-
erature. In (Bobbie et al., 2003) an electronic-
prescription system for home-based telemedicine us-
ing OSGi framework is described. This article de-
scribes a health-prescription application running on a
smart card that communicates with a Personal Dig-
ital Assistant (PDA). It uses OSGi as a cen-tral co-
ordinating point among the devices. The OSGi en-
vironment is aimed to allow intercommunication be-
tween the card reader, the patient’s PDA application
and other devices but there’s no detailed description
about how the system is implemented.
Other telemedicine approach based on OSGi
framework is presented in (Chen and Huang, 2005).
The Service-Oriented Agent Architecture described
enables healthcare services providers to support tele-
cardiology services on demand. It proposes a unit
runtime of telemedicine agents to permit the services
458
Martín J., Seepold R. and Martínez Madrid N. (2009).
OPEN PLATFORM FOR e-HEALTH SERVICES.
In Proceedings of the International Conference on Health Informatics, pages 458-461
DOI: 10.5220/0001542504580461
Copyright
c
SciTePress
to be managed remotely. The system implemented
has an agent unit, which includes a vital signals acqui-
sition module, can acquire ECG (electrocardiogram)
data and forward ECG data to medical service center.
It uses Web Services to all services communicate with
one another but no mention to any Electronic Health
Record (EHR) standard is done.
2.2 e-Health Technologies
Health patient data must be transmitted and saved in
a standard known by the involved systems. An EHR
refers to an individual patient’s medical record in dig-
ital format. An EHR standards comparative study
(Blobel and Pharow, 2006) describes HL7 and EN
13606 standards.
2.2.1 HL7
Health Level Seven (HL7) (Hutchison et al., 1996) is
a widely applied protocol to exchange clinical data.
Several versions are been developed by the HL7 or-
ganization, part of American National Standard Insti-
tution (ANSI) and founded in 1987. HL7 v3 is not re-
viewed in this article because it’s a complex standard
and there isn’t an stable version (Smith and Ceusters,
2006).
The HL7 refers to seventh OSI layer (application)
although also specifies a layer 6 presentation proto-
col made up of its own abstract message format and
encoding rules. Concerning the lower layers, like ses-
sion and transport services, is rather vague because
HL7 authors intention was to support a wide variety
of systems. The underlying HL7 operational model
is that of a client-server system. HL7 distinguishes
between two messages exchange scenarios: trigger
events/unsolicited messages and queries. The com-
munication paradigm in HL7 is the trigger event. For
example, when a patient is admitted to a hospital, the
admission system will propagate HL7 admission mes-
sages to the appropriate subsystems to inform them of
the new patient’s data. An HL7 message always con-
tains all the information required to complete a trans-
action and is encoded in HL7 own rules. The standard
allows defining site-specific extensions segments, like
message extensions to exchange data with an appoint-
ment system. However, the use of these extensions
can prompt serious interoperability problems.
2.2.2 EN 13606
Health informatics - Electronic Health Record Com-
munication standard (EN 13606) is a European offi-
cial standard of CEN (European Committee for Stan-
dardization) and ISO standard approved. The over-
all goal is define rigorous and stable information ar-
chitecture for communicating part or all of the EHR
of a patient. It’s based on the HL7 RIM (Reference
Information Model) from HL7 v3, a set of datatype
definitions harmonized between HL7 and CEN. EN
13606 is flexible to represent the information struc-
tures transmitted thanks to the archetypes, a knowl-
edge representation of the clinic information domain.
Moreover, is robust face of changes in the specifi-
cations because the archetypes changes don’t require
implementing new underlying systems.
The openEHR framework (www.openehr.org) is
consistent with the EN 13606 and it’s beginning to be
utilized in commercial systems throughout the world.
2.2.3 ISO/IEEE 11073
A brief description of novel standards for personal
tele-health systems interoperability can be placed in
(Schmitt et al., 2007). The standards goal, often also
referred to as Medical Information Bus (MIB), or x73
standards, is to enable medical devices to intercon-
nect and interoperate with other medical devices. The
standards cover the upper OSI layers and use well-
known IEEE standards like Bluetooth (802.15.1) or
WLAN (802.11) in lower layers. Part of x73 stan-
dards focus on point-of-care medical devices commu-
nication are mainly designed for acute monitoring and
treatment application in the hospital domain like In-
tensive Care Unit. Several x73 standard series are cur-
rently draft versions or further research projects and
they have not been adopted by the industry yet.
3 e-HEALTH SERVICE
INTEGRATED OPEN
PLATFORM
Our proposal design attempts to integrate several
smart home services to providea scalable and interop-
erability e-health solution. We describe the platform
below.
3.1 Overview
The system is divided in three basic subsystems: do-
motic, multimedia and e-health subsystem. In the
home can exits different devices from each subsys-
tem connected by wire or wireless to a RGW with an
embedded OSGi framework. Blood-pressure monitor
and personal scale are examples of integrated devices
in the medical network.
The automation platform Lonworks
(http://en.wikipedia.org/wiki/LonWorks) is choosed
OPEN PLATFORM FOR e-HEALTH SERVICES
459
Figure 1: Smart Home overview, with domotic, multimedia
and medical devices.
because provides a reliable and open protocol ac-
cepted as a standard for control networking in many
countries. A typical Lonworks network includes sen-
sors and actuators, for example light sensors or blind
motor. As we’ll see in Data Model section, RGW
monitorizes environment variables from automation
home network so when an important event occurs in
the home and sensors detect it, an alert or alarm rises
in the RGW. This event can be sent to relatives or
medical people. The multimedia network typically
includes a television, an IP camera or a webcam with
microphone, necessary for the dependent person to
communicate with relatives and carers. The RGW is
able to physically interconnect all networks and de-
vices, and to host the different services which can be
managed remotely by the e-health or access provider.
Multimedia services, like SIP audio/videoconference
is provided to communicate dependent person with
doctor/assistant during the medical televisit besides
his relatives and friends.
3.2 Production System
A rule-based system to control and monitorize the
user behaviour is presented in this section. It’s
a production system formed by a facts base and
rules base. This system is implemented by Jess
(http://herzberg.ca.sandia.gov), a rule engine and
scripting environment written in Java language.
In certain cases, we need a priority range for these
rules because it’s possible that several rules happen at
the same time. Alert mechanisms in actions should
have a priority level because some situations could be
critical o very critical and need a faster response. For
example, if the patient has a lot of pain, it can notify to
the assistant firstly and then to relatives. The assistant
can then decided if an ambulance is required to attend
the patient.
3.3 Use Cases
We can identify some important use case of the plat-
form. Device management can be one.
A general administrator controls the RGW but can
appear different administrator for each subsystem like
e-health admin, which is allowedto configuree-health
devices only. A solution to separate different RGW
admin by virtualization is described in (Ib´a˜nez et al.,
2007). Every service offered by a device is part of
a scene, i.d. a set of preestablished services by the
admin. Non admin user, like relatives, friends, assis-
tant or dependent person can directly customize the
devices to adapt them according to their preferences.
For example, a relative of dependent person can set
the hours that blind is open to allow illuminate the
room during periodic blood pressure check.
Telecare with assistant people of the dependent
person can be another use case. This is often or-
ganized without considering the communication with
the relatives and friends of dependent person. Prob-
lem is that the patients usually prefer to contact first
of all their relatives and friends if they need anything.
According to several studies, dependent people are re-
luctant to use many health care services because they
do not personally know the operator or contact person
in the service centre. So an objective of this work is
to integrate these relatives and friends into the health-
care service provision, in an effort to increase the us-
ability of the system. For example, in this use case
the assistant initiates a SIP video call with the patient
and with relative and check remotely the vital statis-
tics like weight or blood pressure thanks to health care
devices at patient home. These devices are wireless
connected to RGW which recover the medical infor-
mation, process data and save it in HL7 format.
4 DATA MODEL
Data model designed is divided in user management
in one side and device management in the other
side. An overview of data model it showed in 2. A
generic User entity saves basic data, like name, sur-
name, address, etc. Defined attributes in this schema
should be compatible with HL7 PID (Patient Iden-
tifier Segment) fields. For example, Spanish sec-
ond surname must be matched in Mother’s Maiden
HEALTHINF 2009 - International Conference on Health Informatics
460
Figure 2: Platform Data Model.
Name (XPN) following the HL7 Spain recommenda-
tions (www.hl7spain.org). Relative, Assistant, Doctor
and Administrator are entities which have different at-
tributes and different roles according to permissions.
A role defines a permission set that a user have to ac-
cess to data and devices. In this manner, user type
definition is separated from privilege definition.
5 CONCLUSIONS
We have seen an overview of some e-health applica-
tions and technologies. We propose a system archi-
tecture that provide capabilities to integrate different
telecare, telemedicine and automation services in a
smart home gateway based in OSGi platform. A pro-
duction system is presented also to control and mon-
itorize patient behaviour in his home. Separation be-
tween this production system and different services
implementation in RGW allows a flexible and scal-
able functional system.
Future works should provide a basic implementa-
tion and test with some of the use case describes here.
A prototype is interesting to check in a real home with
dependent person and to observe the result to do fu-
ture enhancements in the system design.
ACKNOWLEDGEMENTS
This research is supported by the MEC I+D project
In-Care. Ref: TSI2006-13390-C02-02.
REFERENCES
Blobel, B. and Pharow, P. (2006). Ehr standards-a com-
parative study. In Bos, L., Roa, L., Yogesan, K.,
O’Connell, B., Marsh, A., and Blobel, B., editors,
Medical And Care Compunetics 3. IOS Press.
Bobbie, P. O., Ramisetty, S. H., Yussiff, A.-L., and Pu-
jari, S. (2003). Designing an embedded electronic-
prescription application for home-based telemedicine
using osgi framework. In Arabnia, H. R. and Yang,
L. T., editors, Embedded Systems and Applications,
pages 16–21. CSREA Press.
Chen, Y. and Huang, C. (2005). A service-oriented agent
architecture to support telecardiology services on de-
mand. Journal of Medical and Biological Engineer-
ing, 25(2).
Hutchison, A., Kaiserswerth, M., Moser, M., and Schade,
A. (1996). Electronic data interchange for health care.
Communications Magazine, IEEE, 34:28–34.
Ib´a˜nez, M., Mart´ınez Madrid, N., and Seepold, R. (2007).
Virtualization of residential gateways. In Seepold, R.,
Madrid, N. M., and Kucera, M., editors, Proceed-
ings of the Fifth International Workshop on Intelli-
gent Solutions in Embedded Systems (WISES07, pages
115–126, Legan´es (Spain). Universidad Carlos III de
Madrid.
Schmitt, L., Schmitt, L., Falck, T., Falck, T., Wartena, F.,
and Simons, D. (2007). Novel iso/ieee 11073 stan-
dards for personal telehealth systems interoperabil-
ity. In High Confidence Medical Devices, Software,
and Systems and Medical Device Plug-and-Play Inter-
operability, 2007. HCMDSS-MDPnP. Joint Workshop
on, pages 146–148.
Smith, B. and Ceusters, W. (2006). Hl7 rim: An inco-
herent standard. In Hasman, A., Haux, R., van der
Lei, J., and France, F. R., editors, Studies in Health
Technology and Informatics. Ubiquity: Technologies
for Better Health in Aging Societies - Proceedings of
MIE2006, volume 124, pages 133–138, Amsterdam.
IOS Press.
OPEN PLATFORM FOR e-HEALTH SERVICES
461