Framework of sensor-based monitoring for pervasive patient care

Abstract

Sensor-based health systems can often become difficult to use, extend and sustain. The authors propose a framework for designing sensor-based health monitoring systems aiming to provide extensible and usable monitoring services in the scope of pervasive patient care. The authors’ approach relies on a distributed system for monitoring the patient health status anytime-anywhere and detecting potential health complications, for which healthcare professionals and patients are notified accordingly. Portable or wearable sensing devices measure the patient's physiological parameters, a smart mobile device collects and analyses the sensor data, a Medical Center system receives notifications on the detected health condition, and a Health Professional Platform is used by formal caregivers in order to review the patient condition and configure monitoring schemas. A Service-oriented architecture is utilised to provide extensible functional components and interoperable interactions among the diversified system components. The framework was applied within the REMOTE ambient-assisted living project in which a prototype system was developed, utilising Bluetooth to communicate with the sensors and Web services for data exchange. A scenario of using the REMOTE system and preliminary usability results show the applicability, usefulness and virtue of our approach.

1. Introduction

Chronic diseases are the primary cause of premature mortality and the overall disease burden worldwide [1]. In this context, significant research is being conducted toward the development of sensor-based health systems which can support the prognosis of health status deterioration and prevent complications, while maintaining patient well-being [2].

Portable and/or wearable sensor-based systems provide an opportunity of monitoring patients’ physiological parameters anytime and anywhere, e.g. at home or at work, during their everyday activities. Monitoring outcomes can then be remotely delivered to the health professionals (HPs), thus eliminating the necessity of frequent hospital visits, and enabling also the timely optimisation of treatment approaches based on individual responses [3].

Even though a plethora of sensor-based health monitoring systems have been proposed [4], their integration into clinical practice has been scarce, at least partly because these systems are proprietary, and difficult to use and extend. Healthcare faces complexities, technology is growing rapidly, and patients and HPs have preferences or requirements which can change significantly over time. Therefore, we consider the need to move to appropriate mechanisms handling the extensibility of such systems in the scope of continuity of care [5].

In this regard, we designed a sensor-based health monitoring framework toward the provision of pervasive care services to patients and HPs, the preliminary idea of which has been presented in [6]. The proposed framework is based on a smart mobile device which enables the interoperation with multiple physiological sensors based on the Bluetooth protocol. HPs are capable to configure monitoring schemas based on which they can track patient condition, detect changes in health status, and respond accordingly. The seamless communication among the system's services is achieved through the deployment of a service-oriented architecture (SOA) [7].

The outline of this paper is as follows: In Section 2, we describe the overall functionality supported in the framework, and in Section 3 we illustrate its architecture and refer to major design aspects to handle data representation and communication for the provision of usable, interoperable and extensible monitoring services. In Section 4 we show the applicability of our approach through the development of a prototype system, the presentation of an application scenario, and the demonstration of preliminary usability results. Finally, in Section 5 we discuss the contribution of this Letter, along with future work directions.

2. Framework overview

The architecture of the proposed framework is illustrated in Fig. 1. The patient is considered as a ‘consumer’ of personalised health services which are installed at a mobile device with networking and computational capabilities e.g. a smart phone. In this Letter, services are distinguished into two categories: (i) Reactive services, being initiated by patients reinforcing their empowerment and better self-management [8], and (ii) Proactive services, being initiated either by the system or by the HPs in an event-driven fashion, reinforcing patient guidance and safety (e.g. sensing of physiological parameters).

Fig. 1.

Architecture toward pervasive healthcare services provision for patients and HPs

Sensors in the patient environment monitor health parameters including the heart rate, activity, breathing rate, skin temperature, and blood pressure, which are represented as <sensor, value, time>. A smart phone (henceforth referred to as mobile base unit – MBU), communicates with the sensing devices through Bluetooth, within a body area network (BAN) with a typical star topology [9]. The MBU manages the sensed data (through processes for data aggregation, analysis, and storage), detects events (e.g. low heart rate), and appropriately communicates personalised notifications to the end-users, i.e. patients and HPs. Notifications are generated after processing the sensed data and aim to guide patients and HPs according to the detected health status, e.g. an alert sent to the HP as a result of low heart rate recommending to increase the frequency of the measurements or a message recommending the patient to be more active when low activity is detected.

The notifications can be communicated to patients, Medical Center (MC) operators, and HPs. MC operators evaluate patient's condition severity based on the monitoring outcome, and decide whether communication with the patient or the HP is needed (e.g. decide on whether a call to the patient or the doctor is necessary, forward an alert message to the doctor, etc.), thereby reducing some of the HPs’ work overload. HPs view notifications through their Internet-linked Health Professional Platform (HPP), which enables them to adapt the monitoring plan, i.e. define the pre-conditions for which notifications are triggered as described in detail in Section 3.2.

3. Architecture design

3.1. Architecture

The proposed architecture targets at the easy adaptation of any sensor-based and Internet-linked mobile health system to changing monitoring requirements. With this in mind, we designed the services provider platform (Fig. 1) in order to achieve: (i) effective machine-to-machine interactions among the diversified system components, i.e. MC, MBU, and HPP, (ii) extensibility and functional scalability for the provided services toward enabling the straightforward extension of the system's functionality, and (iii) interoperable communication with additional external services for independent living (e.g. applications for physical activity monitoring, diet, etc.).

We met the above-mentioned requirements by utilising a SOA which emphasizes on both interoperability and reuse of components through open Internet standards [7]. In this regard, the user data repositories store user, sensor, and notification data which is communicated to system components (such as the MBU) upon request, via structured communication interfaces. More specifically, Web services were formulated within the services provider platform, based on message delivery according to the simple object access protocol (http://www.w3.org/TR/soap/) (SOAP). Requesters are then enabled to call these services via communication interfaces built with the Web Service Description Language (http://www.w3.org/TR/wsdl/). The used Web services are semantically-enriched through an ontological framework which is extensively described in [10], enabling their automated discovery and invocation based on their particular inputs, outputs, and categorisation. Such an approach has been reported to facilitate interoperability and scalability [11].

3.2. Monitoring schemas

HPs are enabled to define and review schemas (plans) in order to monitor patient condition and detect possible health changes, during the system's run-time operation [12]. A monitoring schema is a personalised plan according to which the HP defines the sensing parameters within the HPP (e.g. blood pressure, heart rate, respiration rate, temperature, etc.), along with the symptoms or adverse drug events that require close monitoring, within event-action rules (Fig. 2). An event corresponds to a detected situation which is persistent over a specific time window (e.g. high heart rate, low blood pressure, etc.), and the action corresponds to a notification's forwarding (e.g. an alert message) to the MBU, the MC, or the HPP, to inform about the event and/or make suggestions for its proper handling. The notification message's content can be tailored according to the recipient's specific requirements. For example, a message may be triggered for a patient recommending him/her to stop performing any intense activity or exercise due to a detected event of high heart rate. Moreover, a message can be triggered for the automatic or semi-automatic (requesting first confirmation from the HP) system adaptation. For example, such an adaptation may lead to the change of event parameters, e.g. measurement thresholds or frequency sampling rate for action triggering, due to a detected event (e.g. the patient reported nausea/vomiting).

Fig. 2.

Event-action conceptual model within monitoring schema

In the current design, an event is represented with the generic format <input[], output, parameters[], severity>, and the starting time and duration additionally characterise an event instance. The input corresponds to the sensor(s) which invoked the event (e.g. the blood pressure monitor), output corresponds to an event characterisation (e.g. high heart rate), parameters are the reconfigurable variables required to generate the output (e.g. time windows over which derivative parameters such as min/max values are calculated, frequency of sensed data, etc.), and severity is the level of event significance as defined by the HP (captured e.g. in a scale 0–5, or indicated through a more detailed and dedicated coding scheme).

A typical event in patient monitoring is defined as an occasion where a raw sensor value or signal derivative, mean, minimum, or maximum value, etc., is above or below a defined threshold within a specific time window. In the same rationale, the monitoring of a specified symptom (e.g. headache) by the patient himself/herself can also be defined as an event, where the input can be the patient (considered as sensor), the output corresponds to the reported symptom, severity is related to the level of symptom significance considered by the patient, and the optional parameters correspond to the patient activity, location, symptom frequency, medication treatment parameters, etc. IF-THEN rules are currently applied in order to detect events and trigger actions.

3.3. Event severity

In our design an event can be characterised with one of the three states of severity according to the event's level of significance for the patient or the HP, namely; green state, indicating an event with no severity, orange state, corresponding to an event with low/medium severity, and red state, for an event with high severity.

The severity of a specific event is immutable, i.e. it cannot change over time; however, HPs are enabled to define in the monitoring schema two or more events of the same type (in terms of inputs and outputs) characterised with different severity states, since severity in medical conditions should not be regarded as a static feature [13]. In this sense, the determination of the event severity can depend on the duration or/and starting time of an event instance. For example, an event instance with duration of less than N seconds might be characterised with a green state, another event instance of the same type lasting for M > N seconds might be characterised with an orange state, and an event instance lasting for K > M seconds and starting e.g. after 10 p.m., might be characterised with a red state [14]. The event severity could also be dependent on additional parameters besides event instance duration and starting time as described in this Letter, such as the event frequency during a specified time window, ranges for measurement thresholds, etc.

3.4. Intra-BAN and extra-BAN communication actions

The personalised monitoring schemas are utilised through a system module residing within the MBU which monitors the received sensor data in the BAN according to the defined events, receives the patient self-reports and forwards the actions to the MBU, as well as the HPP and the MC through the services provider platform. The HP is enabled to configure the triggering of one or more actions following the incidence of an event. For example, the sequence of actions depicted in Fig. 3 could be considered as a possible response strategy for handling the incidence of an event: (i) Alert message delivery to the patient through the MBU (for self-management), (ii) alert message delivery to the MC operator for patient triage, and (iii) alert message delivery to the HP through the HPP after phone calls from the MC operator to the patient and/or the HP. Such configurations can provide the ground for robust notification management in various health application scenarios.

Fig. 3.

Possible response strategy for handling an event

3.5. BAN interface

A BAN interface was developed based on the Bluetooth application programming interface (API) JSR-082 to add or remove sensors, in which the communication between the MBU and the sensors takes place in a request-response sequence. The interface supports the communication with Bluetooth devices after following a set of required steps, through which the communication is initialised, available Bluetooth services are discovered, and devices are finally connected according to sensor-specific actuating methods. To this end, following the request message by the MBU, sensed data can be enclosed into the response message and sent to the MBU, utilising the sensor-specific APIs.

3.6. Formalisation of information

The intra-BAN data communication is based on the standard XML (eXtensible Markup Language) scheme that is used to represent data and format messages [15]. This is due to the capability of XML to describe and query data effectively thanks to its flexibility. In particular, SensorML was utilised in order to model the BAN and its functions [16]. We chose SensorML because of its capability to model sensors’ static properties along with additional dynamically interacting processes.

The primary sections of SensorML description carry sensors’ metadata information, e.g. name, manufacturer, capabilities (e.g. possible sampling rates), and actuating processes (e.g. alert generation when an average value of measurements within a time window is over a predefined threshold). Information about the BAN resides in a SensorML document capturing all needed information about the used sensors, the MBU description and the actuating processes (such as patient health status reports and alerts), which is communicated to the HPP. In this respect, the BAN description contains all necessary information for the definition of monitoring plans by the HP.

4. Results

4.1. Application of framework in ambient-assisted living (AAL)

Our framework was applied in the REMOTE AAL project [17] targeted primarily at chronically-ill patients. A primary objective of the REMOTE system was to adopt an open reference architecture and platform enabling interoperation, smooth connectivity and effective content sharing among different services for supporting the patients’ independent living. We successfully integrated within the REMOTE system commercially available sensing devices, including: (i) a wearable multi-sensing chest belt for the continuous monitoring of activity, heart rate, posture, breathing rate, and skin temperature [Zephyr BioHarness (http://zephyranywhere.com/)), (ii) a blood pressure monitor, and (iii) a set of weighing scales (provided by A&D (http://www.aandd-eu.net/)].

We adopted the native security mechanisms of Bluetooth to protect the sensed data from possible intrusion or tampering. To this end, the MBU and the sensors mutually authenticate each other through key-based pairing in a supervised environment. As far as the quality of the sensed data is concerned, the embedded circuitry for worn detection as supported by the sensing devices was used to detect whether the user wears them properly, since this can be a common cause of noisy data.

A Web service was used in order to authenticate the patients and the HPs when using their applications. The user authentication was based on credentials, as provided by the MC operator during the user registration process within the MC. The Web service for authentication was utilised during user login in the system, as well as while accessing persisted information via other Web service operations (e.g. alert delivery Web service, vital signs delivery Web service, etc.), ensuring data confidentiality and protection of privacy.

4.2. Application scenario

Mrs Stewart has been diagnosed with bradycardia and her family doctor, Dr Papadopoulos recently assigned her to sensor-based remote health monitoring via the REMOTE system. The MC operator registers Mrs Stewart and her doctor to the administration service and Dr Papadopoulos is then enabled to define a monitoring plan for her (through the HPP). In particular, he decides to monitor her heart rate, blood pressure, and activity once every week for at least one hour and registers for this purpose the multi-sensing chest belt and a blood pressure monitor. He then sets a ‘low heart rate’ event as follows: First, he defines the input which is the heart rate sensor and the event characterisation or output (i.e. low heart rate). Then he defines the parameters of the event by setting the low and high thresholds of the average heart rate within a time window of 5 min (HRlow = 50, HRhigh = 150). Finally, he sets the severity of the defined event as ‘orange’, and ‘red’ when the event persists for 15 min or more. Finally he sets as an action, the display of a notification to the patient followed by the forwarding of a notification to the MC operator and himself. In the same manner, he defines a ‘low blood pressure’ event.

One day, a low heart rate is detected (HRaverage < 50 bpm in a time window of 5 min) and a notification with an orange severity state is displayed to the patient's mobile phone (Fig. 4). Mrs Stewart was told that in such a case she has to be calm and that the appearance of such notifications might be absolutely normal depending on her condition. A notification was then forwarded to the MC operator who called the patient to verify the problem. Mrs Stewart told the operator that she was feeling shortness of breath during the last hour, while she was sitting in her living-room, but she was not worried. The MC operator advised Mrs Stewart to visit her doctor and then forwarded a notification to him. Mrs Stewart reported the symptom she experienced (i.e. shortness of breath) on her mobile health diary. Upon reception of the notification, Dr Papadopoulos was then able to adapt the monitoring procedures to the actual patient status by introducing specific changes to the personalised monitoring schema. Therefore he decided to monitor the patient's condition every day, by changing the frequency of heart rate monitoring within the monitoring plan. Furthermore, in addition to the ‘low heart rate’ event, he set a ‘shortness of breath’ event and an action of notifying him immediately if ‘shortness of breath’ is logged in patient's diary. Consequently, a notification was sent to the patient that her monitoring plan has been changed and she should monitor her heart rate every day for at least an hour.

Fig. 4.

Vital signs monitoring with the multi-sensing chest belt (left) and low heart rate alert displayed to patient (right)

4.3. Experimental usability study

Patients would not be able to gain health benefits out of using any mobile health monitoring system, if they find such a system difficult to use and they are not properly engaged. The importance of usability studies in the design of human-centred health information systems has been widely reported [18]. In this context, a series of experimental evaluation sessions to systematically explore system usability took place for 3 days at the Pathology Clinic of Ippokrateio, General Hospital of Thessaloniki, Greece, with 53 chronically ill patients (Fig. 5).

Fig. 5.

Patient participating in the experimental usability study

The patients were enrolled in the study during their waiting in the clinic for scheduled check-up and the inclusion criteria for their participation were as follows: (i) be diagnosed with at least one chronic illness (hypertension, cardiovascular disease, Parkinson, diabetes, stroke, COPD, asthma, arthritis), (ii) be aware that they do not suffer from an allergy to sensor materials, (iii) not be diagnosed with a known mental disease, and (iv) provide their written consent for their participation.

23 of the participants were men and 30 were women with an average age of 62.4 years. Of the 53 patients, 68% (36), were diagnosed with more than one chronic condition. The most common diagnosis was hypertension (41% of the patients) and arthritis (38%). 58% of the patients (31) reported having no education degree, 28% (15) had a high school education, and 14% (7) had college education and above. Furthermore, 43% (23) of the participants were slightly familiar with using smart phone technology beyond calls, 38% (20) of them had no familiarity, while 19% (10) reported to be highly familiar. Following patient acceptance in participating in the study, the rationale of patient monitoring with wearable sensing devices and portable devices was explained to them, and the proposed system was demonstrated through the display of small video clips. The participants were additionally told that the system could be easily extended with additional sensors and applications according to changes on their health status and what their caregiver would need to monitor. Next, each participant was asked to perform a series of indicative yet indispensable tasks while interacting with the system (i.e., login, wear the chest belt according to provided instructions and view their measurements), and finally complete a questionnaire related to usability.

The success rate was used through the user-to-system interaction phase of the study in order to measure system effectiveness by calculating the percentage of successful completion of target tasks. The resulted success rate for patients was 77%. Subsequently, participants were given the system usability scale (SUS) questionnaire, enabling us to evaluate the perceived system usability [19]. The overall SUS score was 73%, which is above what is considered average (i.e. 68%). Success rate and SUS were chosen as usability metrics because they produce valid usability data [20] while they are easy to implement. The success rate and the SUS score indicated that patients, despite their age, did not encounter any major difficulties in using a sensor-based mobile health monitoring system.

5. Discussion

Advances in information and communication technologies have provided the ground for the design and construction of a plethora of pervasive health systems, the majority of which rely on the utilisation of sensing devices and smart mobile devices [2]. The adoption of personal health systems has emerged as a consequence of the necessity to ensure individualisation of healthcare, prevention and continuity of healthcare services, improve patients’ quality of life, and rationalise healthcare costs. The value of such systems has been illustrated in several studies [21] showing e.g. reduction in hospitalisation rates for chronically ill patients, increased adherence to therapy plans, higher patient self-efficacy and quality of life, etc.

The presented framework primarily targets at patients who need to be monitored closely, and they are willing to self-manage their condition, while maintaining their independent living during daily activities. In this respect, architectural features such as a SOA, monitoring plan definition by the HP, and addition/removal of sensors through an interface, were implemented toward the development of tailored and sustainable sensor-based health systems.

SensorML was used for data representation to describe the sensors and all events occurring within patient's intra-BAN and extra-BAN, in order to achieve interoperability and enable extensibility which was a major concern of this framework. In this context the addition of a new Bluetooth-enabled sensor is supported through the following four steps: (i) Creation of a capabilities SensorML document, (ii) use of the BAN interface for device discovery, service discovery and message exchange according to the specific API provided by the sensor manufacturer, (iii) creation of a Web service for extra-BAN communications, and (iv) alignment of the Web service to the ontological framework to facilitate future service discovery by external requesters. Standards for the communication of medical devices could aid in the extensibility of our framework, and this would be associated with the willingness of sensor providers to adopt these standards.

The framework was shown to be applicable in AAL and an experimental study with chronic patients demonstrated its usability. Such usability studies conducted with a selected number of end-users are important to evaluate the usefulness and ease of use of extensible systems in the scope of continuity of care.

Frameworks for pervasive patient care based on sensing devices and extensible functional components have been illustrated in the literature. Storage and communication of healthcare information through cloud-based environments and SOA [22], semantically-enriched data models to handle heterogeneity of sensor data [23], and data-driven approaches for predictive patient monitoring [24], constitute areas which have been spotlighted. However, in the above frameworks the capability to define personalised monitoring schemas is missing, while the evaluation results mostly concern their technical feasibility and performance rather than usability as assessed by patients.

As a next step, we aim to evaluate the introduction of more elaborate events in the framework by combining multiple events and contextual information such as patient location and environmental conditions (e.g. the weather). In addition, the prioritisation of patients according to specific criteria, taking into account for example the patient's history, number of events and their severity, needs to be addressed to achieve effective patient triage. Finally, informal care roles (e.g. a patient's relative) could be incorporated within the extra-BAN communication loop in order to enhance the patient support on the incidence of potentially risky events.

6. Conclusion

In conclusion, a framework which is based on sensors and mobile devices to deliver pervasive patient care, was presented. Our approach took into account important design principles such as system extensibility, interoperability, and personalisation in order to capture architectural and functional features which could be useful toward the sustained use of remote health monitoring systems by both patients and HPs. Therefore, we believe that the framework can assist future designers and researchers in developing valuable systems for pervasive health in the scope of continuity of care.

7. Funding and declaration of interests

The research leading to the above results has been funded from the Ambient Assisted Living (AAL) Joint Programme under Grant Agreement no AAL-2008-1-147 – the REMOTE project.

8. Conflict of interest

None declared.

9. Acknowledgments

The research leading to the above results has been funded from the AAL Joint Programme under Grant Agreement no. AAL-2008-1-147 – the REMOTE project.