INTEGRATION SOLUTION FOR THE ACCESS TO

HETEROGENEOUS MEDICAL DEVICES

Communication with Healthcare Devices in Intensive Care Units

Susana Martin-Toral, Jose Luis Rodriguez-Gonzalez

Computer and Information Technologies Division. CARTIF Foundation

(Centre for Automation, Robotics and Information and Manufacturing Technology)

Ave. Francisco Valles 204-205, Parque Tecnologico de Boecillo, Valladolid, Spain

Javier Perez-Turiel

Head of Biomedical Engineering Division, CARTIF Foundation

Keywords:

Medical devices, drivers, VITAL (Vital Signs Information Representation), manager/agent architecture, MDIB

(Medical Data Information Base).

Abstract:

This paper presents a free Critical Care Information System (CCIS) that shows an essential infrastructure for

critical care medical and nursing practice. Speciﬁcally, a Patient Integral Analysis Aid System (SAIP) in Inten-

sive Care Units (ICU) has been developed to cover the needs discovered in these scenarios. An importart part

of this system is related to medical equipment, that offers important information to help in medical diagnosis.

ICU patients are usually connected to several of these devices which register their physiological parameters.

The integration of these devices, in order to exchange the generated information, is difﬁcult because they are

developed by different manufacturers and with different communication protocols and information represen-

tations. Due to this, it has been necessary to develop a set of communication drivers for each medical device,

according to the current regulations. To reach this objective, the developed drivers have a common interface

for the access and collection of medical device data. The main goal of the present paper is to show the work

done to obtain a real interoperability among medical devices from different manufacturers and with different

communication protocols in ICU services for automatic data collection, storage and retrieval.

1 INTRODUCTION

In this paper a free Critical Care Information Sys-

tem (CCIS) is presented. CCIS is an essential infras-

tructure for critical care medical and nursing practice.

This premise is described in terms of the critical care

environment, clinical decision making in critical care,

increasing demands for information about quality and

costs, and national initiatives for the sharing of health-

care information. This kind of systems are designed

to collect, store, organize, retrieve, and manipulate all

the data related to the care of the patient in Intensive

Care Units (ICU). Some of the main purposes of these

systems are: automated vital signs capture, cardiac

rhythm analysis and dysrhythmia detection, reporting

laboratoryresults, entry and transmission of physician

orders, admission, discharge and transfer of patients,

calculation of medication doses, ﬂuid infusion rates,

shift, and daily intake and output volumes, organiza-

tion of patient records, calculation of patient plan of

care, entry and organization of care documentation

and prompting the caregiver for recorded documen-

tation (Adhikari and Lapinsky, 2003; Fraenkel et al.,

2003; Frize et al., 1997). In this research project a

Patient Integral Analysis Aid System (SAIP) in Inten-

sive Care Units (ICU) has been developed, which is

now being used in the ICU of the University Clinical

Hospital of Valladolid, in Spain.

The SAIP is a system based on free software GNU

GPL (General Public License) (Ope, 2007) composed

by a set of computer applications to facilitate and im-

prove the attention received by the patient in inten-

sive care units (Martin et al., 2004; Jose, 2007). It

provides a support system to collect, store and man-

age the clinical information in the ICU, with the pur-

pose of facilitating the daily medical routine and to

improve the quality of the attention provided to the

patient by overcoming the actual difﬁculties of inter-

247

Martin-Toral S., Luis Rodriguez-Gonzalez J. and Perez-Turiel J. (2008).

INTEGRATION SOLUTION FOR THE ACCESS TO HETEROGENEOUS MEDICAL DEVICES - Communication with Healthcare Devices in Intensive

Care Units.

In Proceedings of the First International Conference on Health Informatics, pages 247-253

 SciTePress

connection and storage (Shortliffe, 2001).

The ICU patient is, habitually, connected to one or

several devices - called in this paper medical devices

- that allow information on several of their physio-

logical parameters to be measured, as shown in ﬁgure

1 with a vital signs monitor. These devices generate

a great amount of information, but their capacity of

storage is limited. In addition, they are usually from

different manufacturers and models, and they are not

interconnected with the rest of the devices. That is

why the integration of the generated information is

difﬁcult. This heterogeneity of medical devices is one

of the main problems for making an integral system

for the ICU. Each device has its own communica-

tion protocol and its own connection interface, for

example, RS-232, Ethernet, MIB (Medical Informa-

tion Bus), etc. and there is no interface or protocol

that allow the uniﬁcation of communication and ac-

cess between different devices and a user application

that wants to communicate with them. In order to

solve this problem, the developed system uniﬁes, for

each type of medical device, the data obtained from

the different medical devices that compose the sys-

tem, by using diverse standards of denomination and

storage.

Figure 1: Monitor connected to the ICU room PC.

The initial situation in the ICU consists of a series

of medical devices, such as infusion pumps, respira-

tory ventilators and vital signs monitors, each with

a different type of connection, a different communi-

cation protocol and without a common interface that

allows homogeneous access to the data that these de-

vices provide (Martin et al., 2004; Jose, 2007). Due

to this, it has been necessary to develop a set of com-

munication drivers for each medical device that al-

low the information provided by the medical devices

be collected and stored automatically, although these

are from different manufacturers, as well as the infor-

mation contributed by the medical staff. Because of

that, the drivers developed for the SAIP system have

a common interface for the access and collection of

data from the medical devices.

Although the main objective of the present paper

is to show the work done to obtain the homogeneous

interoperability between medical devices in the ICU,

additional objectives of the SAIP system (Jose, 2007)

are summarized as follows:

- Automation of the medical workﬂow: electronic

management of documents.

- Collection and storage of other types of manu-

ally acquired information: medical devices with-

out possibility of automatic capture of informa-

tion, connectionless devices and data from the pa-

tient exploration task ﬁlled in directly by medical

staff.

- Calculation of medical statistical indexes:

APACHE, NEMS,etc.

- Consultation of registered information. The infor-

mation stored in the system is readily accessible.

- Document elaboration of patients’ management

(registries, personal information, etc).

- The SAIP must comply with the National medical

information security laws.

- Interchange of data with other hospital services.

The intensive care unit is not an isolated service,

so it needs constant communication with other

hospital services. The efﬁcient implementation of

deﬁned interfaces should ensure communications

between the diverse systems/services of the hos-

pital.

- To manage a safe and trustworthy access to the

system. Most of the information generated in hos-

pitals is personal medical information and there-

fore is conﬁdential.

- Development under the concept of free software

(GPL license). The development of applications

based on free software is an area of activity of ever

growing interest that generates numerous expecta-

tions, given the ample possibilities it offers.

The rest of this paper is organized as follows : sec-

tion 2 describes the proposed control architecture of

the SAIP system in the ICU, paying special attention

to the part related to the integration of medical de-

vices. Section 3 describes the communication drivers

developed to allow the medical devices to commu-

nicate with the SAIP System. In addition, it de-

scribes the dynamic libraries of plugin type solution

proposed. Section 4 describes the agent entity whose

function is to communicate with the different medical

devices with its associated database. This database

stores the device data. In section 5 the results of the

system development are presented. Finally, a sum-

mary of the work done and some conclusions are in-

cluded in section 6.

2 ARCHITECTURE SOLUTION

The SAIP is a system based on the use of computer,

control and communication technologiesto generate a

set of computer applications whose main objective is

to ease and improve the attention received by patients

in intensive medical services. From a physical point

of view, the planned system requires the connection

of medical devices (vital signs monitors, ventilators,

infusion pumps, etc.) to external elements, the instal-

lation of computer systems and communication net-

works, and the development of software applications

for data recording, storage, processing and access.

The proposed system architecture is based on a

manager/agent framework, and in general it can be

seen as a three layer architecture (data, business logic

and presentation). Furthermore, the system function-

ality has been divided in two different parts: the in-

tegration environment and the execution environment

or healthcare information system (HIS) (Scherrer and

Spahni, 1999; Martin et al., 2004).

In general, the aim of the integration environ-

ment is to unify the information obtained from ev-

ery kind of system device (both medical and com-

puter). To achieve this objective, several network de-

vice manager frameworks have been used (Leinwand

and Fang, 1995), such as the ones based on the OSI

(Open System Interconnection) interconnection basic

reference model or the ones based on SNMP (Sim-

ple Network Management Protocol) (Stallings, 1999;

Case et al., 1990). On the other hand, the execution

environment, or HIS environment, is the one in charge

of implementing the business logic, so it develops

the thickness functionality provided by the SAIP. The

modules that form the HIS environment are located

throughout the diverse physical devices that house the

application, based on the information type they han-

dle. This information is provided by both the integra-

tion environment and users, or through other appli-

cations and external systems (admission information,

laboratory results, etc.). Therefore, the execution en-

vironment has the elements needed to process the in-

formation and to provide the functionality required by

users.

From this architecture, the present work empha-

sizes the part dedicated to the communication and

information processing provided by medical devices,

according to norms (CEN/CENELEC, 1993; CEN,

2000). The goal pursued in this aspect is to have a

system that allows the interaction with patient vital

support devices, so as to make the data and alarms

generated by these devices available for users (doc-

tors, nursing staff, nursing assistant, etc.). Since

these medical devices are in the patients’ emergency

rooms, the computer equipment entrusted to interact

with them must also be located in the same emer-

gency rooms. This IT equipment (pesonal computer)

is called, in our system, ICU room PC. The ICU room

PC architecture is shown in ﬁgure 2, and its main

characteristics will be detailed in the rest of the sec-

tion.

Figure 2: Block diagram of ICU Room PC.

For the ICU room PC connection architecture, the

main objective of the integration environment is to

unify, for every type of medical device and as far as

possible, the data obtained from the different devices

that compose the system. This environment, there-

fore, converts and translates the hardware dependent

information provided by medical devices into an an-

notation and nomenclature understandable by all the

devices. Moreover, it also uniﬁes the way in which

the calls are made to access information. In this way

an integrated and homogeneous medical device man-

agement is obtained.

With these objectives, the integration environment

uses some parts of the VITAL norm (Vital Signs In-

formation Representation) (CEN, 2002) to deﬁne the

semantics of the information provided by medical de-

vices as a structured set of objects and methods to rep-

resent medical information. The VITAL experimental

norm provides the deﬁnition of an independent com-

mon device representation of vital signs information,

and the deﬁnition of a common model for accessing

to this information. It means that VITAL looks for

real interoperability between medical devices even if

they are from different manufacturers (CEN, 2002).

In general, the information provided by medical

devices is transformed into VITAL nomenclature to

be stored in a database called MDIB (Medical Data

Information Base). An agent entity is responsible for

updating this database, which in addition attends to

the requests made by a manager entity, as can be seen

in detail in section 4. In short, the integration environ-

ment needs:

- A set of drivers that allow communication with

diverse medical devices. Each one is device de-

pendent, so they must speak the same language as

the device they access.

- The translation of device dependent information

into VITAL nomenclature.

- An agent entity that gathers this information peri-

odically.

- A database where information is stored.

In ﬁgure 2 the connection schema of the elements

housed in the ICU room PC is shown. Three differen-

tiated groups are distinguished in this schema. From

the lower level of abstraction to the upper, ﬁrstly the

set of drivers can be seen, then the agent entity and

its related database, and ﬁnally the business logic and

the graphic user interface housed in the ICU room PC.

Each of these groups is presented in detail in the fol-

lowing sections.

3 COMMUNICATION DRIVERS

Drivers are programs in charge of serving as middle-

wares between the computer operating system and the

different elements connected to it. In this particular

case, the system works with two different kinds of

drivers, as can be seen in ﬁgure 2. The ﬁrst one ﬁts the

deﬁnition given before, and is called “communication

driver” in the ﬁgure. This driver allows the communi-

cation with medical devices through a communication

element. Currently, the system works with a unique

communication driver, that is, a serial port hub of

Moxa trademark (Moxa’s NPort 5610 8 Port RS-232

Device Server). The reason is that almost all the med-

ical devices provide their output through an RS-232

interface, so we have chosen to work with this type

of device server, that allows a greater the number of

RS-232 interfaces than a conventional computer. Per-

haps in the future the system could need other types

of drivers for medical device communication, maybe

through Ethernet or MIB (Medical Information Bus)

interfaces.

The second driver type presented in the schema is

related to special programs developed to implement

the communication protocol of each medical device.

Therefore, there must be a driver for each type and/or

model of medical device. These drivers can be seen as

translator gateways, since they translate data requests

from the agent entity, who makes them in a homo-

geneous way, into a language understandable by the

corresponding medical device, and then they respond

in a standard VITAL format. In this way the agent

entity can talk to the different devices using the same

language, and without worrying about which device it

is talking to. The main objectives of these drivers are:

- To implement the communication through the se-

rial port (extendable to other communication in-

terfaces).

- To implement the proprietarycommunication pro-

tocol of each medical device.

- To attend to manager entity requests.

- To translate the information provided by devices

into VITAL format.

In this work, a plugin is considered a driver im-

plemented for every type or model of medical device

(the second type of driver seen before), since its com-

pilation is made as plugin libraries that can be loaded

later by an agent entity. These plugins have been de-

veloped using the same interface, so the agent can call

their functions in a homogeneous way and without

the need to know the device with which it works, or

from which manufacturer it is. In this way, the system

is totally scalable in order to increase the number of

medical devices to work with, and it ensures the com-

munication with heterogeneous devices from diverse

models and manufacturers.

When the incorporation of a new medical device

is needed in the ICU, and whenever the new device

presents some external communication port and pro-

tocol, it will be enough to implement the appropriate

driver (ﬁlling the speciﬁed interface and VITAL rep-

resentation), to generate the plugin library and to in-

form to the agent entity about the new plugin name

and location. Once the plugin is incorporated into the

system, the agent entity will be able to communicate

and extract information from this device.

4 AGENT ENTITY AND ITS

RELATED DATABASE

The agent entity is the element in charge of the com-

munication with the different medical devices (con-

nected to the ICU room PC by the serial ports hub)

through the corresponding plugins. Its main target is

to collect the information as well as the alarms pro-

vided by the different medical devices, to be mon-

itored and validated. Every agent entity communi-

cates with the medical devices assigned to a speciﬁc

patient and, with the data provided by them, must ﬁll

in the database named MDIB, and must respond the

requests from a manager entity. Therefore at this level

it is a manager/agent architecture.

The main functionalities of the agent entity are:

- To detect the connection of a new medical device

in the serial port hub assigned to one ICU room

and one patient. This detection is carried out by

the own hub, which is able to send an SNMP trap

to the ICU room PC indicating the status changes

in DCD and DSR signals in each hub’s port.

- To identify the connected medical device, that

is, to detect the type of device the agent entity

must work with to use the suitable plugin. With

this aim, the agent entity loads every plugin and

checks if it exists an appropriated communication

with the device related to the plugin. If the de-

vice responds its plugin will have been detected,

and therefore the agent entity will know the type

of device which it works with.

- The previous items provide the system with a

plug-and-play functionality related to the connec-

tion of medical devices to the system. This func-

tionality simplyﬁes the connection of these medi-

cal devices to the nursing staff.

- To collect periodically the data provided by these

devices, and update the MDIB with them.

- To detect alarm conditions in the devices using

pull or push methods, according to the behavior

of each one.

- To notify the detected alarms to the adecuated el-

ement of the systems for its processing and broad-

cast.

- To attend the requests of the manager entity, that

must ask for and provide the information from

medical devices to the business logic layer, to be

processed and showed to system users.

The MDIB, database containing the information

provided by medical devices, has an information

model according with a part of the structure and

nomenclature of the VITAL norm. This part is used

to represent the different information objects. Either

the agent entity, or other modules and elements, could

need to access to the MDIB database.

5 MAIN RESULTS

In order to understand the obtained results it has to

be considered the scenario where the project has been

developed:

- Each ICU room has a ICU room PC.

- An ICU room can have more than one patient.

- For each patient there is an agent entity and a

MDIB associated to it. Therefore in each ICU

room PC there will be so many agent entities and

MDIB as patients are in the ICU room.

- All the data gathered during a patient’s stay in the

ICU is stored in the MDIB.

- This MDIB is ﬁlled in a periodical way. In every

period the data collected by the drivers is used to

ﬁll the database.

- When a patient leaves the service, and therefore

the system, the data stored in the MDIB relatec to

that patient is erased.

Figure 3: Device identiﬁcation screen.

- The agent entity must be always active, waiting

for the connection/disconnection of a medical de-

vice, even if there is no patient in the room.

- When there is no patient in the room and a device

is connected, the agent assumes that there is a new

patient in the room.

- Whenever a device is connected, if the agent is

able to recognize it, a screen appears indicating

the device detected (type of device, manufacturer,

etc.). If the displayed data is correct, the user must

introduce the number that identiﬁes that device

univocally, as it is shown in ﬁgure 3.

- The agent monitors each device using its sam-

pling period. The data is stored periodically in

the MDIB of the ICU room PC, whereas the de-

tected alarms are sent to the appropriate process

to be handled. An example of an alarm originated

by an infusion pump is shown in the next listing

(taken from the standard output):

Hilo alarmas: Se ha detectado 1 nueva

alarma en el equipo 3

----------------------------------------

Identificador de dispositivo: 3

---> Hilo alarmas: ALARMA 0:

Equipo: Bomba

Modelo: "Plum XLD"

Descripcion: Fallo en cassette.

Tipo de alarma: tecnica

Prioridad: baja

Fecha de produccion: 22/06/2007

Hora de produccion: 08:14:32

----------------------------------------

- Once the data is stored in the MDIB, the medical

staff has the possibility of visualizing it as graphs

(trend curves) corresponding to different physio-

logical signs from the medical devices. Two ex-

amples of these trend curves can be seen in ﬁgures

4. and 5. Only the vital signs with a green spot are

showed in the graph.

Figure 4: Trend curves from patient monitor data.

- When the patient leaves the service all the medi-

cal devices must be disconnected, while the agent

entity waits for the arrival of a new patient.

During the project, the following medical devices

communication drivers have been developed, tested

and included into the system:

- Lifecare XL Infusion Pump from Abbott Labora-

tories.

- Evita Ventilator from Drager Medical.

- Vital signs monitor from Agilent Technologies.

Figure 5: Detail of trend curves.

The software developed in this project has been

implemented using the C++ language and the Troll-

tech’s QT library (Tro, 2007).

6 CONCLUSIONS

In this paper it has been presented the components

of the SAIP system developed to interact with medi-

cal devices (vital signs monitors, ventilators, infusion

pumps, etc.) in charge of the patient’s vital support in

Intensive Cares Units (ICU). The details of the com-

ponents of the ICU room PC architecture, being part

of the global SAIP system, have been shown. It has

been necessary to develop communications drivers

with a common interface to facilitate the connection

to the different devices in a uniform way, and the ac-

quisition of the data provided by the medical devices

following the indications of the medical staff respon-

sible for the ICU. These communication drivers have

been developed as plugin libraries to allow the SAIP

application to manage them through an agent entity,

while only those corresponding to medical devices

connected to the patient are loaded and used.

On the other hand, once the data of the medi-

cal constants of each device are gathered and trans-

formed into VITAL nomenclature, they are stored in

the MDIB of the corresponding ICU room PC. This

allows to visualize as graphs (trend curves) the values

stored for the different medical devices. These graphs

allow the medical staff to see the evolution of the dif-

ferent medical signs provided by the devices during a

complete cycle of 24 hours, or the ones stored for any

day of the stay of the patient in the ICU.

Considering the implementation and the be-

haviour of this part of the system, the beneﬁts and

remarkable advantages related to the handling of in-

formation provided by the medical devices are:

- Automatic and periodical collection of values of

vital signs, avoiding the manual introduction of

these values in the system.

- Automatic collection of the alarms produced by

these devices and diffusion for the knowledge of

the medical staff of the ICU service.

- Storage of all this information. Capacity to con-

sult data of different stages from the beginning of

the stay of a patient. Usually medical devices do

not have the capacity to store the information gen-

erated during all the stay of the patient in the ICU.

Some of them have buffers of storage, but they are

not big enough to store all the information relative

to the complete entrance of the patient.

- Plug-and-play functionality, that simpliﬁes the

use of the system for communicating with the

medical devices, specially for the nursing staff.

- Automatic collection of the constants indicated in

the treatment, always with the corresponding val-

idation of the nursing staff. Obtaining of nursing

reports relative to these constants.

- Taking of values for semi-automatic generation of

balances.

- Generation of trend curves.

- Compilation of the information in a unique and

standard format that facilitates its integration

and handling and provides a real interoperability

among devices.

- An application that facilitates a joint visualization

for the generation of diagnoses with all the infor-

mation of several medical devices.

As it can be seen, the main purpose of the sys-

tem is to facilitate the collection, storage and subse-

quent processing of the information provided by the

medical devices connected to patients in the intensive

care units in an homogeneous and standard way. The

automation of the collected data has been possible to

make it available to the medical staffin a friendly way,

and a real interoperability among heterogeneous me-

dial devices has been obtained.

ACKNOWLEDGEMENTS

This work has been funded by the SACYL (Sanidad

Asistencial de Castilla y Leon - Health Welfare

of Castilla y Leon), through agreement of collab-

oration between the University Clinical Hospital

(HCU) of Valladolid and the Centre for Automation,

Robotics and Information and Manufacturing Tech-

nology (CARTIF Foundation). We appreciate the col-

laboration of the intensive medicine staff of the HCU

and the CARTIF development team involved in the

project.

REFERENCES

(2007). Open soruce home page. URL:

http://www.opensource.org. Last visit: june 2007.

(2007). Trolltech home page. URL: http://trolltech.com/.

Last visit: june 2007.

Adhikari, N. and Lapinsky, S. E. (2003). Medical informat-

ics in the intensive care unit: overview of technology

assessment. Journal of Critical Care, 18(1):41–47.

Case, J., Fedor, M., Schoffstall, M., and and, J. D. (1990).

RFC 1157 - Simple Network Management Proto-

col (SNMP). Technical report, Network Working

Group. URL: http://www.faqs.org/rfcs/rfc1157.html.

Last visit: june 2007.

CEN (2000). ENV 13735:2000. Health informatics - Inter-

operability of patient connected medical devices. Eu-

ropean prestandard. English version.

CEN (2002). CEN/ISO ENV13734. Health informatics.

Vital signs information representation. European pre-

standard.

CEN/CENELEC (1993). IEC 60601-1. Medical electrical

equipment. General requierements for safety. Euro-

pean standard.

Fraenkel, D. J., Cowie, M., and Daley, P. (2003). Quality

beneﬁts of an intensive care clinical information sys-

tem. Critical Care Medicine, 31(1):120–125.

Frize, M., Trigg, H., Stevenson, M., and Solven, F. G.

(1997). Decision-support systems for critical care.

In American Medical Informatics Association Confer-

ence.

Jose, S. S. (2007). Modelado y desarrollo en software li-

bre de un sistema de analisis integral de pacientes en

unidades de cuidados intensivos. In FSWC 2007: Free

Software World Conference 3.0.

Leinwand, A. and Fang, K. (1995). Network Management,

a practical perspective. Addison Wesley, London, 2nd

edition.

Martin, S., Gutierrez, S., Jose, S. S., and Barrientos, F.

(2004). Sistema de ayuda al analisis integral de pa-

ciente en unidades de cuidados intensivos (SAIP). In

INFORMED 2004, X Congreso Nacional de Informat-

ica Medica. El tratamiento de la informacion, instru-

mento de valor aadido en la practica medica, pages

185–192. SEIS, Sociedad Espaola de Informatica de

la Salud.

Scherrer, J. R. and Spahni, S. (1999). Healthcare infor-

mation system architecture (HISA) and its middle-

ware models. In AMIA Symposium, 1999 - amia.org.

AMIA: American Medical Informatics Association.

Shortliffe, E. H. (2001). Medical Informatics. Com-

puter Applications in Health Care and Biomedicine.

Springer, New York, 2nd edition.

Stallings, W. (1999). SNMP, SNMPv2, SNMPv3, and

RMON1 and 2. Addison Wesley, London, 3th edition.