Abstract
The need for interoperability among devices is an issue of vital importance in current telemedicine systems. Although a completely standardized system is an ideal solution, most commercially available devices include their own software and communication protocols, which cause serious problems and hinder the application of a standard. Patients' telemonitoring at home requires a wide variety of biometric and ambient sensors and devices that usually present a set of very specific features and characteristics. The present article introduces a system based on the Open Services Gateway Initiative architecture, which offers plug-and-play connectivity of ambient assisted living devices. Using a data model inspired by the X73 standard, we describe a set of bundles that reduces the interoperability problem and allows the data stored in the platform to be independent from the connected devices.
Introduction
In the coming years, our health system will have to face a new situation. The increase of life expectancy is generating a progressive aging of the population, which, in turn, entails a greater number of handicapped, dependent persons and people suffering from chronic diseases. In the year 2020, it is predicted that over 32% of the population will suffer from some kind of disability, and by 2050, chronic pathologies will represent 60% of all diseases. 1 The World Health Organization has estimated that there will be 1 billion people in the world over the age of 60 years in the year 2025 and twice as many by 2050, with nearly 80% concentrated in developed countries. 2
This scenario is unsustainable for present health systems because of the lack of material and human and economic resources. The first steps are being taken by different health systems, both public and private, and they all agree that the solution to this problem lies in the use of information and communication technologies, and especially the use of telemedicine. 3 Telemonitoring of patients is a common practice in telemedicine. The inclusion of such services allows the patients to stay at home, thus avoiding the cost derived from the occupation of a hospital bed, at the same time that the patient is in a more comfortable ambience. This leads to a considerable reduction in the number of visits to the hospital and, hence, a better quality of life for the patient. 4
Home monitoring of a patient implies deploying systems and technologies based on sensor networks that must be integrated into the environment and gather all the information that may be of interest to the doctors or the patient. 5 –7 Among the different kinds of existing devices, we can find ambient sensors (humidity, luminosity, etc.), as well as personal sensors, both biometric (electrocardiogram [ECG], weight, pulse oximetry, etc.) and non-biometric (localization, activity, etc.). Obviously, all the devices are completely different from each other. Even those that provide similar measurements usually present different behaviors: every manufacturer uses its own software and communication protocols. In addition, manufacturers provide the information in their own specific format, which generates a severe interoperability problem. Such differences must disappear; the information should always be represented in the same way, regardless of the sensor being used. Moreover, the system has to permit plug-and-play connection of devices, as well as user-transparent communication.
Studies are now focusing on the development or application of standards to solve interoperability issues. One noteworthy contributor in this line is the nonprofit, open industry organization Continua Health Alliance (
This article presents a solution to unify the information gathered by the sensors, starting from the basic concept that each device has its own characteristics. A plug-and-play system is obtained, where the communication among users and devices is carried out in a totally transparent mode, regardless of the device. In addition, this system is easily implementable without losing any functionality.
The novelty of this article lies in the exploitation of the features of Open Services Gateway Initiative (OSGi) 18 (a framework for modular systems that simplifies building, deploying, and managing complex applications) to solve interoperability problems in telemedicine systems. The X73 standard data model turns out to be the perfect complement as it allows the OSGi framework to model the information extracted from the sensors. Although OSGi has previously been used to interconnect home automation devices, this article goes a step further, proposing an ambient assisted living system that goes beyond the mere communication between devices, introducing signal processing, feature extraction, and storage information under a single format.
Materials and Methods
This section aims to describe the data model used for device management (i.e., the structures needed to represent different devices), as well as the measurements they gather. The data model also includes attributes associated with these structures, their format, and the possible values they may take.
A model that is originally created for a telemedicine system includes a large number of entities that cover all the aspects of a patient and his or her medical history. This document is primarily focused on the storage structures directly related with the sensor network.
This data model is inspired in the X73 standard, 19 more specifically in the management of the parameters measured by the sensors. The standard ISO/IEEE 11073 (or X73) is the result of the joint effort of the International Organization for Standardization (ISO), IEEE, and European Committee for Standardization standardization organizations, and it has been approved internationally. Although some parts of the standard are based on some previous standards such as the medical information bus (IEEE MIB 1073), some other parts are still considered as drafts and are currently in the development phase. 20
The X73 standard is a set of connectivity norms for medical devices, going from the physical level (either wired or wireless) to the information representation. Our interest is focused on the norm 1073.1.x.x of the standard, where the data model for the representation of devices and measurements is included together with a wide nomenclature of medical terminology. 21
We have used the X73 standard as a guide to develop an adapted data model, extracting and simplifying many of the attributes that can be found in its classes. In this way, we have implemented a model that is adapted to our needs, as the strict application of the standard presents some drawbacks in home hospitalization scenarios. 22,23 That many of the devices located in such scenarios have a limited processing capability because they are based on microcontrollers and most of them have limited batteries for their wireless communications must be taken into account.
The X73 standard defines an OSI-based layer architecture. Each layer generates its own protocol data unit that encapsulates the protocol data unit of the upper immediate layer. The functionality is therefore divided into layers, with an ever-increasing complexity and execution time, which requires additional memory and higher battery consumption. This prohibits the possible use of this standard in very limited devices. Furthermore, we should remark that very few devices currently incorporate this standard by factory default. This can be attributed to the complexity of the standard, which makes it hard and expensive to implement. Besides, and because of the fact that X73 deals only with the medical field, it was necessary to extend the nomenclature to include those terms related with ambient sensors and other domotic (i.e., home automation) devices.
In the data model presented in this article (Fig. 1), every device has a series of associated channels, which in turn comprise a set of metrics or parameters.
Proposed data model.
The “Device” class is equivalent to the Virtual Medical Device class included in the X73 standard 24 and represents any device working in the scenario. Although the aforementioned standard only includes devices with medical nature, we have developed an extension so it also includes non-medical devices such as ambient devices.
The “Channel” class contains a set of related metrics, that is, metrics that share some characteristics. It can provide independence of the measurements from the devices themselves, as the information is stored in channels and not in devices.
Metrics are represented by the “Parameter” class. This class is equivalent to the “Metric” class included in the X73 standard. One parameter or one metric corresponds to any measurement taken by a device. This measurement can be either a single value or a set of values and can be numeric or non-numeric.
The following classes descend from the “Parameter” class attending to the nature of the measurement data: “NumericParameter” (numeric value or values), “SampleArrayParameter” (samples vector), “EnumerationParameter” (variable that can take specific values, usually text), and “ComplexParameter” (parameter formed by other kinds of measurements).
The “Numeric Parameter,” “Enumeration Parameter,” “Complex Parameter,” “Array Parameter,” and all those classes stemming from it have been directly adopted from the X73 standard. This set of classes provides the representation of any measurement without including any additional attribute. In addition, they contain not just the values corresponding to the measurement itself, but also a wide set of attributes that provide all the information of interest about the measured parameter.
Figure 2 depicts an example of how the information provided by an ECG would be represented according to this data model.
Electrocardiogram (ECG) information represented according to the data model. HR, heart rate.
The “BioECG” class represents the device. The attributes of this class are defined in the data model and contain both the information gathered by the sensor and the information about the quality and characteristics of the signal (resolution, sampling frequency, etc.).
The “ECGChannel” contains parameters that represent the multiple derivations that an ECG may have. “RespirationRateChannel” contains, as its name suggests, information about the respiration rate that can be obtained from an ECG. Finally, “HRChannel” contains parameters to represent the heart rate (HR).
Results
After the definition of the data model, a software communication architecture that permitted plug-and-play device connection was created. This was achieved by using the OSGi architecture. 18 Every element forming the architecture was to be encapsulated inside an OSGi bundle and will communicate with the rest of bundles through a publication-subscription system. The OSGi architecture has proved to be very useful for device intercommunication in home scenarios, such as in the case of radio frequency identification devices. 25
One of the objectives of this system is to make the connected devices independent from the extracted information, so that the rest of the platform is provided with all the information in a transparent way, without having to take care of what devices are connected.
As noted above, the inclusion of channels in the data model allows for the independence of the information stored in the platform from the sensors that provide it. We can consider a scenario where the patient is wearing a pulse oximeter and an ECG recorder. Both devices can measure a pulse value. If we query this value from a patient, the system will provide us with the information stored in the platform without worrying about which of the two sensors is actually measuring it. The system only sees the available list of channels and will choose the one considered as the most convenient one.
Inside the developed system there are four kinds of bundles that are of vital importance for device management and their inclusion inside the platform: the driver, the measurement-specific manager, the device manager, and the preprocessing and feature extraction bundle. Figure 3 shows the organization of these bundles.
Open Services Gateway Initiative-based architecture.
In the following subsections, we will describe each one of the elements forming the system, as well as an example of the communications triggered between the bundles after the connection of a device.
DRIVER
The fact that every manufacturer creates its devices using its own specifications makes the use of a driver absolutely unavoidable. Every device will have its own communication driver encapsulated inside a bundle.
The driver will be in charge of (1) detecting the presence of the new device and (2) gathering the information obtained by the sensor and delivering it to the rest of the platform publishing the necessary “Device” classes. Each of these classes will correspond to a specific kind of measurement. For example, a multiparameter device driver that provides pulse and temperature measures will publish two “Device” classes, one for each type of measure.
The data transfer format is device-dependent, so the driver must be able to read the data frame sent, interpret it according to the given format, and save the data in the published “Device” classes.
MEASUREMENT-SPECIFIC MANAGER
The measurement-specific manager is a module that acts as an intermediary between the drivers of a specific kind of sensor and the rest of the platform. It manages all the information gathered by the devices and adapts it to the presented data model.
We will find only one manager for every kind of measurement (e.g., we will have a measurement manager for the ECG devices and another one for the pulse oximeters). This manager will therefore work with all devices offering measurements of which it is responsible, regardless of the device manufacturer. That is, two ECG devices from different manufacturers will be handled by the same manager.
A multiparametric device will be managed by various measurement managers, one for every kind of parameter that it provides, even though there is only one driver. The devices being represented by the “Device” class and providing the drivers are of virtual nature. A physical device can be formed by various virtual devices (multiparametric device), and a virtual device can be formed by many physical sensors (a sensor network providing a single measurement obtained as the combination of the particular gathered signals). On the whole, there is only one driver for each physical device, which, in addition, is able to publish more than a virtual device in the platform.
As we can see in Figure 3, devices A and C correspond to two monoparametric sensors managed by their own measurement manager, whereas device B is a multiparametric sensor with only one driver being managed by two different bundles.
The measurement manager is in charge of detecting the appearance of new devices to manage (publications of the “Device” class carried out by the drivers), and will act creating storage structures for the information following the data model. Specifically, it will have to create the channels and parameters associated to each device and link them to it. Furthermore, it will introduce new information in the platform as it is updated in the system by the drivers.
If the signals need some preprocessing or if the system needs extra information that is not provided by the sensors, the measurement manager module will call the appropriate functions. The manager has to know all the methods that can be applied to a signal and decide whether they should be applied or not.
The list of published channels will depend on the signal characteristics and the capacity of the platform to implement a certain kind of algorithms. If the quality of the signal is not good enough to extract the required features, then the channels associated with those features are not created. The same will occur if we are dealing with a platform with limited processing capacity that is not able to run a certain algorithm because of its high computational cost.
Preprocessing and Feature Extraction Bundle
Many of the signals measured by the sensors require a previous preprocessing stage and a feature extraction process before any useful information for the system can be obtained. The preprocessing and feature extraction bundle contains all these functions. It contains both general methods that are applicable to many kinds of signals and specific methods that can be applied only to one kind of signal. Inside this bundle there is a specific class for every kind of signal that contains all the methods that can be applied to that signal.
Two of the most common algorithms in ECG signal processing are signal filtering (noise suppression) and HR extraction. Hence, we can find a class named “ECGPreprocess” that contains both methods for the application of these algorithms.
Device Manager Bundle
Even though the channels allow measurements to be independent from the sensors gathering them, it may also be interesting to know which devices are connected to the platform and their associated channels. This information is available in the system by means of the device manager bundle.
Every time a “Device” class is generated in the system by a driver, the device manager gets a notification that allows it to keep a record of the connected sensors and their channels.
Example Of Communication Between Bundles
Figure 4 shows the communications triggered when a series of devices are connected to the system. When an ECG device is connected, driver A (specific for this device) detects its presence and publishes in the system the class that will represent the virtual device of the ECG (“bioECG”) according to the specifications of the data model.
Communications triggered by a new connection. ECG, electrocardiogram; HR, heart rate; SpO2, oxygen saturation.
The measurement-specific manager, which is subscribed to the creation of any class of this kind, creates the required storing structures (described in Fig. 2) according to the defined data model. Therefore, three channels associated to the device are published. The manager analyzes the characteristics of the signal that is provided by the driver and decides to apply two algorithms, one for signal preprocessing and a second one for HR extraction, both contained in the same bundle. Then, it introduces the information gathered by the sensor into the created structures.
When the pulse oximeter device is connected (“SpO2 Device”), a similar process is triggered, but in this case the manager decides not to apply any preprocessing, and it just copy the information given by the sensor in the channels and corresponding parameters.
As we can see in Figure 4, there is a common channel in the channel lists published by the managers. This channel (“HRChannel”) provides a pulse value that is extracted by a different kind of sensor in each case. As the system is concerned, there is no difference between both channels, and both data flows are considered as valid.
The third device that joins the platform is a multiparametric sensor. The driver bundle will publish two different classes that correspond to the two virtual devices that compose the sensor.
Finally we can see that the “Device Manager,” which is subscribed to any class derived from the “Device” class, introduces into the system information about the devices that are connected to the platform.
When a device is disconnected from the system, all the channels associated with it will disappear as well as the corresponding gathered information.
Discussion
This system has been designed and implemented as part of the AmIVital Project. 26 AmIVital, is a Spanish CENIT project where public research institutions and 17 companies such as Telefónica R&D, Siemens, Ericsson, and Telvent are taking part. The total budget of the project is over 20 million Euros.
The main population target of the project are elderly people, dependent persons, chronic patients, sportsmen, and people performing physical activity. The objective of AmIVital is to set the technological base that allows for the implementation of assistance and telemedicine services in the personal environment of the patient.
A very important part of the project corresponds to research and development of sensor networks using medical and ambient sensors and domotic actuators, multimodal interfaces and communication networks that are able to operate in home environments (PCs, residential gateways, etc.), and mobile platforms (personal digital assistants, mobile phones, etc.). Everything is connected to a coordination center that controls these networks and is able to provide medical assistance services such as teleconsultation or urgent medical assistance.
AmIVital is a real application, and, as such, it requires implementable solutions that solve the aforementioned interoperability problems. The inclusion of measurement-specific managers, presented in this article, permits the system to operate regardless of the sensors connected to it. For instance, once the measurement manager for a signal coming from an ECG is implemented, it will be able to deal with any ECG connected to the system regardless of the manufacturer as long as the driver is provided.
In order to implement a driver in the AmIVital platform, the main requirement is that a “Device” class gathering all the useful information of the device should be published following the directives of the data model.
In addition to this, the use of OSGi technology not only provides a plug-and-play connection of devices but also allows the system to be implemented in different platforms, no matter whether it is fixed (PC) or mobile (mobile telephony or personal digital assistant), without having to make any significant modifications.
A wide variety of measurement management bundles have been already developed for AmIVital, of both biometric and ambient nature, allowing the connection of a large number of devices. These devices have been integrated into a home scenario for the treatment of one of the most prevalent chronic diseases today: chronic obstructive pulmonary disease (COPD).
Within this scenario, especially significant are the respiration and pulse oximetry sensors that measure parameters directly related to the disease as well as the ECG, activity, and location sensors, which let us control the exercises that COPD patients should perform. Additionally, in a COPD scenario, the environmental characteristics of the home are of vital importance. As a consequence of this, sensors that measure temperature and humidity of the room and the air quality (CO2 and O2) also become indispensable.
Besides all these bundles relating to the measures discussed, others have also been implemented to manage secondary sensors for this scenario, such as those measuring perspiration, body temperature, weight, identification, or ambient light. As we have already mentioned, the implementation of these bundles allows for the connection of any device that provides these measures.
Preprocessing and device management bundles have also been created for this scenario. In particular, the architecture has been tested using multiple devices such as the Alive Heart Monitor sensor (ECG and activity), 27 Equivital Systems (ECG, temperature, respiration, and activity), 28 and Onyx II 9560 pulse oximeter 29 together with a Zigbee network of motes with environmental and location sensors.
In the demonstration of the project two areas were simulated in which an independent environmental monitoring was performed using a highly reliable tracking system capable of identifying not only in which room the patient was, but also the exact area where he or she was located. On both the fixed and the mobile platform all the information provided by the devices was gathered and then sent to a control center, which in this demonstration just presented graphically all the information received.
It is important to note that the behavior of the platform when using either Equivital devices or the Alive Heart Monitor (sensors that provide both ECG and activity signals) is identical, and no distinction is made between one sensor and the other, being both completely transparent to the user. The implemented system (Fig. 5) has been evaluated satisfactorily for both fixed and mobile platforms.
System implemented for the AmIVital project demonstration.
Footnotes
Acknowledgments
This work has been developed as a part of the AmIVital project (Digital Personal Environment for Health and Welfare), funded by the Spanish Ministry of Science and Innovation (CENIT 2007-2010 Program), and partially supported by the Spanish CICYT project SAF2010-20558.
Disclosure Statement
No competing financial interests exist.