Notifications and alerts policies for the patients’ stress levels
Recent advances in ICT technologies have led to a new generation of systems and services with potentials to play very important role in the healthcare domain. Ubiquitous technologies and context-aware computing have drawn huge attention as they enable the delivery of personalized healthcare services at any time and any place. Context-awareness is a concept first described around the early 90s along with the introduction of ubiquitous computing (Weiser, 1991). It has emerged as the key concept in order to realize ubiquitous applications, encompassing several ICT technologies and supporting seamless integration of activities between communicating entities. The term context-awareness has received many definitions, which do not meet a consensus among researchers. It is a rather general concept that refers to the capability of a system to be aware of its physical and logical environment (i.e. its context) and to intelligently react according to this awareness (Dey & Abowd,1999).
Along with the introduction of these technologies in healthcare, the clinical practices are changing too, requiring healthcare professionals to collaborate across disciplines and organizational boundaries. Contemporary health systems provide a more protective (proactive self-care), reachable (i.e. at home, at work, while travelling abroad) and high-quality health advice and assistance. Modern healthcare services are available around the clock, seven days a week and systems with ubiquitous access are becoming indispensable. During the last decade ubiquitous technologies and context-awareness facilitated the design and development of many prototype systems and applications in the healthcare domain, addressing, among others, dementia (Bharucha, 2006), diabetes(Pentland, 2004), Parkinson (Sung et al., 2005) and physical fitness (Buttussi & Chittaro, 2008). Little effort has so far been put into the investigation of context-awareness as the enabling technology for assisting the treatment of anxiety disorders.
Anxiety disorders are a group of major psychiatric disorders, characterized by disproportional anxiety, compared with the stimulus which provoked the anxiety response. Anxiety is a natural physiological reaction that helps individuals to cope with situations that require increased level of performance (e.g. during exams). But, when anxiety becomes disproportionately excessive to the provoking stimulus and persistent, even in the absence of the corresponding stimulus, it can lead to specific anxiety disorders. They include several stress - related disorders, such as panic disorder with or without agoraphobia; agoraphobia with or without panic disorder; specific phobias, social phobia, posttraumatic stress disorders and acute stress disorders, among others. Anxiety disorders are associated with significant morbidity and are often chronic and resistant to treatment (Merikangas & Swanson, 2010). Their impact is huge both in personal level (e.g. low self-esteem and isolation) and social level (e.g. family problems and low productivity).
The chronic aspect of these disorders, as well as the high possibility of recurrence, indicate the need of a persistent monitoring of patients suffering from anxiety disorders. For instance, panic disorder has a high rate of recurrences, the presentation of which is a significant factor in the treatment decision’s procedure (Kessler et al., 2010) In addition, high stress level is not always worrying since many situations of increased stress are normal (e.g. professional meetings). All these suggest that patients suffering from anxiety disorders should be continuously monitored for disorders’ progress assessment, treatment evaluation and adjustment, stress level assessment and provision of proper medical assistance.
From a technological perspective, anxiety disorders’ treatment has been mainly addressed through teleconference (Himle et al., 2006) and virtual reality (Parsons& Rizzo, 2008; Wood et al., 2008), while other solutions include e-mail support (Andersson, 2009) and internet-based treatment (Shandley et al., 2008). Teleconference is mainly used when patients are not able or willing to visit the medical expert at his physical space. It saves patients from transportation costs and time but it provides only subjective data as these are given by the patient during the teleconference sessions. On the other hand, virtual reality approaches require co-existence of patients and medical experts at the same physical space, providing objective data for the patients’ medical condition. Virtual reality is mainly used for exposure-based therapies and aims at creating virtual environmental settings where the patients’ attitude is monitored.
Nevertheless, the aforementioned technological approaches are not used as means for persistent monitoring that anxiety disorders require. Towards this direction, we propose a context-aware tele-monitoring system, for patients diagnosed with anxiety disorders, which will provide persistent health monitoring services and additional support to therapists for decision making, assessment of treatment efficiency and treatment personalization to the needs of the individual. Since this system is not yet fully integrated, and therefore evaluated, its design is hypothetical. The main target of the proposed system is the provision of a comfortable and safe environment, for daily living and mobility of patients diagnosed with anxiety disorders. This is achieved through: (a) health tele-monitoring services for continuous assessment of patient condition and provision of feedback to authorized persons, and (b) self-help services assisting patients to identify and change the harmful and unhelpful attitudes that strengthen their disorders.
2. Context-aware computing in healthcare
Context-awareness in healthcare implies the capability of a system to adapt to changes in its environment and patient preferences in order to deliver personalized health-related services. The most fundamental contextual elements for medical context-aware systems are the physiological parameters, based on which the patient’s medical condition is assessed. The values of several contextual parameters (e.g. location) are further collected and the overall patient’s context is obtained. The final step is the service provision and personalization according to the identified context and the patient’s needs and preferences. Thus, in general terms, context is mainly used to achieve two goals: a) medical condition assessment and b) personalized healthcare services provision.
The first context-aware systems in healthcare are tracked in the beginning of the 2000-2010 decade focusing on professional work settings. Their target is to assist the daily tasks of the medical staff through seamless ICT services, supporting their direct and uninterrupted communication, as well as immediate access to medical data regardless of location and time. Characteristic examples of such systems include the Qos Dream platform (Mitchel et al., 2000), the “Hospital of the Future” prototype (Bardram, 2004) and the MobileWard prototype (Kjeldskov & Skov, 2007). The Qos Dream platform provides seamless context-sensitive communications, through strategically placed terminals at the emergency department of the Royal London Hospital, which can adapt to the user’s location. When a video call is requested by one clinician, the individual being called is located through appropriate tracking technologies and this call is put through to the terminal closest to him. The “Hospital of the Future” prototype includes a context-aware bed, a context-aware pill container and a context-aware Electronic Patient Record (EPR). The bed is able to identify who and what lies in its proximity displaying relevant medical information according to this context. The MobileWard prototype supports the daily morning procedure tasks of nurses providing patient lists and patient-related information based on their location and the time of the day.
Apart from the systems focusing in professional work environments, there have been developed several context-aware solutions for home-based healthcare provision. The context-aware systems focusing on providing healthcare services at home, aim at keeping patients’ autonomy, improving their quality of life and at the creation of a safe environment where patients are constantly monitored for abnormal situations, while being able to perform their daily activities. For example, in the context of the INHOME project (Korhonen et al., 2003), several technologies were developed for the management of the domestic environment and the enhancement of security and autonomy of elders living at their homes. Furthermore, the House_n project (Intille et al., 2004) deployed a proactive context-aware medical system that uses wearable biometric sensors and cameras, aiming at identifying potential symptoms of congestive heart failures. If the system identifies any abnormal symptoms (e.g. weight changes), it produces alerts and suggests interventions for minimizing the risk of a congestive heart failure occurrence.
A different category of context-aware systems in healthcare consists of the so called wearable systems. These systems provide persistent monitoring and healthcare service provision to patients while ensuring their mobility and independence. One of the major systems developed in this application area is the wearable system MIThril (Pentland, 2004) that offers the capability of collecting and processing real-time data provided by various sources, such as biosensors, accelerometers and Global Positioning System (GPS). These data are used to assess the patients’ medical condition based on which the system either delivers feedback and notifications to the patients or to other authorized people. Similarly, the wearable system LiveNet (Sung et al., 2005) is able to continuously monitor a wide range of physiological signals, through various wearable biosensors, together with the user's activity and context, developing a personalized, data-rich health profile of a patient over time. This profile is used to provide objective information to patients so as to promote better behavior, as well as to medical staff in order to evaluate the treatment progress. The LiveNet system is designed to support the monitoring of several disorders, such as epilepsy and depression.
3. Context-awareness and anxiety disorders
While context-awareness has been barely used in anxiety disorders, several factors indicate that its implementation has the potentials to offer an integrated and effective technological solution for the support of their treatment. The most important factor is that situations that provoke anxiety highly depend on specific attributes, such as location, noise, temperature, visibility, activity and time. These attributes form the context of a patient and determine the environmental situation a patient finds himself in. In addition, these attributes (i.e. the patient’s context) strongly affect the way anxiety is expressed, kind of presented symptoms and their tension and the duration of critical episodes. For this reason, we propose the use of context-awareness for the inference of various attributes related to anxiety disorders and their treatment support.
A common feature of the majority of the disorders being addressed by context-aware systems is that context itself does not affect any of their basic attributes, such as manifestation triggers and symptoms. It is simply used to assess the patients’ medical status and determine the appropriate actions to be performed in case of an emergency. On the contrary, when it comes for anxiety disorders, the patient’s context plays a very important role in a number of attributes directly related to these disorders, as mentioned above. The following example will illustrate this difference between anxiety and some other disorders. Let’s consider the following context: “Peter is at a bar with friends on Sunday”. If Peter suffers from diabetes, his location, or the day do not play any role in a potential critical episode. On the other hand, these contextual parameters may be strongly related with a critical episode if Peter suffers from anxiety disorders. For example, when Peter finds himself in a crowded place like a bar he may feel overstressed. Due to the above, the acquisition of semantically enriched contexts is required in order to create a rich knowledge base regarding stress-provoking situations, symptoms occurrence and other stress-related attributes.
Moreover, anxiety disorders have a really dynamic nature and require persistent and long-term monitoring in order to verify several attributes, such as symptoms and stress-provoking situations. For example, Generalized Anxiety Disorder (GAD) diagnostic criteria require persistent specific anxiety symptoms for at least 6 months while some disorders occur along with other mental or physical disorders (Brawman-Mintzer et al., 2007). This means that a collection and analysis of a series of contexts should be performed, aiming to provide efficient objective data to expertized medical staff in order to make a diagnosis and then establish, direct and adjust (if necessary) the offered treatment accordingly. To achieve this, two things are needed: a storage mechanism where the identified contexts will be kept and appropriate algorithms for their processing.
In summary, anxiety disorders raise two fundamental research and technological challenges in the implementation of context-awareness. First, the acquisition of semantically enriched contexts that will describe with the highest possible expressivity the situation a patient is or was. Second, the integration of a mechanism that will store and process the acquired patient contexts. One approach that addresses both challenges is the use of user profiles, which will actively participate in the context reasoning process and then store the acquired contexts for future process and analysis. Structure and content of these profiles is discussed in detail in Section 5.
3.1. Context information
Similarly to context-awareness, the term context has received numerous definitions that are most likely tailored to the specific research needs for which context is used. According to the most cited definition that provides an abstract view of this term, context is “any information that can be used to characterize the situation of entities (i.e. a person, a place or an object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves. Context is typically the location, identity and state of people, groups and computational and physical objects” (Dey & Abowd,1999).
One of the initial steps while designing context-aware systems is to identify the context parameters to be monitored. Concerning anxiety disorders, we consider six primary categories of the patient’s context, as illustrated in Fig. 1.
Location context captures the current location of a patient and correlates it (if possible) with a social arena (e.g. home, office, etc.). Specific locations may cause increased stress (e.g. office) while others may be more relaxing (e.g. home).
Environment context refers to physical conditions such as humidity, noise and luminance. These conditions are strongly related with stress as increased noise, temperature and luminance may result to increased stress.
Activity context describes the current task the patient performs. A sub-context of activity could be the patient’s role in the performed task. Some activities may be highly relaxing (e.g. hobbies), while others may be overstressing (e.g. social activities).
Social context provides information regarding the people interacting with the patient in a given patient context. These people have a strong influence in stress as the presence of family members and friends give the patient a feeling of safety making him less vulnerable to critical episodes.
Time context captures the day of the week and the time of the day. Time is highly correlated with stress, as specific points in time and/or specific days of the week may be associated with increased (e.g. morning hours) or decreased stress.
Identity context consists of three sub-contexts: personal context, stress context and symptoms context. Personal context contains the demographic data of the patient, while stress and symptoms context keep track of the patient’s stress level and symptoms respectively.
Identity context is used to assess the patient’s medical condition, as well as the way stress is expressed (through symptoms). All the other contexts are exploited for the creation of a rich knowledge base (i.e. patient profiles) that will associate context parameters with several disorder-related attributes. This knowledge will be used for the provision of self-help services to the patients (e.g. suggestions for improving their lifestyle) and several treatment supportive services to medical staff (e.g. stress-provoking situations pattern detection service (Panagiotakopoulos et al., 2010a)).
3.2. Context modeling
Context modeling is a key feature in context-aware systems in order to describe context information in a semantic level and obtain an interoperable representation of diverse data coming from heterogeneous sources. It provides context in a structured form for the development of intelligent services, where information is situation dependent. The fundamental role of context modeling is to describe the relationship between the vocabulary and the concept of knowledge in a domain.
Ontologies are widely used in ubiquitous computing environments and context-aware systems for the representation of context information. They provide a uniform representation of context data, a structured and semantically rich way to model a domain and enable rule-based context reasoning. They also facilitate knowledge reuse and sharing among system components and count classes, inheritance, relationships between classes and instances as some of their major components. Due to the above, we developed an ontology-based context model written in OWL (Ontology Web Language), which shows an increased expressivity against other ontology languages.
Based on the context classification illustrated in Fig.1, we considered the Patient Ontology, which is comprised of the following parts:
Person Ontology: it describes information of the personal context of the patient.
Medical Condition Ontology: it contains the values of the physiological parameters measured by biosensors that determine the stress level of the patient (an excerpt of the Medical Condition ontology is illustrated in Fig.2).
Symptoms Ontology: It describes the symptoms of a patient in defined stress levels.
Environmental Ontology: it represents information regarding time, location, activity, physical conditions and people interacting with the patient.
Social Ontology: Represents the members of the care provision chain as well as their context information (e.g. availability).
4. System architecture
From the architectural point of view the proposed system (Fig. 3) will be composed by three main parts, the Body Area Network (BAN), the Health Care Center (HCC) and the Network of Third Authorized People (NTAP). Each part is described in detail in the following subsections.
4.1. BodyAreaNetwork (BAN)
The BAN is located at the patient’s body and includes the following components:
Bio-sensors acquiring essential implicit information concerning the patient’s medical situation,
sensors acquiring essential context data,
The gateway is the core element of the proposed system and can be implemented on a personal digital assistant (PDA), cell phone, or home personal computer. It controls the sensor network handling the sensor registration (type and number of sensors), initialization (e.g., specify sampling frequency and mode of operation), customization (e.g., run user specific calibration or user-specific signal processing procedure upload) as well as the dynamical configuration of the sensor network according to the service’s needs. It also has the responsibility to communicate the acquired information to the HCC, as well as the actions that must be fulfilled by the system, so that the delivered service adapts to the context and the requirements of the patient. The BAN’s gateway encapsulates a variety of processes, such as:
data acquisition of the above mentioned heterogeneous sources,
local storing and communicating of the acquired data with the HCC,
local evaluation of the acquired data and deduction of the patient’s medical condition in case of interruption of the communication connection,
patients’ self-evaluation through a proper GUI (Graphical Unit Interface), as well as channelling of advices or commands from the HCC, and
determination of a group of events (within the BAN), which occurrence indicates the patient’s current medical condition.
4.2. HealthCareCenter (HCC)
The HCC keeps the Electronic Medical Records (EMR) of registered users as well as their profiles. User profiles contain gateway related data, location related data, application specific data, user preferences, physician preferences, alerting thresholds of values regarding physiological data, user specific data and so on. The patient does not have any access to their profiles while the authorized physicians have full access and the opportunity to check the context history of the patients, forward new instructions to the patients (e.g. prescribed exercises) and alter the thresholds of the measured values that indicate some kind of anomaly. Patients interact with their profiles in an indirect manner, initially discussing with the respective physician, reaching to an agreement for the changes to be performed and authorizing the physician to make these changes.
Furthermore, the HCC performs a group of functions based on the information provided by the BAN’s gateway (e.g. context information) and the patients’ user profiles. More specifically, the functions performed at the HCC include context modeling, context reasoning and continuous patients’ medical condition assessment (normal state, increased stress state, emergency state, etc.). Moreover, it offers medical decision support mechanisms that process context and profile information in a proactive manner, to provide feedback both to patients and medical experts. Based on context and profile information, HCC also provides medical decision support mechanisms that facilitate reactive healthcare service execution in case of emergencies.
Finally, the Network of Third Authorized People (NTAP) is established at the HCC, where patients and medical staff collaborate to determine its members (medical staff belongs to NTAP as well). HCC also performstheprocessof selecting the appropriateNTAP members to be notified, based on the identified patient’s medical condition, his preferences and the NTAP members’ context (e.g. availability).
4.3. Network of Third Authorized People (NTAP)
The NTAP consists of several groups of people that form a caregiving support network providing both medical and social assistance. A single NTAP is established for each patient. This network includes an additional group of people (e.g. relatives) apart from expertized medical staff and paramedicals. These people are authorized to participate in the patient’s treatment process and are requested to play a specific and well-defined role according to the identified patient’s medical condition and the treatment guidelines set by the expertized medical staff (Panagiotakopoulos, 2010b). Potential members include relatives, close friends, co-workers and volunteers. Their role, training, capabilities, way of engagement and context information is described in their user profiles, parts of which are integrated in the patient’s profile.
5. Context-aware framework
This section presents the context-aware framework architecture that we have developed to offer the required functionality for the implementation of context-aware healthcare services for patients suffering from anxiety disorders. Furthermore, it provides further insight to some core functions of this framework, such as context processing, user profile structuring and event-based notification of NTAP members.
5.1. Framework architecture
The proposed framework architecture is depicted in Fig.4. The framework is deployed at the patient’s side, the HCC’s side and the NTAP’s side, consisting of several modules and components described in detail in the following sub sections.
The patient’s side includes the following modules and components implemented in the BAN’s gateway:
Context aggregation.It consists of two components, the Collector and the Scheduler. The Collector gathers all the context data from the context providers, pre-processes the collected data creating low level contexts and reasons about the redundant and the useful data. The Scheduler allocates corresponding timers and pointers triggering data acquisition.
Context reasoning. It consists of four components, the Rule manager, the Profile manager, the Knowledge base and the Context interpreter. The Rule manager is responsible of maintaining and updating subscribed rules and transforming them into rules that can be handled by the Context interpreter. The Profile managerdownloads, stores and keeps the patient’s user profile updated, in order to deliver it to the Context interpreter. The Knowledge base contains the ontology context models and instances, which are stored in a local database Based on ontology context instances, rules and profile information, the Context interpreterprovides the high level contexts interpreting the low level ones that come from the context aggregation module and assesses the patient’s medical condition, through rule-based reasoning techniques.
It has to be mentioned that this module is activated only when communication with HCC is unavailable and processes locally the collected context information. In this case, the reasoned high level contexts are then transmitted back to the Profile manager that sends them to the HCC (through the patient’s context and profile broker) when the communication is re-established for archiving purposes.
Context and profile broker.It essentially comprises the mediator between the HCC and the BAN’s gateway. It receives the patient’s profile and context reasoning rules from the HCC and provides them to the context reasoning module, while periodically checking their consistency. In case of connectivity problems it receives the reasoned high level contexts from the Profile manager and transmits them to the HCC when communication is re-established. Otherwise, it receives the context data from the Collector and transmits them to the HCC for further processing.
Notification and alert manager.It receives notifications (e.g. medication reminders) and alerts originated by the HCC and delivers them to patients.
PatientService manager. This component comprises the interface between patient and system. The patient may access and request the delivery of several patient-centric services, such as alerts and notifications management and self-help services. It includes a GUI where alerts, notifications and self-help services content are presented.
The following modules and components are part of the HCC’s side:
Patient-centric information management. It stores the patient’s EMR and user profile, NTAP’s members’ user profiles, as well as several policies regarding the notification and alert management and NTAP’s members’ selection process. It also has the responsibility to collect the patients’ reasoned contexts and store them for further processing.
Notifications and alerts manager. Based on the identified patient’s context, his inferred medical condition and specific policies, it determines potential notifications and alerts to be pushed to patients, as well as to NTAP’s members. It also initially defines the appropriate NTAP members that have to be notified and requests their context information through the HCC’s context and profile broker.
Context and profile broker. This module communicates both with the BAN’s gateway and the NTAP. Concerning the patient’s side, it provides user profile instances as well as context-related information (e.g. context reasoning rules, context acquisition scheduling etc.) to the BAN’s gateway, while it constantly (unless communication is broken) receives the collected context data. Regarding the NTAP it requests the collection of specific NTAP members’ context data through the HCC’s context and profile broker, which provides them to the NTAP member selection module.
Context reasoning. It performs exactly the same actions with the respective module located at the BAN’s gateway. It receives the context data from the HCC’s context and profile broker and provides the reasoned contexts back to it, in order to be archived in the patient’s user profile and used by other modules and components that lie at the HCC. It also provides the reasoned contexts to the notifications and alerts reasoner for the determination of the actions that have to be performed according to the identified high level context.
NTAP member selection.Based on information provided by the notification and alert reasoner, the identified NTAP members’ context information, and NTAP-related policies, it determines the appropriate member to be notified when assistive healthcare actions are required.
Service management. It hosts the service logic of the context-aware healthcare services, including patient-centric services (e.g. self-help services) and medical staff-centric services (e.g. user profile management and policies management).
Finally, the NTAP’s side includes the:
Context aggregation module. It is responsible for collecting the requested context information of the initially identified NTAP members and providing them to the HCC’s context and profile broker.
NTAP notification manager. It sends notifications to the selected NTAP members, along with information concerning the specific actions they have to perform.
The developed context-aware framework addresses the two challenges that anxiety disorders raise in the implementation of context-aware computing, as mentioned in Section 3. The context reasoning module actively engages user profiles in the context interpretation process aiming at producing semantically enhanced high level contexts. In addition, the patients’ reasoned contexts (including his medical condition while being at this context) are always archived in their respective user profiles. The archived contextual information is further processed through various data mining algorithms for the delivery of additional personalized treatment supportive services to medical staff. The kind of these services along with the potential algorithms for their implementation are out of scope of this study and are comprehensively presented in (Panagiotakopoulos et al., 2010a).
5.2. User profiling
Each patient has an individual user profile (patient profile), which contains information organized in distinct sections. The patient profiles are used as data storage mechanisms and as means of providing personalized healthcare services. They consist of various types of information summarized in the following list:
Disorder-related data (e.g. guidelines for providing medical care and conditions that cause reduced/increased levels of stress)
Context-related information (e.g. normal and abnormal values of measured physiological parameters, social arenas and scheduled activities)
NTAP-related data (e.g. list of persons, contact numbers and roles)
Preferences (e.g. hierarchies of notifications and alerts priorities in a NTAP group basis and service-related preferences)
Some of that information stored in the patient profile is quite static while other is rather dynamic as a user moves from place to place interacting with diverse entities. Personal information (i.e. demographic data and preferences) and medical history are predominantly static and defined at the patient profile creation. This information can be considered permanent in the sense that it does not change so often, and its attributes are not affected by external factors. The other types of information are highly dynamic, changing according to the patient’s context and treatment needs.
Similarly, each NTAP member has an individual user profile (NTAP member profile) that contains the following types of information:
Personal information (e.g. status and role)
Preferences (e.g. visual or sound alerts and notifications)
Context-related information (e.g. location and availability)
For the provision of timely-critical and accurate healthcare services, NTAP members need access to information hosted by patient profiles.However, patient profiles contain sensitive information which patients do not want to be accessible by everyone and especially by the people they do not know (e.g. volunteers). This leads to the need for degraded access to patient profiles. Therefore, NTAP members (e.g. paramedical staff) should have access only to those parts of the patient profile that provide the necessary information for the fulfilment of their role in the treatment process. For example, when a volunteer is called to provide his services, there is no need to access the patient’s preferences or the complete list of his demographic data, but has to receive knowledge upon disorder-related data and context-related information. Fig. 5 depicts the parts of the patient profile that each NTAP group has access to.
5.3. Context reasoning
The context reasoning process converts sensor readings to meaningful context information. Sensor readings are considered to be low level contexts, which on their own do not provide rich information on a semantic level. The processing of low level contexts by using the context ontology instances, several inferential rules and user profile information, produces the high level contexts. For instance, the values of physiological parameters, such as blood pressure, are considered low level contexts, while an alert of “critical medical condition” that may be deduced from the processing of these physiological parameters consists a high level context.
The proposed system addresses the need of high level contexts acquisition through a rule-based approach performed by the “Context reasoning” module (see Fig. 4). Several user-defined rules are used to reason about the patients’ medical condition, as well as the notifications and alerts that have to be triggered. Regarding the medical condition assessment, rule-based reasoning over the “Medical Condition Ontology” instances is performed. Due to the fact that the patients’ medical condition is tightly connected to the stress level they might present, we used a four valued scale to represent their medical condition through their stress level: low, medium, high and very high. For example, the following rule shows that if the heart rate frequency is higher than 50% and blood pressure is higher than 40% of their respective average values then the stress level is “very high”:
HRFavg is the average value of the heart rate frequency
BPavg is the average value of the blood pressure
When the patient’s stress level is assessed, the “Notifications and alerts manager” module (see Fig. 4) initiates a rule-based reasoning process to determine the actions that have to be performed based on the identified stress level. These actions consist of alerts and notifications that have to be sent at the appropriate NTAP members. The rules that determine whether an alert or a notification will be sent, as well as the respective NTAP recipients, are represented by specific policies, illustrated in Table 1.
|Stress level||Notifications and alerts policy|
|Medium||Notification to relatives|
|High||Notification to relatives and notification to paramedical staff|
|Very high||Alert to relatives and paramedical staff, notification to medical expert|
Examining the case where the stress level is “very high”, the actions that the system has to perform are the following:
First, it has to send alerts to the patient’s relatives along with information regarding his/her stress level.
Second, the paramedical staff is alerted, being responsible to communicate with the patients’ relatives to gain awareness of the incident. In order to do so, the system has to inform the alerted paramedical of the patients’ relatives engaged in the treatment procedure of the current incident. In addition, the system has to inform the paramedical whether a medical expert is available or not, in order to determine his/her further actions.
Third, the system has to notify the medical expert for the ongoing incident.
Apart from the deduction of their medical condition (i.e. stress level) that is constantly performed by the system, patients might request to receive alerts (self-help services) in case of abnormal environmental conditions (e.g. increased environmental temperature), in order to perform proactive actions. This would initiate a context-monitoring process, where rule-based reasoning is performed over the “Environmental Ontology” instances, to identify a potential abnormal situation and produce the respective alert messages. Alert messages are determined through specific policies (contained in patient profiles) similar to those presented in table 1.
5.4. NTAP’s members’ selection
The previous sub-section described the reasoning process that determines the NTAP members that have to be alerted or notified based on the identified stress level a patient presents. For instance, when the patient’s stress level is “Very high” the patients’ relatives have to be alerted. Nevertheless, alerting all of the relatives would be inconvenient as some of them might be engaged with important activities not wanting to be interrupted (e.g. professional meeting), while other might be unavailable to provide their assistance (e.g. enjoying a family trip). For this reason, a selection process must be performed to define the appropriate relative that has to be alerted.
The proposed framework uses rule-based reasoning over the “Social Ontology” instances to deduce the exact members that have to be alerted or notified. The selection process is performed by the “NTAP member selection” module (see Fig. 4), which utilizes the following information:
NTAP group that have to be alerted/notified
Availability the NTAP group’s members
Location of the NTAP group’s members
NTAP member selection policies
Continuing our example, the system has to select the appropriate relative that will be alerted. At first, the availability of each relative is checked. Next, the distance of each available relative from the patient is inferred by comparing their respective locations. Finally, according to the NTAP member selection policies (representing the rules), the appropriate relative is selected. The NTAP member selection policies may vary on a per patient basis. For example, one patient may designate a special relative who should be alerted regardless of location, unless he/she is unavailable. In this case, the system checks the availability of this relative and if he/she is available it immediately sends an alert without checking the availability and the location of the rest relatives. If this relative is unavailable, the system performs the selection process as described above to find an appropriate relative to be alerted.
5.5. Alerts and notifications subsystem
There are two modesthrough which NTAP membersinteract with the system (European Telecommunications Standards Institute [ETSI], 2009). In the first mode (polling mode), they can explicitly perform queries to get information about specific context information. The second mode (subscription mode) allows them to subscribe specifying what they are interested in receiving (e.g. patient’s medical condition). The subscription is followed by a notification which confirms the subscription and informs the NTAP members about the current value of the subscribed context information. After their subscription, the NTAP members are asynchronously notified about changes in the subscribed context information when these occur.
The mode of interaction depends on the application requirements for context distribution, as well as the nature and characteristics of the context information. Due to the fact that in the proposed context-aware system for anxiety disorders the context information is highly dynamic, the subscription mode is preferred,which reduces the overhead created by polling as well. The polling modeis usually used used when subscription is not supported or when the information is seldom variable.
To enable efficient and scalable content delivery to different NTAP members, and at the same time offer content filtering, we suggest the use of SIP (Session Initiating Protocol) and more specifically the SIP/SIMPLE protocol(SIP for Instant Messaging and Presence Leveraging Extensions) (Roach, 2002; Niemi, 2004). SIP is a simple, scalable, text-based protocol that offers a number of benefits including extensibility and provision for call/session control. In addition, SIP has been adopted by several organizations and is the foundation for session initiation for presence support in desktop, mobile and server platforms.SIP has been extended by IETF's SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) Working Group to enhance the basic protocol with Instant Messaging and Presence (IMP) functionalities. The SIMPLE extensions to the SIP protocol enable it to exchange messages inside a SIP session and provide an event package mechanism for notification of presence information.
The alerts and notifications subsystem involves two types of users: publishers and subscribers. Publishers (patients) “offer” the content that is submitted to the service for the subsequent delivery to subscribers. Subscribers (NTAP members) define subscriptions that describe the type of content they are interested in receiving. The infrastructure enables publishers to publish the information through content provider (Presence SIP Server), and allows subscribers to declare interest in certain types of information(Devlic& Podnar, 2009).
The content provider stores the subscription (Fig. 6), checks if there is a publication to match it, and in the case of successful match it delivers the published content to the subscribed user. The notification of the user can be synchronous or asynchronous.
6. Anxiety-related context-aware services
The proposed context-aware system is able to provide differentiated context-aware healthcare services both to patients and medical experts. These services are based either on the identification of the patient’s current context and execution of the respective reactive actions, or on the processing of a series of contexts stored in the patient profiles aiming to provide objective data for several disorder-related features. Concerning medical experts, offered services include, among others, lifestyle and habits pattern detection, context and stress level pattern detection and stress level prediction, which are comprehensively described in (Panagiotakopoulos et al., 2010a). Regarding patients, the proposed system provides several services focusing both on proactive and reactive aspects of anxiety disorders. The most important patient-oriented healthcare services are the self-evaluation service and the stress monitoring service.
The self-evaluation service offers patients the capability to check their stress levels within specific periods of time (e.g. one week) in specific environmental settings (e.g. at work). This way they receive an overview of the behavior of their stress at specific days and hours of a day and can try on their own to understand the exact situations that lead to increased or reduced stress levels. Next, they can experiment on alternative lifestyles and behavioral patterns evaluating their impact on their stress levels. Thus, patients become more familiar with their disorder by gaining knowledge on important features relative to its manifestation and are motivated to actively participate in their treatment process. In a similar way, patients have the ability to gain knowledge on the correlation of the symptoms that they suffer from and the stress level that has provoked them. This feature increases the patients’ self-awareness on the way that stress is physically expressed to them helping them identify increased stress level conditions (through specific symptoms manifestation) and perform the appropriate actions for its reduction.
Regarding the stress monitoring service, the patients’ stress level is constantly monitored for the execution of the appropriate actions with respect to their healthcare needs, as described in section 5.3. This service has a huge impact both for patients and their close environment (e.g. relatives and close friends). As for patients they feel safer to perform daily actions knowing that they will receive the required support whenever and wherever this will be needed. Concerning the members of a patient’s close environment, they do not have to always be in the same physical space with the patient for the provision of the appropriate healthcare assistance that dramatically limits their social activities. Having the ability to get informed of the patient’s medical condition either on demand, or whenever their intervention is needed without time and space restrictions, they ensure a better quality of life.
7. Conclusions and future work
This chapter presented a context-aware system for the support of patients suffering from anxiety disorders. The proposed system facilitates the persistent tele-monitoring of patients’ medical condition and administrates the collaboration of a network of third authorized people for the provision of timely-critical and accurate health assistance in case of emergencies. Based on the analysis of context information, it provides several healthcare services to patients for self-help purposes, as well as to medical experts for the selection, evaluation and adaptation of the offered treatment to the patients’ needs. The ultimate objectives are the creation of a safe and comfortable daily living environment for the patients and the better coordination and collaboration between caregivers in the treatment process.
Our research is now proceeding in several directions. We will examine several physiological signals to produce an optimum model that will assess the patients’ stress level as accurately as possible. Furthermore, we will introduce further adaptation capabilities by allowing patients to explicitly state their stress level estimations through an adaptive interactive interface located at the BAN’s gateway. This information will be considered for the optimization of the stress level assessment process through appropriate machine learning algorithms.
Moreover, we will focus on security and privacy issues regarding the patient profiles aiming to define specific policies that will determine the access rights of third authorized people according to various features, such as their roles. Finally, we will implement the SIP/SIMPLE based alerts and notifications subsystem and conduct an experimental evaluation of its performance.