Abstract
Chronic heart failure (CHF) is among the major causes of hospitalization for elderly citizens. Its considerable impact on patient quality of life, the resources congestion, and the related costs can be efficiently mitigated using remote wireless biosensors networks placed at patient home, able to communicate in secure way over the public Internet with the cardiology departmental Hospital Information System (HIS). In this way, physicians can monitor the situation of several patients at distance and quickly realize and act alterations in vital parameters. In this scenario, the Health@Home (H@H) platform is conceived. The pool of Bluetooth sensors enables patients to daily collect vital signs at home in noninvasive fashion. A home gateway receives and processes all signals before sending them to a server node in charge of interfacing with the usual HIS. The novel concept of operating protocol (OP) represents a list of actions, remotely configurable, that the domestic network has to follow (required measurements, transmissions, comparisons with personalized thresholds, etc.). The first medical tests on 30 patients (1 month) allowed to verify the model, both from the patient and the medical perspective. The main evaluation metrics were usability, flexibility, and reliability of the communication from sensors to HIS.
1. Introduction
Chronic heart failure represents one of the most relevant chronic diseases in all industrialized countries, affecting approximately 20 million people in Europe and US [1–3]. The hospital admissions, mainly concentrated in the older adults segment, range from a prevalence of 1.5% to 8.4% in 65–74 years and 75 years or older groups, respectively [2]. Admissions to hospital with heart failure have significantly doubled in the last 20 years [1]. Despite the advancements in medical and pharmacological fields, CHF continues to increase in both prevalence and incidence, with 4 million new cases each year in Europe and US, as result of the general ageing of population [4]. To address the societal and economical issues posed by the hospital admissions due to CHF [5] (2% of the total healthcare expenditure [6, 7], with hospitalizations that represent more than two-thirds of such expenditure [3]), the introduction of cost-efficient healthcare services/treatments is required, in particular preventive strategies aiming at more effective outpatient follow-up management programs [8].
It is acknowledged that the current healthcare model based on periodic visits, usually monthly, leads to a high re-hospitalization rate (25% within 30 days and 45% within 6 months [9]), failing to early detect the signs of destabilization. Besides the important problem of poor quality of life of surviving patients and their caregivers [10], this results in high congestion in specialized health facilities and poses financial problems to the National Health Systems. There is in the literature some evidence that a multidisciplinary management program [8, 11], including a home-based follow-up strategy, that is, telemonitoring or structured telephone support, can improve the outcomes of heart failure patients. It provides a reduction in mortality, hospital readmissions, and lengths of hospital stays, and in general increases patient satisfaction [12–14].
The current ICTs (Information and Communication Technologies) enable to build effective telemonitoring systems, overcoming the limit of the actual models. Biomedical wireless sensors networks allow for a daily collection of interesting biological parameters at home. The increasing computational power available in numbers of embedded devices permits more and more complex signal processing algorithms, while large amounts of data can be safely moved globally via the Internet.
The Heatlh@Home (H@H) project introduces a new flexible and high configurable platform for domestic vital signs acquisition and processing, along with a management scheme able to support in an integrated and coordinated fashion the whole treatment of CHF patients since their enrolment in the system. Being directly integrated with the usual cardiology departmental HIS, the H@H platform aims at connecting in-hospital care of the acute syndrome with out-of-hospital followup by patient/family caregiver. Patients’ signs, symptoms, and raised alarms can be received remotely by the healthcare providers, and aggravations can be quickly detected and addressed. More frequent (usually daily) assessment of clinical parameters than in conventional practice is permitted [15]. The benefits extend beyond the early detection of clinical destabilization: better and optimized scheduling of specialized resources and reduction of unnecessary travel to hospital.
Hereafter, Section 2 reviews the state of the art. The H@H system architecture is introduced in Section 3. Sections 4, 5, and 6 describe respectively the sensing devices, the home gateway and the collection server. Communication details are explained in Section 7. Section 8 describes the testing validation phase. Conclusions are drawn in Section 9.
2. State of the Art Review for Telemedicine Systems
Considering the Ambient Assisted Living (AAL) roadmap [16] that draws the guidelines to develop efficient strategies and systems to face the aging of population, along with future challenges in telecare [17] and some recent studies on AAL solutions [18], especially for telemonitoring [19], the desirable features of a monitoring platform for chronic disease are as follows:(1)health monitoring service using wearable/portable sensors for non-invasive measure of vital signs, activity level and symptoms signaling,(2)reasoning and data processing to detect emergency situations or behaviors,(3)secure and reliable communication of data,(4)interconnection between stationary home care and acute medical treatment,(5)integration with existing solutions and components,(6)modular structure of the solution to ensure easy maintenance and future extensions,(7)high degree of interoperability accomplished by the use of well-known communication standards,(8)flexibility to face the wide range of patients’ status and the progress of chronic diseases,(9)interfaces and system requirements defined taking into account the individuality of the end user group.
Today there are many system of telemedicine [20–27] specific for CHF or suitable for this kind of disease, together with many dedicated prototypes and project trial [28–30]. However, at the state-of-the-art, it is difficult to find a solution that completely agrees with all the previous requirements. Systems based on telephone calls or web-portal to report symptoms and outcomes of the measures have to be discarded for scalability and usability issues. Considering instead systems in which measures are performed by the patient and automatically transmitted to remote node, most of them use a dedicated collection database failing the requirement point 4 and partially the point 5. This way data collected at home are not flowed into the existing HIS that in turn contains only data related to acute syndrome. All solutions have a gateway that at least receives and forwards data coming from sensors. Sometimes signal processing and reminders are provided. This device is often realized using a smartphone or tablet, a set-of-box or a PC. However their mall screens and rich application interfaces do not meet the requirements of older users (>65 years and often with comorbidity and cognitive or sensorial deficit), lowering the acceptance/usability of the system. Finally, all considered systems do not include a formal method to adapt and monitor the follow-up activities to be performed at home by the patient. The H@H telecare platform, described in detail in the following sections, represents a complete and high configurable ICT solution for CHF remote management, developed taking into consideration all the guidelines discussed in the above points to overcome the limits of the state of the art.
3. H@H Telecare System and Networking Overview
The requirements of the system come from a close collaboration among important healthcare providers (Hospitales Virgen del Rocio, Spain; Dom Koper Hospital in Slovenia and the research clinical center Fondazione Gabriele Monasterio in Italy) and technical entities within the H@H consortium. This multidisciplinary approach leads to develop a platform able to meet medical expectation, patient’s features (elderly, with numerous comorbidity and cognitive deficit), and the progressive nature of the disease.
The key points of the proposed architecture are two. Firstly the concept of follow-up operating protocol (OP) as embed formal description of the medical prescription and definition of the behavior of the home system. Secondary, the native integration with the HIS which is already present in most cardiology departments. Other interesting features are the reduced impact on the patient due to the limited effort required to follow the assigned therapy and the low overhead introduced with respect to the regular activity of medical staff.
From the architectural point of view, the global system follows the client/server paradigm (see Figure 1). At patient’s home, a set of wireless biosensors allows to measure the main vital signs while the home gateway centralizes all computation and communication resources, masking the complexity of the sensors network to the server. The latter, installed at health service facilities, accepts and processes data from several gateways making them available in the HIS and finally allows the management of all patients since their enrolment. This hierarchical structure improves the scalability and the upgrading of the system.
Biomedical sensors that form the network are equipped with wireless connectivity in order to submit acquired data to the home gateway. In that sense Bluetooth 2.0 technology represents the better tradeoff among available bandwidth (430 Kbps against ~18 Kbps required by the ECG-SpO2 device), security and reliability of the connection (SAFER encryption algorithm), cost and power consumption of the node, link distance. Comparison among Bluetooth and the rest of possible communication technologies is shown in Figure 2.
The home gateway behaves as a server in the wireless sensors network located at the patient’s home. It receives data from sensors over point-to-point connections, managing in time-division way the communication resource. Specific signal processing algorithms executed on incoming values allow to timely detect alterations in punctual values and trends over short and medium periods. The final step consists of forwarding elaborated data to the hospital server to be further analyzed and stored into the Electronic Health Record (EHR).
To accomplish the transmission task, multiple available technologies ensure a good adaptability of the system in overall operating areas. As outcome of the survey illustrated in Figure 3, the home gateway exploits both ADSL (via Ethernet or WiFi) and mobile broadband connectivity. The GSM global coverage of 99% gives a very high degree of connectivity, dealing also with digital divide issues because in the worst case the GPRS upload data rate of 20 Kbps is sufficient to transmit data in few minutes. Furthermore, the gateway leverages the GSM capability to send SMSs to the physician, patient’s relatives, and caregivers in case of alarm situations.
Because of the personal nature of the data in transit, the privacy is a primary goal to achieve, avoiding that eavesdroppers could understand the content of the communications. Different protocols ensure simultaneously authentication, integrity, and confidentiality: IPSec, SSL/TSL, HTTPS, symmetric protocols. The chosen HTTPS relies on SSL connection and allows to exchange HTTP messages over a secure channels. It comes natively with all operating systems and does not require any further configuration other than the SSL certificate installation.
Finally, H@H involves international and well-known formats for data representation to definitively improve the interoperability of the system and the integration with existing HIS. The ANSI HL7-RIM Clinical Document Architecture (CDA) v2 [31–33] and XML codify, respectively, the post-processed vital signals and the current OP.
4. Wireless Sensors
The sensing elements of the domestic network are wireless biomedical devices selected with the rationale to minimize the impact on the patient, in order to be easily used autonomously by the patient at home. According to the analysis carried out by the physicians, the sensors in the H@H system are wearable/portable, noninvasivity, wireless [34], and battery powered. Additionally, to meet the peculiar patient features, the measurement experience consists of wearing/using the sensors only for the duration of the acquisition, without any long-term installation of electrodes or other reading terminals. Low quality signals arising from sensors mispositioning are detected and requested again. Indeed signal quality is not excessively dependent on transducer positioning (e.g., 3-lead ECG instead of a more complex 12-lead ECG is adopted, as in [35]).
The significant vital parameters to monitor in a CHF patient (ECG, SpO2, weight, blood pressure, chest impedance, respiration, and posture) have been clustered into two possible configurations: basic and advanced. Basic partitioning implements the minimum set of requirements to achieve a complete telecare system, while the advanced version integrates additional features to widen the kind of CHF patients to be enrolled into the service and to cope with other chronic diseases (i.e., chronic obstructive pulmonary disease, diabetes). Table 1 shows the features of the sensors and the composition of the basic and advanced version of the system.
The basic version of the H@H monitoring system, used for the demonstration phase, envisages the use of three sensing devices (see Figure 4). (i)The commercial UA-767BT arm cuff device for blood pressure readings by A&D Medical. The sensibility range and the accuracy are 20–280 mmHg and ±3 mmHg respectively. It outputs packets with 8 bit values of systolic and diastolic pressure and heart rate.(ii)The commercial UA-321PBT digital scale by the same manufacturer for body mass measurements. It has a maximum capacity of 200 Kg and an accuracy of ±0.1 Kg. The value of the current body mass can be calculated from the 5 bytes data packets. (iii)The ECG-SpO2 sensing module for acquiring synchronized 3-lead ECG, SpO2 and plethysmographic traces, developed ad hoc in the H@H project and detailed by the authors in [36]. Conditioned and digitalized (at 500 samples/s) ECG waveforms of two standard limb leads, level of oxygen saturation in the blood, digitalized (at 100 samples/s) plethysmographic waveform are sent in real time during the acquisition.
The latter device is assembled on a single 90 × 14 mm printed circuit board, hosting the CARDIC integrated circuit [36] to read 12 bit resolution ECG leads, the ChipOx OEM by Envitec which provides SpO2 readings and a digitalized plethysmographic waveform (measurement range from 45% to 100%, with an accuracy of 1.5–2% for oxygen saturation and measurement range 0–255 LSB with an accuracy of 6 ppm/LSB for plethysmography), the Bluetooth 2.0 chip OEMSPA312i by Connect Blue and the MSP430F2418 Ultra-Low Power Mixed Signal Controller for mixing raw data before passing them to the Bluetooth interface. Integrating ECG and SpO2 functionalities in a novel single sensor reduces the number of devices in the final system and also enables for advanced analysis (e.g., the Pulse Transit Time estimation) using synchronization between SpO2 and ECG traces. The sensor naturally allows to deal with a single parameter at a time.
All sensing devices send only raw data exploiting the onboard Bluetooth 2.0 Class I transceiver and data signal processing is completely demanded to the home gateway. They use the Service Discovery Protocol (SDP) and the Serial Port Profile (SPP) services to wirelessly communicate with the gateway, which acts as access point. PIN-based peering procedure is required once at configuration time, while during the permanence at patient’s home the wireless sensors network not require further configurations (device searches, PIN validations, etc). Indeed each sensor acts as initiator of connections towards the home gateway when activated. This means that a measure acquisition simply consists of turning on the sensing device and waiting until the end of the measurement process without any preventive interactions, introducing also benefits in battery saving. Only one active connection at a time can be managed by the implemented home gateway, while simultaneous connection attempts lead to discard attempts other than the first. This is not a real limitation since measurements have to be done one by one by the user.
5. Home Gateway and Operating Protocol
5.1. Home Gateway HW/SW Platform
The home gateway is the elaboration and communication node of the wireless sensors network. Centralizing and automating the acquisition and transmission of vital signs, it minimizes patient efforts. The gateway accepts incoming connections over the Bluetooth channel and handles all sensor-dependent communication protocols to receive data packets from the biomedical sensors and to extract their content. Its primary task is the data processing for early detection of critical alterations and the secure forwarding of the computation results (i.e., filtered data, alarms, etc.) to the remote server system to be further analyzed and finally flowed into the cardiology departmental HIS. The system provides a permanent storage of pending data waiting for transmission so that power supply failures do not result in data loss (16 MB, for 1 week complete acquisitions). With respect to the remote server the gateway masks the complexity and the heterogeneity of the sensors network behind it.
The gateway follows the OP and guides step by step the patient in performing the activities as scheduled by the physician, leveraging its powerful graphical user interface. In addition to the planned measures the system can receive others spontaneously performed by the patient. In this case it asks to select the reason of the measurement from a list, still ensuring the analysis process. Finally it is possible to submit alarms manually from a selectable list (i.e., dyspnoea, palpitation, breathlessness, etc.).
To achieve a fully compliance of requirements, taking into account flexibility, robustness, and user-friendliness, and at the same time reducing costs and project risks, several hardware solutions have been considered. Full custom platform presents some advantages but long development/testing time. Moreover, the number of devices for early demonstration is very low, resulting in a high cost per unit. Mobile phone has too small display and keys, limited memory space and comes with only mobile broadband connectivity. In smartphone potentially the allocation of memory and the computational resources meet the demands. However, it is not the better solution due to the size of display and also because, being born to telephony, running applications are placed on hold/delayed status in case of incoming call. Bluetooth access points are typically used to realize Bluetooth network in proximity marketing. Some of them allow customizing its functionality thanks to a Linux software platform and specific SDKs. These products are upgradeable with a series of interfaces with USB connection such as GSM/UMTS or Wifi modules. The degree of customization reachable without incurring the cost of SDK, inferred by tests, is not adequate for the project needs.
A netbook represents the best tradeoff among all metrics. Designed for wireless services it typically includes most of the needed resources: Bluetooth, Wifi, modem, 9-10 inches screen, speakers, low-power ×86—compatible processor, storage space. All missing interfaces, or future extensions, can be added by USB connector. The only drawback is the keyboard, whose keys are too small and too many with respect to the request. So in replacement of the native keyboard, a custom one was developed for the selected netbook (Samsung N150), including only the required buttons: Yes, No, Alarm sending, and Up/Down scroll buttons (see Figure 5).
(a)
(b)
The operating system chosen for the gateway is based on Linux kernel 2.6.27 or higher, customized with the addition of a lightweight window manager and deprived of unnecessary services, applications, and kernel modules. The H@H software runs directly when netbook is switched on. It is implemented in C language using, respectively, libbluetooth, libSSL, libXML, libgtk to support Bluetooth management, security, XML parsing, and graphical development.
The software architecture is represented in Figure 6 using an UML diagram:(i)the sensor server manages incoming connections over Bluetooth interface to receive raw data from sensors,(ii)the network communicator manages the available channels to forward both collected information to the server and alert SMS to caregivers/physicians,(iii)the clock and the scheduler ensure scheduling and reminder of all the therapeutic activities,(iv)the graphical user interface handles both events throw during interaction with the keypad and the visualization of messages in the application window.
The main concerns of the system were implemented in separated threads to ensure a high modularity and the maximum flexibility when combining them in any arbitrary operating protocol. This modular architecture ensures easy maintenance and upgrades, including future extensions with new sensors or the introduction of new communication standards.
5.2. Operating Protocol
The newly developed OP concept consists of a set of actions, like taking measurements or replying to simple questions, that the patient must follow during the monitoring period as well as it completely defines the behavior of the home gateway in terms of types and frequencies of measurements transmission policy, selectable symptoms, comparison thresholds, and phone numbers for each alarm. The OP is tailored by the physician at the beginning of the monitoring period and it can be remotely updated in progress according to the patient conditions. In fact at the end of any data transmission, if necessary, the server is able to update the current operating protocol by sending the new one to the interested gateway. The OP update and the consequently reconfiguration of the gateway is totally transparent to the user. Usual values for measuring frequencies and ranges for alarms detection are shown in Table 2, but clinicians can configure each parameter.
5.3. Data Processing and Alarm Management
Sensor data signal processing, implemented in the home gateway, is in charge of detecting alterations in vital signs potentially dangerous for the patient. In this way the physicians are timely alerted if anything out of the ordinary is found and they have in the HIS all patients’ data to plan the following actions. Data processing involves three main steps: preprocessing, analysis and cry wolf avoidance. The preprocessing consists of the filtering of raw data provided by the sensors, removal of noise and main interference, and the extraction of derived information. The analysis step compares the outcome of the preprocessing with the thresholds defined in the OP that establish the admissibility range for punctual values or trends over a medium period. The last step is useful to reduce the number of false positive alarms, for example due to temporary stress or sensors misuse. In the presence of abnormal values, the same measurement is shortly deferred and only if the condition is confirmed the gateway raises the alarm, contacting caregiver or health professionals via SMS. The required arithmetic precision is compliant with real-time implementation on 32-bit single-core processor and the RAM memory available in the netbook. All involved algorithms have a linear complexity with the number of considered samples of the signal, both in terms of memory and computational cycles.
The electrocardiographic signal is treated to extract maximum, minimum, and average heart rate over the track as well as to detect the presence of atrial fibrillation. The reference point within the ECG signal is the QRS complex: three deflections that occur periodically and in rapid succession, where the R point represents the main upward ones. A derivative-based algorithm [37] and a rule-based system [38] for the QRS complex detection are applied. The source signal is filtered in order to keep just the central frequencies (8 to 30 Hz) where the QRS complex information lays. Afterwards, the signal is differentiated, squared, and averaged. Comparing the averaged signal against a threshold creates a set of windows that allow to recognize the R peaks in the filtered signal (maximum positive within the window). The R peak has still passed through a rule-based system that evaluates whether the detected QRS is a valid QRS complex or not based on the distance in time between consecutive peaks. To improve the legibility of the track for further medical review, a 50 Hz notch filter is applied to the signal to remove power-line noise. Figures 7(a) and 7(b) show the raw and filtered signal. There is also a cubic spline data interpolation algorithm that extracts the envelope of the R peaks as an indirect indication of the respiratory activity. Figure 7(c) shows the envelope signal of the peaks. The analysis of the intervals between consecutive R peaks, using a 30 seconds window shifted along the time axis by 5 seconds length steps [39], allows to calculate the heart rate.
(a)
(b)
(c)
Concerning SpO2 signal analysis, relevant values are maximum, minimum, and also the average level of oxygen saturation over the track, extracted by a digital low-pass FIR filter. The normal range in healthy people is from 94% to 100% while oxygenation can quickly lower in CHF patients; hence, a frequent monitoring is necessary to detect these changes.
Concerning blood pressure signal processing, systolic and diastolic values are analyzed (see Figure 8) to find out under or over threshold situations and the general trends of both parameters are verified looking for suspicious variability that are typical manifestation of cardiac instability.
As far as weight, this parameter is easy to measure and elaborate as well as very effective in the CHF management. It allows to detect fluid retention in the patient. The system is able to find out increases of 1 Kg in a day or 3 Kg in a week that are considered potentially critical situations in CHF.
5.4. User Interface
The user interface has an essential role in this application having to guide the patient in following the scheduled measurements or drugs assumptions. The developed home gateway provides an intuitive user interface able to display guide images, reminder messages, and sounds when a planned activity time is reached. Figure 9 shows the appearance of the graphical interface. Patients can read the last measured values of weight, blood pressure, heart rate, and oxygen saturation. At the top of Figure 9 the reminder textbox indicates the requested activity, along with the graphical helper that shows the correct actions to be done as gif animation. The other textboxes report the status of the related sensor, included battery charge. Green, yellow, and red textboxes background colors are used for information, warning, and error messages, respectively. In idle state the time of the next activity is visualized. The custom keypad allows to navigate and confirm symptoms in case of manual alarm or extra measure and to answer questions about pills therapy.
The gateway provides also the possibility to store in a local database all collected vital signs occupying less than 1 GB for one year observation. This functionality allows to select and visualize ECG tracks, R-Wave envelops, SpO2 tracks, and plethysmographic waves or trend graphs for weight, blood pressure, heart rate and SpO2. This is particular useful when medical staff is present at patient’s home and needs to consult the measurements repository on-site.
6. Remote Server Module
The H@H server platform is a web-based application that receives data from gateways, providing a detailed process of analysis based on expert systems and finally the update of the patient record in the departmental HIS. No summarization function is provided, but it deals with all the received unaggregated data. Moreover the H@H server platform exports interfaces that allow the clinicians to interact with the system, retrieve information and manage all patients.
The format of data shared between the H@H server and the HIS is the ANSI HL7-RIM CDA v2, the same template adopted for the communications gateway-server. Besides HL7 CDA v2 is also possible to use other XML formats. Transmissions leverage the web services architecture and MLLP (Minimum Low Level Protocol) is applicable.
Two possible ways of integration with existing HIS are available (see Figure 10) in order to improve the interoperability of the system. In the first mode, called synchronous request (SR), all data are stored locally in the H@H server platform and vital signs are provided on-demand as result of query messages submitted from the HIS. Queries address a dedicated service endpoint and use XML to specify the searching parameters: the patient identification, the vital signs, and the time interval. In the SR mode a specific interface to build the queries has to be added to the HIS. The second mode, the automatic notification (AN) method, requires that the HIS interested in receiving the clinical information coming from the gateways exposes a dedicated webservice reachable by the H@H software platform. When new data are received and stored in the H@H server, they are immediately flowed to the registered HIS, enabling an automatic update of the EHR.
From the functional point of view the software platform is composed of two main parts: the core and the frontend.
The frontend represents the human machine interface for the physicians (see Figure 11). Its main functions are related to the patient management since their enrolment, when the physician inserts the patient data and configures his OP. To be noted that user interfaces at both home gateway and server sides have been realized in different languages (English, Italian, Slovenian, Spanish) to allow the installation of the system in the National Health Systems of the different project partners. At any time the physician is able to look through the patient clinical folder, comparing the patient health status in different periods by means of measurement trends. The system is able to highlight the alarms encountered during the monitoring. If necessary the physician can modify the OP at any time, this produces an automatic and transparent update of the gateway. The frontend is based on the rich client technology which allows defining a simple user interface with high performance from the user interactivity point of view. The architecture is able to completely decouple application logic from data displaying, in order to make the interface fast, flexible, and usable by the user. Conceptually, the browser provides the features of a desktop application accessible from the Internet without installing any add-on. The visual components, written in Java Script, are downloaded at runtime and run locally into the browser.
The core part is based on the Spring Framework [40] which accepts patient measurements collected and sent by the gateways through a dedicated webservice endpoint. All received messages are formally verified and the contained observations are stored in the local database. The core is also in charge of managing the integration with the HIS, both serving the incoming queries in SR mode or forwarding vital signs to HIS in AN mode. Additionally the core is responsible for data retrieval when requested by the frontend. Data between the core and the frontend is exchanged through Java Script Object Notation. Finally the core exposes an additional service useful when a gateway has to be customized for new users.
7. Gateway-Server Networking
WAN (Wide Area Network) technologies, ADSL, or mobile broadband are used to communicate with the collection server. As data exchanged between gateway and server involves the public Internet, the use of HTTPS protocol fits completely the requirements of confidentiality, authenticity, and integrity for the data traffic. The protocol also meets perfectly the web service paradigm: the request message contains all pending results and events within its body, coded according to the HL7-RIM CDA v2, while the response includes the XML description of the current OP, allowing remote updates after each transmission.
The header of the CDA document contains information about the patient, used to address its EHR, and the recipient hospital. Result and Vital Signs sections contain numeric and waveform observation blocks, one for each measure. The InterpretationCode tag is used to mark normal or abnormal values. Symptoms are hosted as event observations in the Purpose section. Medical equipment section describes the sensing devices used. All observations use SNOME CT [41] or LOINC [42] codes.
Transmission occurs according to the OP, at the end of an activity, or on time-base (i.e., daily or weekly), and always after an alarm either manually signaled or automatically detected.
Communication occurs also when the gateway has to be configured for a new patient. A dedicated interface allows to completely configure the home gateway or to modify the current patient’s information status, server IP addresses and ports, names of the collection and configuration service, and regionalization. The gateway contacts the configuration endpoint indicating the patient’s ID. The server replies with all the information of the given patient and the personal OP. Now the configuration is complete, the reachability of the endpoints is tested and the monitoring can start. Using this procedure, patient information and operating protocol are defined only once at server-side, reducing the possibility of mistakes.
8. H@H Telecare System Testing
One of the key issues for the adoption of new telemedicine systems is an exhaustive mixed HW/SW test [43, 44]. The H@H system follows a very structured and incremental testing procedure concluded with the final technical validation and demonstration phase. Unit test of hardware components and operational correctness of software and firmware applications using conventional procedures were the first steps. The following integration test verified the end-to-end communication in the system and the overall system-level interactions of the different HW and SW parts. To this aim some ad hoc prepared scenarios and the involvement of healthy users were used. The last important phase before the final technical demonstration was the alpha-testing: two patients minimally aware of ICT and younger than the CHF average age (1 month). The first impressions of physicians and patients coming from these tests made possible to tune the final version of the system.
The technical validation of the H@H platform involved 30 patients with CHF disease in New York Heart Association (NYHA) classes III and IV, with an average age of 62 years, hospitalized for acute heart failure in the previous 6 months and consenting to take part in the study. Acute coronary syndrome within 3 months before the enrolment was the only exclusion criteria. The size of the set of CHF affected patients is similar to those of other works published in the literature about ICT systems for CHF monitoring [45]. The minimum period of monitoring was one month.
The metrics established for the evaluation of the system belong to two main categories: objective and subjective. The first ones are related to items unequivocally measurable, the latter depend on the personal experience during the demonstration and the feeling with the system. A specific testing protocol and a questionnaire to collect patients, caregivers, and physicians feedbacks were used to validate the system. A group of selected cardiologist checked out the information arrival in HIS, evaluating the quality and coherence of data collected and the relevance of the alarms. The ergonomic of patient’s interface was evaluated as a key point of system functionalities, as well as the general end-user usability. On the other hand the robustness and reliability of data transmission and the effectiveness from the medical point of view were evaluated.
The results show a very limited number of activity misses (<3%), mostly in the first days of monitoring. Moreover, the number of false positive alarms is less than 5%. No connectivity and transmission problems occurred, including data or sensors network configuration lost. Thanks to the high quality of acquired signals and alarms detection capability the physicians reported a valid impression of the system to control at distance the evolution of the followed patients. All physicians involved in the demonstration are definitively in favor of the adoption of the H@H system. 89% of the patients report a very high satisfaction level, motivating their choice with the friendliness of the solution and the easiness to follow the therapy.
The complete success of the H@H technology test under medical control led to plan a clinical validation (with OPEX/CAPEX economical analysis), including 500 patients in the Italian Regional Tuscany Health System.
9. Conclusions
The technologies currently available allow for the provisioning of effective out-of-hospital telemonitoring strategies for chronic diseases, instead of the actual in-hospital-based follow-up procedure based on periodic visits. In this scenario the H@H system proposes an innovative home care model for the CHF patients based on a Bluetooth wireless sensors network equipped with software tools and communication technologies for remote acquisition, analysis, and secure transmission of the main vital signs. The final aim is to design an integrated platform to support the whole process of the patient treatment, connecting in-hospital care with out-of-hospital followup. The system was developed around an OP with a per-patient granularity allowing to generate a really meaningful database for every patient. The use of international standards for data exchange and the well-know communication protocols improves the interoperability, favoring the future integration of the platform with other HIS or sensors.
All metrics about usability, reliability, and robustness of the platform evaluated during the first technology assessment in a real medical scenario, with tens of patients affected by CHF disease NYHA classes III and IV, prove the effectiveness of the H@H telemonitoring system from both the patients and the caregivers’ point of view.
Acknowledgment
This work was supported by the Ambient Assisted Living Programme.