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 deﬁne 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) speciﬁcation 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 brieﬂy.

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

 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 speciﬁes 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 deﬁning site-speciﬁc 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 ofﬁ-

cial standard of CEN (European Committee for Stan-

dardization) and ISO standard approved. The over-

all goal is deﬁne 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

deﬁnitions harmonized between HL7 and CEN. EN

13606 is ﬂexible 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 speciﬁ-

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 ﬁrstly 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 conﬁguree-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 ﬁrst

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. Deﬁned attributes in this schema

should be compatible with HL7 PID (Patient Iden-

tiﬁer Segment) ﬁelds. 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 deﬁnes a permission set that a user have to ac-

cess to data and devices. In this manner, user type

deﬁnition is separated from privilege deﬁnition.

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 ﬂexible 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 Conﬁdence 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