STANDARDIZED DATA ACCESS FOR TELEMEDICINE

DEVICES

Mari Ibáñez, Álvaro Reina Nieves, Jaime Martínez Jiménez, Natividad Martinez Madrid

Telematic Engineer Department, Universidad Carlos III de Madrid, Leganés 28911, Madrid, Spain

Ralf Seepold

Computer Science Department, University of Applied Sciences Konstanz, Konstanz 78462, Germany

Keywords: Home healthcare, Telecare, UPnP, HL7, OSGi.

Abstract: Currently, there is a great number of telemedicine devices that can be connected to a computer in order to

collect medical data of a patient, but these devices usually use proprietary protocols with a low level of

interoperability. This paper proposes the use of a standardized protocol like UPnP to enhance the diffusion

and utilization of a telemedicine device. This work presents an UPnP wrapper that allows announcing,

discovering and managing of those telemedicine devices into an UPnP network. Additionally, the

integration of this wrapper into an OSGi service platform allows the use of a telemedicine device by other

services/applications that can need the medical data.

1 INTRODUCTION

Telemedicine is growing fast for different reasons as

the progressive increase of dependent people

(elderly or disabled people) or the need of reduce the

cost of hospitalization. The integration of key

healthcare actors is required to offer an efficient

service but these systems often lack of adequate

interoperability which slow down the acceptance

and usage of the system. Additionally, ehealth

applications and technologies are usually proprietary

and unreasonably complex for embedded systems.

For example, John is 80 years old and lives with

his son, Benn, who is 55 years old. John has been

sent to Benn's home after an operation but he has to

be visited by a doctor. As some of the visits are only

to take different measurements of his state, it has

been decided to provide some telemedicine devices

that, with the help of Benn, John has to use to take

that measurements and automatically send it using

an Internet connection. The set of devices includes a

thermometer, a blood pressure monitor and a

personal scale. Additionally, there are some devices

to create a videoconference between patient and

doctor when it is necessary. All of them use different

protocols to communicate with a computer where

has been installed different applications to manage

those devices. Benn is familiarized with computers

and Internet but the installation of new software and

devices is too complex for him.

Therefore, we have an scenario where lots of

devices and protocols, some of them proprietary,

appear, making the interconnection and

interoperability very difficult. Our approach

describes a system architecture that reduces

complexity combining a central management device

with a service platform to integrate different telecare

services. The main service of this architecture will

be an UPnP (UPnP Forum, 2010) wrapper that

provides transparent connectivity and discovery of

telemedicine devices.

According to the description of our approach, the

main device of the architecture will be the

Residential Gateway (RGW) (Hofrichter, K 2001)

that provides connectivity between Internet and the

local network and provides a place for installing the

OSGi service platform (OSGi Alliance, 2010),

which provides an execution environment as well as

a remote control architecture for services.

Figure 1 shows a scenario that presents all the

elements involved in our work and includes the

patient surrounded by multimedia devices for

videoconference and the eHealth equipment for

monitorization, and, as a central control point, the

174

Ibañez M., Reina Nieves Á., Martínez Jiménez J., Martinez Madrid N. and Seepold R..

STANDARDIZED DATA ACCESS FOR TELEMEDICINE DEVICES.

DOI: 10.5220/0003135201740179

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2011), pages 174-179

ISBN: 978-989-8425-34-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

RGW with the OSGi platform. This service platform

includes services for health data transmission,

videoconference and other not related. However, the

service that is in the target of this paper is a service

for wrapping telemedicine devices to serve them in

an UPnP network.

The wrapper consists of an OSGi service that

creates different UPnP devices for each telemedicine

device managed by the residential gateway. The

service has to announce each device and provides

the information to communicate a telemedice device

with those that requires their data. This data are

encapsulated following medical standards like HL7

(Hutchison, A. et al., 1996) and the ISO/IEEE

Health Informatics (ISO/IEEE, 2004).

In resume, we propose an architecture for a home

ehealth system based on OSGi that provides

capabilities to integrate different telecare,

telemedicine and home automation services for

dependent people in a RGW. This system provides

transparency of installation and utilization using the

widely use UPnP protocol and medical data

transmission standards.

Figure 1: Environment description.

The next sections are organized in the following

way: Section 2 presents the state of the art as well as

protocols and standards. Our proposal is presented in

Section 3 while Section 4 describes implementation

details and Section 5 shows the testbed and results

obtained. Finally, the last section concludes the

paper and gives some future outlook.

2 STATE OF THE ART

This section presents the work and research lines

related to telemedicine and similar developments

followed by a brief introduction to the technologies

and standards used in the system.

2.1 Related Work

Healthcare is a very important topic as reflects the

high number of projects that describes a

telemedicine environment and solves related

problems. A brief sample of this projects are

HEALTHMATE (HEALTHMATE, 2010), Personal

intelligent health mobile systems for Telecare and

Teleconsultation, TELECARE (TELECARE, 2010),

A multi-agent tele-supervision system for elderly

care or PIPS (

PIPS, 2010), Personalized Information

Platform for Life and Health Services. They provide

different solutions but they use to work with

compatible devices and proprietary solutions.

There are some works that attempt to provide a

non proprietary solution defining a generic

architecture to interconnect telemedicine devices.

This is the case of (TIA, 2003), (Parkka, J. et al.,

2002) and (Hui-Bing, Z. and Jing-Wei, Z. 2009). All

of them describe architectures to provide a

homogeneous management system. All work do not

present a definitive solution because they are not

oriented to telemedice devices or because they do

not define the kind of services and data that an UPnP

telemedicine specification has to provide. Apart

from those work there are other ones that present a

complete solution for the integration of different

telemedicine devices. Wen-Wei, L. and Yu-Hsiang,

S., 2008, presents a solution to manage zigbee

telemedicine devices as UPnP devices but it is

limited to the zigbee protocol and to a subset of

telemedicine devices. Toninelli, A.; et al., 2009,

presents a solution based on the MIDAS protocol

that is a non standard protocol.

To end this section and justified the use of UPnP

and OSGi to provide interoperability, as well as the

ones mentioned before, it is possible to cite Reina,

Á. et al., 2009) and (Martinez J. et al., 2007). Both

present solutions for the management of different

devices using UPnP and OSGi but in different

environments.

2.2 Technologies

The main technologies describe in this section are

related to the health informatics standards, the OSGi

framework and the UPnP standard.

2.2.1 Health Informatics Standards

Home telecare requires that patient data must be

transmitted following messaging standard.

Currently, HL7 (Hutchison, A. et al., 1996),

(Hammond, W. E., 1993) is a widely applied

STANDARDIZED DATA ACCESS FOR TELEMEDICINE DEVICES

175

protocol to exchange clinical data that provides open

source tools like (HAPI, 2010), (Mirth Corp., 2010).

Furthermore, there is a standard under

development, the ISO/IEEE 11073 (also known as

x73) standard (

ISO/IEEE, 2004), to transmit medical

information among devices, but there are hardly

eHealth devices yet in the market supporting the

standard.

2.2.2 OSGi Framework

The OSGi framework (OSGi Alliance, 2010) is a

Java-based open architecture for network delivery of

managed services. Services are added through

software components (bundles). The platform carries

out a complete management of bundles’ life cycle:

install, remove, start, stop and update.

2.2.3 UPnP Standard

The Universal Plug & Play (UPnP) (UPnP Forum,

2010) protocol is used to exchange services between

the devices attached to a local network (LAN) and a

control point (CP). An UPnP network can be

deployed over any kind of TCP/IP network,

including the most common access technologies like

WiFi or Ethernet.

Additionally to this specification, the UPnP

Forum has release a document with the definition of

a security (UPnP Security Ceremonies, 2009).

3 UPNP/HL7 WRAPPER

FOR TELEMEDICINE

DEVICES

The objective of this work is to describe a wrapper

that allows the integration of any kind of

telemedicine device into a common network to

provide interoperability. For this reason, UPnP has

been chosen because of its capabilities of

autodiscovery, autoconfiguration and adaptability as

well as being a well known standard. This protocol

is combined with HL7 to provide a medical data

structure and management. This section shows the

software architecture defined and the hardware

architecture where the software is deployed.

3.1 Type of Devices

As it is depicted in Figure 2, the working

environment is composed of four types of devices:

non-UPnP telemedicine devices connected directly

to the RGW (USB, RS-232, Bluetooth, …) or using

the Home Network, UPnP telemedicine devices,

UPnP Control Point (Mobile, Tablet PC, …) and the

RGW which acts as the coordinator device

Figure 2: System Architecture.

3.2 UPnP Wrapper and Medical Data

Management with HL7

The UPnP/HL7 wrapper is the main part of this

work. It is in charge of mapping the non-UPnP

telemedicine devices that can be accessed from the

RGW, the interaction with the modules that

communicates with the telemedicine devices,

providing an easy way of accessing data for the

internal control point and announce the telemedicine

devices in the UPnP network as well as manage

communications with devices that want to use data

of the devices supported by this system.

This medical data follow the HL7 standard in

order to be integrated and exchanged using UPnP. It

enables the communication with the largest possible

number of Electronic Health Record (EHR) servers,

making possible the use of our telemedicine

platform with many providers involved in patient

care. Our approach follows the described

De Toledo,

P. et al., 2006.

3.3 Telemedicine Device Managers

These modules are in charge of managing the

communications with the medical devices in a

middleware-compliant way (OSGi bundle in case of

the proposed architecture). They must be provided

by the device manufacturer who owns the

knowledge about how they work (data types,

acquisition methods, sampling modes, etc.).

A common interface between the telemedicine

device managers and the wrapper is needed to read

HEALTHINF 2011 - International Conference on Health Informatics

176

the device descriptive information like type of

measurements, units, bounds and sampling

frequency . Afterwards, an instance of a UPnP

device that represents such telemedicine device in

the home network can be created.

3.4 System Security

Medical data is highly sensible so that discovery of

devices and distribution of data have to be done in a

secure manner. For that, a module based on the

UPnP definitions has been defined. This module

encrypts data generated by the wrapper before

sending any device description.

4 UPNP TELEMEDICINE

DEVICE DEFINITION

The UPnP allows the definition of different devices

depending of the requirements of each situation, and

additionally, it defines some basic devices. As there

is not a standard definition for telemedicine devices,

one has been developed one for this work.

This proposal states how to describe an UPnP

telemedicine device and the services provided.

4.1 Device Model

Two types of devices are covered by this model

depending on the way of collecting data. On-demand

devices that collect data sporadically for example the

temperature or the weight of the patient, and event-

triggered devices that continuously monitor the

patient.

Table 1 shows the devices and their services.

OnDemandTelemedicineDevice:1 communicates

with the on-demand devices and has 4 services

named to start or shutdown the device, to access the

buffered data and to access the measurement units.

Table 1: Devices and services.

Device Type Service Type Service ID

OnDemandTelemed

icineDevice:1

SwitchPower:1 SwitchPower

GetMeasurement:1 GetMeasurement

GetUnit:1 GetUnit

Event-

triggeredTelemedici

neDevice:1

SwitchPower:1 SwitchPower

StartMeasurement-

Stream:1

StartMeasurementSt

ream

StopMeasurement-

Stream:1

StopMeasurementSt

ream

GetUnit:1 GetUnit

Event-triggeredTelemedicineDevice:1 service

differs with the previous one in the way of collecting

data. In this case it is needed to start and stop the

measurement stream.

4.2 SwitchPower Service Description

This service defines a basic power switching for

telemedicine devices. Table 2 shows the State

variable for this service which is in charge of storing

a value of false to request for a power-off or true to

request for a power-on state. This variable has to be

monitored to detect changes.

Table 2: State variables for SwitchPower service.

Variable Name Data Type Allowed Value Events

Status boolean true/false YES

Finally, the actions associated with this service

are listed in Table 3. These actions respectively

write and read the status state variable.

Table 3: Actions for SwitchPower service.

Name Arguments Direction

Associated

Variable

Set-Status

NewStatus-

Value

IN Status

Get-Status RetStatusValue OUT Status

4.3 GetUnit Service Description

This service defines the type of value managed by

the device. A datum is defined by a name, the

number of bytes needed to store one measurement,

and a range where this datum moves. Table 4 shows

the list of variables associated with this service

requiring name, size and minimum and maximum.

Table 4: State variables for GetUnit service.

Variable

Name

Data Type Allowed Value Events

Name string n/a NO

Size int >0 NO

MinValue float n/a NO

MaxValue float n/a NO

As the variables described above only depend on

the specific device they cannot be changed so the

allowed actions for the service GetUnit, see Table 5

are used to read the values of the state variables

Table 5: Actions for GetUnit service.

Name Arguments Direction

Associated

Variable

Get-Name RetName OUT Name

Get-Size RetSize OUT Size

Get-Min-Value RetMinValue OUT MinValue

Get-Max-Value RetMaxValue OUT MaxValue

STANDARDIZED DATA ACCESS FOR TELEMEDICINE DEVICES

177

4.4 GetMeassurement Service

Description

GetMeasurement provides data obtained by the

intervention of a patient. This data is stored in the

telemedicine management bundle till is required by a

UPnP device. The state variables for this service are

described in Table 6. The variable Values is an array

of floats that stores values while the variable Dates

stores the instant when those values were captured.

MaxElements and CurrentElements determine the

maximum and current number of values stored.

Table 6: State variables for GetMeasurement service.

Variable Name Data Type Allowed Value Events

Values set

>= MinValue,

<= MaxValue

Dates set

Dates, format:

yyyymmdd-

hh:mm:ss

CurrentElements int

>= 0,

< MaxElements

MaxElements int n/a NO

Table 7 shows the actions available for this

service. They provide a way of accessing to the

stored values getting the value (getValue) and the

associated date (getDate). These methods always

return the oldest values erasing them from the

internal buffer. GetCurrentElement provides the

number of elements in the buffer.

Table 7: Actions for GetMeasure service.

Name Arguments Direction

Associated

Variable

GetValue RetValue OUT Values

GetDate RetDate OUT Dates

GetCurrent-

Elements

RetCurrent-

Elements

OUT

Current-

Elements

GetMax-

Elements

RetMax-

Elements

OUT Max-Elements

4.5 StartMeassurement Service

and StopMeassurement

Description

These services are related with the event-triggered

devices which are constantly generating

measurements. Values are generated in the physical

device with a certain frequency and send to the

device manager with the same rate. MinRate and

MaxRate determine the limits of the Rate one. Table

8 shows detailed information of the state variables.

Table 8: State variables for StartMeassurement service.

Variable Name

Data

Type

Allowed Value Events

Values set

>= MinValue,

<= MaxValue

YES

MinRate float n/a NO

MaxRate float n/a NO

Rate float

>= MinRate,

<= MaxRate

The actions for these services are resumed in

Table 9. They allow starting and stopping the

acquisition process as well the setting of rate.

Table 9: Actions for StartMeassurement service.

Name Arguments Direction

Associated

Variable

StartCapture n/a n/a n/a

StopCapture n/a n/a n/a

GetMinRate RetMinRate OUT MinRate

GetMaxRate RetMaxRate OUT MaxRate

SetRate NewRate IN Rate

4.6 Errors Considered for all Services

Table 10 shows a compilation of all the errors that

can be returned by the system in case of failure.

Table 10: System error compilation.

Error Code Error Description Description

401 Invalid Action

See UPnP Device

Architecture section on

Control.

402 Invalid Args

403 Out of Synch

501 Action Failed

5 RESULTS

Currently, we have developed and tested a prototype

with the functionality described above. First

experiments are being implemented in a laboratory

with a simulated RGW and a blood pressure monitor

and a personal scale.

The RGW is running in an embedded computer

with limited resources using an Intel Pentium

Celeron CPU, 512 MB memory and Debian Linux.

Apache Felix (Apache Software Foundation, 2010)

an OSGi R4 Service Platform compliant

implementation released under an open source

license has been chosen as service platform.

The software made for this work includes a

Telemedicine Device Manager that communicates

with the eHealth equipment via Bluetooth and the

UPnP/HL7 Wrapper. UPnP development is based on

HEALTHINF 2011 - International Conference on Health Informatics

178

a branched version of Cybergarage (Satoshi, K.,

2010) Java libraries. HAPI, (HAPI, 2010) an open

source libraries, are used to implement the HL7 part

of the wrapper following the HL7 version 2.6

standard.

6 CONCLUSIONS AND FUTURE

WORK

An "UPnP/HL7 wrapper" for providing

interoperability in an e-health environment has been

presented and developed. Our approach is based on

well-known standards as OSGi, UPnP and HL7. It

supports discovering medical devices that use

different protocols as well as the management of the

health data provided by those devices. Additionally

the presented architecture is open to incorporate

future devices.

Future work is directed in three ways. The first

working line tries to increase the functionality of the

system incorporating home sensors. The second line

of action has relation to the usability of the

application, so it is needed to test the interface with

real patients. Finally, UPnP defines a security

protocol module that has to be implemented.

REFERENCES

Apache Software Foundation, 2010. Apache Felix.

Available: http://felix.apache.org

De Toledo, P. et al., 2006. Interoperability of a mobile

health care solution with electronic healthcare record.

In Proceedings of the 28th IEEE EMBS Annual

International Conference. New York, NY (USA), pp.

5214-5217.

Hammond, W. E., 1993. Health Level 7: A protocol for

the interchange of healthcare data. In Progress in

Standardization in Health Care Informatics, G. J. E.

D. Moor, C. McDonald, & J. N. V. Goor, eds.

Amsterdam: IOS Press.

HAPI, 2010. HL7 application programming interface.

Available: http://hl7api.sourceforge.net.

HEALTHMATE, 2010. Personal intelligent health mobile

systems for Telecare and Teleconsultation. Available:

http://www.healthmate-project.org/

Hofrichter, K 2001. The Residential Gateway as service

platform. ICCE, International Conference on

Consumer Electronics.

Hui-Bing, Z. and Jing-Wei, Z. 2009. Using 6LowPAN

UPnP and OSGi to Implement Adaptable Home

Ambient Intelligence Network Platform. In

Proceedings of the 5th international Conference on

Active Media Technology (Beijing, China, October 22

- 24, 2009). J. Liu, J. Wu, Y. Yao, and T. Nishida,

Eds. Lecture Notes In Computer Science, vol. 5820.

Springer-Verlag, Berlin, Heidelberg, 263-272

Hutchison, A. et al., 1996. Electronic data interchange for

health care. Communications Magazine, IEEE, 34, pp.

28-34.

ISO/IEEE, 2004. Health Informatics - Point-Of-Care

Medical Device Communication - Part 10101:

Nomenclature. ISO/IEEE 11073-10101:2004(E).

Martinez J. et al., 2007. OSGi Platform for UPnP AV

service delivery. Fifth Workshop on Intelligent

Solutions in Embedded Systems (WISES 07).

Mirth Corp., 2010. Mirth Connect. Available:

http://www.mirthcorp.com/products/mirth-connect.

OSGi Alliance, 2010. OSGi - The Dynamic Module

System for Java. Available: http://www.osgi.org

Parkka, J. et al., 2002. Scenarios for health management in

Future Home, [Engineering in Medicine and Biology,

2002. 24th Annual Conference and the Annual Fall

Meeting of the Biomedical Engineering Society]

EMBS/BMES Conference, 2002. Proceedings of the

Second Joint , vol.3, no., pp. 1904- 1905 vol.3, 23-26.

PIPS, 2010. Personalized Information Platform for Life

and Health Services. Available: http://www.

pips.eu.org/

Reina, Á. et al., 2009. UPnP into a car-gateway

middleware with OSGi: interoperability and security.

IEEE Seventh Workshop on Intelligent Solutions in

Embedded Systems (WISES 09)

Satoshi, K., 2010. Cybergarage UPnP framework.

Available: http://www.cybergarage.com

TELECARE, 2010. A multi-agent tele-supervision system

for elderly care. Available: http://www.uninova.

pt/~telecare/

TIA, 2003. Telemedicine Interoperability Alliance:

“Telemedicine System Interoperability Atchitecture”.

Toninelli, A.; et al., 2009. Enabling secure service

discovery in mobile healthcare enterprise networks.

IEEE Wireless Communications, vol.16, no.3, pp.24-

UPnP Forum, 2010. Universal Plug and Play standard

Available: http://www.upnp.org

UPnP Security Ceremonies, 2009. UPnP Security

Ceremonies v1.0. Available: http://upnp.org/

download/standardizeddcps/UPnPSecurityCeremonies

_1_0secure.pdf.

Wen-Wei, L. and Yu-Hsiang, S., 2008. Using OSGi UPnP

and Zigbee to Provide a Wireless Ubiquitous Home

Healthcare Environment. Mobile Ubiquitous

Computing, Systems, Services and Technologies,

2008. UBICOMM '08. The Second International

Conference on, vol., no., pp.268-273.

STANDARDIZED DATA ACCESS FOR TELEMEDICINE DEVICES

179