Available online at www.sciencedirect.com

Procedia Computer Science 00 (2015) 000–000www.elsevier.com/locate/procedia

19th International Conference on Knowledge Based and Intelligent Information and EngineeringSystems

A semantically-based framework for continuous u-health servicesprovisioning

Matıas Echeverrıaa, Angel Jimenez-Molinaa,∗, Sebastian A. Rıosa

aUniversity of Chile, Department of Industrial Engineering, Republica 701, Santiago, 8370439, Chile

Abstract

The need of having a more preventive, personalized and anticipatory healthcare for chronically ill patients entails a continuousprovisioning of health services everywhere, anytime and to anyone. The ubiquitous computing paradigm is an approach to realizethis vision. Nevertheless, the use of all potential ubiquitous health services and contextual information is quite limited in theliterature. To tackle this issue, this paper proposes a semantically-based framework for continuous ubiquitous services provisioning.Patients needs are represented in business processes. Also, this paper proposes a semantic description model of processes, services,as well as medical and environmental contextual information, in order to make it easier to select appropriate services out ofsemantically selected business processes. The suitability of the framework is evaluated through a case study for respiratory chronicdisease, by making use of real patient data and health professionals from a public pediatric hospital.c© 2015 The Authors. Published by Elsevier B.V.Peer-review under responsibility of KES International.

Keywords: Ubiquitous Health; Semantic Web; Context-Awareness; Ubiquitous Health Services; Business Process Management.

1. Introduction

Currently, chronic diseases represent a public health problem worldwide and constitute the majority of the costin health. According to the World Health Organization, chronic diseases are have long duration and generally withslow progression. In 2008 alone, 36 million people died from chronic disease worldwide. Unfortunately, the cost oftreatments for chronic diseases could reach up to 80% of the health budget in many countries1.

Several health systems from different countries have agreed on the need of tackling this challenge by the meansof a more preventive, personalized and anticipatory health service. This requires to encourage chronic patients andcaregivers to make them protagonists of their healthcare, assuming responsibility to keep themselves on controlledstates without collapsing health centers. This implies to realize the metaphor of a continuous healthcare provisioning,that is, providing healthcare everywhere, anytime and to anyone2.

The ubiquitous computing (UC) paradigm is an approach to realize this vision. Its principles entail to providethe right health services in an invisible, non burdening manner, and at the right moment. Continuous healthcare

∗ Corresponding author. Tel.: +56-2-2978-4053E-mail address: ajimenez@dii.uchile.cl

1877-0509 c© 2015 The Authors. Published by Elsevier B.V.Peer-review under responsibility of KES International.

2 Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000

provisioning faces the same challenges of UC, such as physicians that frequently move from hospital to hospital,patients that can be monitored regardless of their location, a huge amount of raw data generated by environmentalor bio-sensors, an increasing number of algorithms packaged as services able to anticipate patients conditions if theright information is at hand, among several other characteristics. Nevertheless, the use of all potential ubiquitoushealth (u-health) services and contextual information is quite limited in the literature of health services provisioning.Existing works use low-level context information, mainly raw data captured by bio-sensors. There is a need ofmaking autonomous decisions in accordance with ever-changing high-level context, allowing to select and activateautonomously and spontaneously various u-health business processes depending on the specific need that a patientmay has at a particular time.

To overcome these limitations, this paper proposes a semantically-based framework for continuous u-health ser-vices provisioning for chronically ill patients. This framework is patient-centric. That is, u-health services are pro-vided in the perspective of patients, rather than on a systemic perspective. This is realized by representing patientsneeds in business processes, and by defining a mechanism to map these processes to available u-health services. Thisis done by a three-level abstraction framework, which consists of a business process layer, a mediating layer composedof a set of coordinated activities, and the u-health service layer. This framework is supported by a semantic descriptionmodel of u-health business processes, activities, u-health services, medical context, and environmental context. Hav-ing such a semantic model makes it easier to instantiate applications based on contextual information. The reason isthat this kind of models enhances process and service developers to reuse and integrate a diversity of resources. Also,intelligent algorithms can personalize and adapt applications on top of the semantic model. In addition, we propose au-health business process selection mechanism on top of this model.

The benefits of this framework are as follows: (1) personalized, context-aware u-health service provisioning; (2)independence of heterogeneous sensor devices; (3) reusability of u-health services in diverse applications; (4) businessprocess oriented, which allows orchestrating several u-health services dynamically; (5) disease agnostic, which meansthat the semantic model and business processes can be grown to include knowledge, patients’ needs and u-healthservices for a variety of chronic ills.

The suitability of the framework is evaluated through a case study for respiratory chronic disease, by making useof real patient data and health professionals from a public pediatric hospital of Santiago, Chile. This study is aboutpredicting patient’s risk level, in order to anticipate crisis states. This is done by implementing into the frameworkan intelligent prediction model based on fuzzy reasoning, generating risk context out of vital signs data; allowing theframework to select appropriate u-health business processes based on the risk context, and mapping these processes tou-health services to meet patients’ needs. Also, we show a set of real u-health services we developed, which supportthe alerts management once a patient, his/her caregiver, and physician, have been notified of a potential crisis by theframework. We evaluate the usability of these u-health services allowing health professionals to interact with theservice functionality.

This paper is organized as follows. Section 2 introduces the related work. The architecture of the framework isdescribed in section 3. Section 4 depicts the semantic description model, and exemplify on the u-health businessprocesses and u-health services selection. The details of the framework implementation are explained in Section 5.Section 6 shows the evaluation of the framework in a real case study, while section 7 concludes the paper.

2. Related Work

The remote patient monitoring approach has been successful on realizing the ideal of continuous healthcare provi-sioning. It is defined as the continuous or frequent periodic measurement of physiological characteristics of a patient.This approach has also been useful to monitor patients with chronic diseases. The most common diseases that fall onthis category are, among others, cardiovascular disease; stress and depression; diabetes and hypertension; dementia;obesity problems and obstructive sleep apnea3,4,5. The main limitation is that these systems are designed and builtfrom a technical perspective, being isolated applications, each with a particular focus towards one or few diseases.Moreover, they are aimed to a specific group of patients, or a small community of people.

Recently, autonomous health services that incorporate artificial intelligence have appeared, like machine learning,to assist health professionals in the interpretation of medical data and decision making6. Such services implement

Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000 3

algorithms using data mining techniques over bio-sensors, such as clustering techniques applied to real and historicaldata, predicting real-time health status of a patient, or performing pre-diagnoses7.

The emergence of health services based on Web services allows easy access and proactive provisioning of healthinformation at any place and any time. This requires an integration of different technologies, systems and communica-tion infrastructure8. In this regard, the literature shows that these systems have tended to evolve to SOA architectures9.The settlement that is evidenced in SOA architectures on these systems has allowed the fact that, to promote interop-erability within healthcare organizations seeking to develop this approach, it has been generated a joint collaborationbetween Health Level Seven and Object Management Group, creating the organization Healthcare Services Specifica-tion Project. The aim of this joint effort is to produce SOA standards in healthcare that define the behavior of servicesand interfaces10.

The related work applying the principles of UC on this type of systems has proved been limited. Indeed, the term u-health service is used to identify the computational health services that are provided in UC environments11. Therefore,it is necessary to create a common platform where various services can be developed, sharing and reusing effectivelythe features and services in common. Han et al. propose an architecture that allows common characteristics to berecorded and reused during the development of u-health services12. The main categories supported by the proposedplatform are: obtaining and managing bio-data, biodata analysis, knowledge extraction and decision support.

A limitation of the frameworks that provide u-health services associated with bio-sensors or specific devices, isthat currently they are being developed in an ad hoc manner. Hence, if required to implement a new bio-sensor in anapplication-health service, it must be developed from scratch. Strictly speaking, u-health applications obtained fromspecific bio-sensors configuration, and their respective u-health services cannot be generated on-the-fly. This meansthat, given the inflexibility of existing frameworks, such applications cannot be obtained at runtime.

Among the few models based combining UC and SOA is the work of Giuli Paganelli et al.13, who propose anarchitecture based on context ontologies. The main components of this ontology are: location; patient physicaldata; activity; and social context. The system proposed by these authors is quite complete, they incorporate to theontology key aspects of the process, such as reasoning about the patient context, together with an appropriate policyfor preventive alerts. Following a similar approach, other authors have proposed ontologies for remote managementhealth systems and alert detection, which integrate explicitly in ontologies using data mining in conjunction withexpert judgment of physicians, but only setting general guidelines without achieving an explicit logic7. However, thebiggest problem is that current solutions use static association between health applications and u-health services. Thelimitation of this primary approach is that the provisioning of these services can only be made according to how theywere configured at design time.

3. Framework Architecture

The major elements of the framework consists of the context manager, the process manager, and a repositorysystem that supports these modules. The context manager is fed by signals generated by different types of sensorsthat capture physiological, environmental or location raw data. This data is processed by the raw data collector toelaborate low-level context. For instance, the raw data collector can classify the different types of data, or make simpledata fusion. In turn, this low-level context is processed by the the high-level context generator, which in accordancewith the nature of the received data, generates high-level context by activating different contextual services. Section6.2 exemplifies this process for two types of high-level contexts: patient’s risk level to fall into a crisis, and inaccuracyof a prediction model that assesses this risk level. In this framework we package such contextual services as RESTservices invoked by the business logic of the high-level context generator module.

The process manager is in charge of selecting the appropriate u-health business processes for certain high-levelcontext values. This is done by the context listener, properties matchmaker, semantic measurer and process selectormodules. The first consists of a event-based listener that subscribes to specific types of high-level contexts of thecontext manager. Then, the properties matchmaker module matches the context against the property values in theu-health business processes ontology, which is stored in a repository system and explained in Section 4.2.

Having selected an appropriate process, the process manager gets the process definition from the repository system.This definition consists of a BPEL file for each business process, which embeds its coordination logic making use of

4 Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000

Fig. 1. Architecture of the Semantically-based Framework for Continuous u-health Services Provisioning (Overview)

sequential, concurrent or iterative constructs, and different types of logical gateways, such as OR-split, OR-join,X-OR-split, AND-join, AND-split, etc.

The BPEL file is processed by the interpreter in the service engine. This module parses the file to extract theactivities that compose the process, and their information, such as input and output variables, pre-conditions andeffects variables, functional definition, URIs, and QoS parameters. Section 4.2.1 shows a simplified example of suchBPEL definition. This information is processed by the service query manager, which defines several abstract servicesto meet the activity requirements. Then, this module fires a query statement to the service discovery, in charge ofsearching for appropriate, available services in the u-health service ontology, in a similar fashion to the propertiesmatchmaker module. Once these services are discovered, the coordinator binds the services with activities of theprocess. Then, it sends a list of service operations arranged in accordance with the coordination logic embedded inthe process definition. Services are finally activated and ran by the executor.

The repository system has ontology and process definition managers. They have functions for storing, modifying,deleting and updating ontologies and definitions. In particular, process developers interact with the description man-ager to create and store newly generated u-health business processes, in the same way that the service developersinteract with the u-health service ontology manager.

4. Ontology-based Continuous Healthcare Framework

4.1. Semantic Description Model

As mentioned in Section 2 few work has been done on modeling the semantics that describes the multiple settingsof continuous u-health service provisioning. In this section we introduce the u-health business process semanticsdescription model, which is shown in Figure2. It embeds the contextual information involved on the u-health serviceprovisioning. For instance, it models the vital signs gathered from bio-sensors, patient’s health records, stakeholdersprofiles, environmental conditions, among several other aspects.

Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000 5

We model the context by the means of three aspects: medical, personal and environmental. The medical contextof a patient includes both the information from their medical records and vital signs measured at a specific time, aswell as the contingent risk level and symptoms at any given time. People is represented through the multiple roles andtheir profiles involved in the care settings, such as the patient, physicians, caregivers, nurses, secretaries, etc. Personalinformation is also available, which might be needed to contact caregivers of physicians; assign physicians; assess thesocial conditions of a patient, etc.

Since healthcare provisioning is framed in multiple physical settings, it is necessary to represent the environmentalcontext contingent characteristics that may affect the patient current and future status. For instance, the localization ofstakeholders is critical to identify whether the actual conditions a patient might be facing, the distance of a physicianor a caregiver in case of a medical emergency, or the closest and available nurse to assist a patient event, etc. Also,the actual level of temperature, humidity or luminosity of a place to infer the need of activating actuators to improvesuch conditions, in case environmental constraints have been previously defined for a patient.

These semantics aspects enable the definition of appropriate u-health business processes for multiple combinationsof ontology instances. Process modelers, assisted by medical expert knowledge, can built in advance these processeson top of this model. For instance, a process developer may build a business process to notify caregivers, physiciansor nurses about the risk level of a homecare patient, as well the required activities to manage their actions. Such aprocess is useful whenever the context manager infers, based on a predictive model, that a patient is in a high riskgiven his/her actual vital signs. Therefore, it is clear that this process needs to be added as an instance of the u-healthbusiness process ontology, taking into account, for instance, that the symbolic location, chronic ill, prediction model,risk level, among other properties, need to be set to patient bedroom, respiratory disease, fuzzy reasoning model,high-level risk respectively.

4.2. Semantically-based Process Selection Mechanism

The matching mechanism mentioned in Section 3 is computed by a SPARQL query statement, and consists ofidentifying the number of property values of the u-health business process ontology nodes that have a total or partialmatching against the values of the context, which generates different semantic matching values for different processes.Afterwards, the semantic measurer module ranks the processes in terms of this value. In case of having severalprocesses with the same value, this module determines their position in the u-health business process ontology, whichis hierarchically arranged based on subsumptions relationships among its nodes, and selects the most specializedsubclass. This step is explained in previous work14,15, and is out of the scope of this paper.

4.2.1. Business Process Sample: Notifying CaregiversWhenever the context consists of the patient’s risk level, the patient identifier and a specific pathology, the pro-

cess selector extracts those u-health business processes from the ontology whose supportRisk and supportPathologyproperties exactly matches the context. Since it might be a critical situation, we do not accept partial matching inthis example. The following selections were satisfactorily executed (ceteris paribus the pathology, which we assumeconstant):

• When the patient’s risk is no risk, any business process is selected.

• When the patient’s risk is low risk, the process selector extracts the processes labeled as notifying low risk tothe caregiver and providing basic care recommendations, among others. The former has a process definitionrepresented in a BPeL file that after being parsed by the activity extractor module its coordination logic con-sists of two sequential activities, getting the patient’s caregiver and getting the caregiver’s contact information,followed by a parallel construct with an OR-split gateway with three branches – sending SMS, sending e-mail,and a third branch composed of a sequence of getting the patient’s physician, getting physician’s secretary,and assigning phone call to secretary. The BPeL file defining the first activity states that its input consists ofa string with the patient’s identifier, and its output a string with the caregiver identifier. The REST servicesimplementing the getting the patient’s caregiver activity, consists of two sequential SPARQL queries, wherethe first one jointly matches the identifier and hasCareGiver properties of the patient ontology, and the secondone uses the obtained caregiver instance to apply a SPARQL query that matches its identifier property. In turn,

6 Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000

owl:u-healthBusinessProcess

owl:input owl:output

owl:activity

owl:precondition literal

owl:person

owl:patient owl:physician owl:caregiver

owl:secretary

owl:demographicInformation

owl:contactInformation

owl:medicalContext

owl:symptons

owl:healthRecords

owl:vitalSign

owl:pathology

owl:chronicIll

owl:predictionModel

double

owl:glucoMeterMeasurementowl:ecgMeasurement owl:oximeter

Measurement

owl:temperatureSensorMeasure

ment

owl:respiratorySensorMeasurement

owl:effect

BPELBPEL

owl:environmentalContext owl:location

owl:simbolicLocation

owl:outdoorLocation

owl:indoorLocation

owl:luminositySensorMeasurement

owl:environmentalCondition

owl:humiditySensorMeasurement

owl:riskLevel

1..1

hasProcessDefinition

hasExecutionPattern

supportBusinessProcess

0..n

0..nhasOutputhasInput0..n

0..1

hasEffect0..n

0..n

hasPrecondition

hasActivityDefinition

1..1

supportsEnvironmentalContext

0..n

is-ais-ais-a

subClassOf

hasCurrentCondition isLocatedAt

1..11..1

is-a is-a

is-a

supportsMedicalContext

0..n

isComposedOfHealthRecords

0..nhasPatology

is-a

is-a is-a is-a is-a

is-a is-ais-a

hasContactInformation

hasDemographicscurrentPredictionModel

hasAccuracy

isComposedOfSymptons

isComposedOfVitalSigns

isComposedOfCurrentRiskLevel

0..n 0..n 0..1

1..n

1..1

0..1

hasMedicalContext0..n

0..n0..n

{iterative, semi-automatic, context-based,...}

Medical & Personal Aspects

u-health Business Process Ontology

Spatial Aspect

Fig. 2. U-health Business Process Semantics Description Model (excerpt)

the second activity receives as input the caregiver identifier and produces as output an array of strings withthree spaces, where the first one represents the caregiver’s cellphone number, the second his/her e-mail, and thethird his/her fixed phone number. The REST service implementing the second activity is simply a SPARQLquery that matches the hasContactInformation property of the caregiver instance. The sending SMS activity isimplemented by using the Google Cloud Messaging Service. The rest of the coordination logic can be easilyfollowed. The following script is a simplified version of its definition in BPeL:

1< process >2 <sequence >3 < receive name="receive" partnerLink="processSelector"

4 operation="request" variable="request" initiate="yes" >5 < /receive >6 < invoke name="gettingPatientCaregiver" partnerLink="patient"

7 operation="getCaregiver" inputVariable="patientIdentifier"

8 outputVariable="careGiverIdentifier" >9 < /invoke >10 < invoke name="gettingCaregiverContactInformation" partnerLink="caregiver"

11 operation="getCaregiverContactInformation"

12 inputVariable="caregiverIdentifier"

Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000 7

13 outputVariable="careGiverContactInformation" >14 < /invoke >15 < flow >16 < invoke name="sendingSMS" partnerLink="caregiver"

17 operation="sendSMS" inputVariable="caregiverCellphoneNumber"

18 < /invoke >19 < invoke name="sendingEmail" partnerLink="caregiver"

20 operation="sendEmail" inputVariable="caregiverEmail" >21 < /invoke >22 < sequence >23 < invoke name="gettingPatientPhysician" partnerLink="patient"

24 operation="getPatientPhysician" inputVariable="patientIdentifier"

25 outputVariable="physicianIdentifier" >26 < /invoke >27 < invoke name="gettingPhysicianSecretary" partnerLink="physician"

28 operation="getPhysicianSecretary"

29 inputVariable="physicianIdentifier"

30 outputVariable="secretaryIdentifier" >31 < /invoke >32 < invoke name="assignPhoneCallToSecretary" partnerLink="secretary"

33 operation="setPhoneCallToSecretary"

34 inputVariable="secretaryIdentifier" >35 < /invoke >36 < /sequence >37 < /flow >38 < /sequence >39< /process >

• Analogously, when the patient’s risk is moderate risk or high risk the process selector extracts the processlabeled as notifying medium/high risk to caregiver and physician among other business processes. The onlydifference of this process is that both the caregiver and the physician are notified of the risk level of the patient.

5. Implementation

The framework is implemented in Java with the following support: (1) Protege to create OWL files; (2) BusinessProcess Execution Language (BPEL) to describe the process and activity definitions; (3) the Jena library to implementsemantic reasoning and assist with search queries from the loaded ontology model; (4) SPARQL as the query languageand a protocol to access OWL files, and (5) the My-SQL database management system to store patients’ data.

6. Case Study

6.1. Scenario Description

The suitability of the framework is evaluated through a case study for respiratory chronic disease, by making useof real patient data and health professionals from the “Exzequiel Gonzalez Cortez Pediatric Hospital” (EGCPH), thebiggest public pediatric hospital in Santiago, Chile. This institution takes care of around 300,000 patients per year, themajority of them from a segment of the population that corresponds to the smaller income. One of the major problemsin Santiago are the respiratory diseases, aggravated to a great extent by the high air pollution of the city, speciallyduring autumn and winter seasons, when the number of cases of ill children of some type of respiratory disease hasan explosive increase. The EGCPH developed a innovative program called Invasive Ventilatory Support and NonInvasive Ventilatory Support. Both programs were developed to take care of children with chronicle diseases at their

8 Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000

Table 1. Fuzzy Reasoning Evaluation

before discharged C5 C4 C3 C2

No Risk 41,3% 50,5% 39,6% 18,3% 4,9%Low Risk 30,7% 36,7% 29,3% 23,8% 17,2%Moderate Risk 21,9% 11,9% 28,0% 36,5% 23,0%High Risk 6,1% 1,0% 3,2% 21,4% 54,9%

homes. These programs train children parents to be able to take their biometric signals, register this information, andto use several medical equipment. Besides, paramedics perform visits to the children in order to supervise them.

The scenario is about predicting patient’s risk level, in order to anticipate crisis states. This is done by implementinginto the framework an intelligent prediction model based on fuzzy reasoning, generating risk context out of vitalsigns data; allowing the framework to select appropriate u-health business processes based on the risk context, andmapping these processes to u-health services to meet patients’ needs. Also, we show a set of real u-health services wedeveloped, which support the alerts management once a patient, his/her caregiver, and physician, have been notified ofa potential crisis by the framework. We evaluate the usability of these u-health services allowing health professionalsto interact with the service functionality.

6.2. Generating High-Level Context: Patient’s Risk Level Assessment

This sections describes how the context manager generates high-level context through a contextual service thatpackages a fuzzy reasoning model, in charge of computing the patient’s risk level, in a REST service. In fact, theEGCPH physicians, supported by the existing medical literature, have defined that respiratory rate, heart rate, tem-perature and oxygen saturation are needed to assess the crisis risk level of this type of chronically ill patients at home.These vital signs are remotely monitored by a set of non-invasive bio-sensors, such as electrocardiograms, oximeters,thermometers, among others. We have configured a set of micro controllers to integrate and transmit the digital signalsof these devices to the hospital server, but their details are out of the scope of this paper.

The context manager periodically gathers the vital signs captured by the bio-sensors, and feeds the high-levelcontext generator (HLCG). Whenever the HLCG module receives vital signs, it triggers a SPARQL query to themedical context ontology, in order to get the prediction model instance predefined for the patient’s pathology. Theretrieved model runs with the measured vital signs to assess the patient’s contingent risk level (RL), with RL ∈{no risk, low risk,moderate or medium risk, high risk}. In this specific scenario the assessment is carried out by afuzzy reasoning model that embeds the expert knowledge elicited from the EGCPH physicians.

The generation of such a predictive model is carried out by physicians and analysts, who are supported by a semi-automatic business process selected by the process manager whenever the model does not achieve certain accuracylevel. That is, the model has turned obsolete or its parameters have to be adjusted. This process is described inSection 6.3.1. In this way, the patient’s risk level is a high-level context generated by the context manager, which istransmitted to the process manager. Afterwards, the process selector uses this newly generated high-level context toidentify a set of suitable, semantically matching business processes, as explained in Section 6.3

6.2.1. Fuzzy Reasoning Contextual Service EvaluationWe test the contextual service that implements the fuzzy reasoning model by using supervised vital signs from

this type of chronically ill patients, under authorization of the EGCPH’s ethical committee. This supervised data isgenerated by using the triage, which is the medical protocol to assign a risk index to patients. The triage has fivecategories: No risk (C5), patient can wait for attention (C4), patient with injuries that need immediate attention (C3),patient with sever injuries and no vital risk (C2), patient with vital risk (C1). We collect data of patients from eachstate (from C1 to C5) plus data from patients 48 hours before discharged from the hospital. The former are 1358records while the latter are 675.

In order to evaluate its correctness, we allow that the context manager gets each of the above records from a SQLdatabase iterativelly. As expected, it correctly triggers the HLCG module, which in turn executes the SPARQL query

Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000 9

to get the predictive model instance from the medical ontology. Previously, we had populated this ontology with thefuzzy reasoning model.

As shown in Table 1 the model performs with high accuracy in the C5 case, where we mark with no risk or lowrisk more than 87.2% of the patients marked as C5. Similarly for C4 we also mark with no risk or low risk about68.9%. At this point we need to mention that in some cases the personal in charge of the triage labels a patient onelevel below of his/her real category. That is, if the real category is C5 they put the patient in C4. This is specially truefor patients from C3 (real), which are placed in C2. Therefore, the database has a bias on each category. This can beseen examining the results from the column C2 in Table 1, where the algorithm detects 54.9% in high risk, but also23% as moderate risk or 17.2% with low risk.

In conclusion, the fuzzy reasoning model created by the developing a predictive model business process, resultsto be useful for this scenario. In fact, it predicts a huge proportion of true positive cases, while for physicians falsenegatives are not a problem. Of course, more work is needed to satisfy the false positives obtained for C1 and C2 pa-tients, which fortunately are very few. Moreover, we demonstrate that the context manager is able to generate suitablehigh-level context based on the bio-sensor data.

6.3. U-health Business Process and U-health Service Samples

6.3.1. Business Process Sample: Developing a Predictive ModelAs explained, the business process known as developing a predictive model, interleaves the actions carried out by

the analyst, such as parameter adjustment, and the Web services that are required to simulate variables and validate thecontextual service implemented by a fuzzy reasoning model. We develop this reasoning model (which was evaluatedin Section 6.2.1) by following the mentioned process. The first activity consists of defining by physicians a set ofspecific ranges of reference for different patient age segments, whether for respiratory or heart rates. These rangesrepresent the lower and upper bounds acceptable for these vital signs. Regardless of age, the normal temperature rangeis set in between 36 and 37,5 Celsius degrees, while the saturation (SAT) in between 90 and 93. Secondly, physiciansneed to develop a score scheme to characterize different states of the vital sings (see Table 2). For example, if thepatient only exhibit a high or low temperature, it is assigned a score of 1. However, if the patient shows a low heartrate, then it is assigned a score of 3.

Once the score schema is established, it is necessary to define the correspondence between combination of vitalsigns scores and the risk of a respiratory crisis (see Table 3). Therefore, the execution of this semi-automatic businessprocess can provide a risk assertion based on this information.

Finally, this knowledge is formalized in the form of functions, as shown in the equations (1)–(3). These equationsdefine three membership functions to denote high range (HR), normal range (NR) and low range (LR) of a variable.Afterwards, these equations are used as a fuzzy reasoning model, which is added to the prediction model ontology asa new instance for this type of patients.

RAi(x) =

0 if x < ci(di−x)(ci−di)

if ci ≤ x ≤ di

1 if x > di

(1)

RNi(x) =

0 if x < ai or x > di(x−ai)(bi−ai)

if ai ≤ x ≤ bi

1 if bi ≤ x ≤ ci(di−x)(di−ci)

if ci ≤ x ≤ di

(2)

RBi(x) =

0 if x > bi(bi−x)(bi−ai)

if ai ≤ x ≤ bi

1 if x < ai

(3)

10 Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000

Table 2. Score Table Deviation Health Indicators.

Score Scheme Biosignal State

1 Temp. High or Temp. Low2 High Heart Rate2 High Respiratory Rate2 SAT 90 − 93 (CR)2 SAT 94 − 95 (NCR)3 Low Heart Rate3 Low Respiratory Rate4 SAT 90 − 93 (NCR)5 SAT < 90

Table 3. Mapping Risk Level with Health Indicators.

Risk Level Chronic Respiratory Diseases (CR) Non-Chronic Diseases (NCR)

Low (2 − 3 points) Altered Heart Rate Altered Heart RateLow (2 − 3 points) Altered Respiratory Rate Altered Respiratory RateLow (2 − 3 points) SAT 90 − 93 SAT 94 − 95Medium (4 − 5 points) SAT 90 − 93 and ((HR) or (RR) altered) SAT 94 − 95 and ((HR) or (RR) altered)Medium (4 − 5 points) High HR and Altered RR High HR and Altered RRMedium (4 − 5 points) High RR and Altered HR High RR and Altered HRMedium (4 − 5 points) Altered Temperature and Low HR Altered Temperature and Low HRMedium (4 − 5 points) Altered Temperature and Low RR Altered Temperature and Low RRMedium (4 − 5 points) SAT 90 − 93High (≥ 6 points) Low (HR) and Low (RR) SAT 90 − 93 and ((HR) or (RR) altered)High (≥ 6 points) SAT < 90 Low HR and Low RRHigh (≥ 6 points) High HR and Low RR and Altered Temp High HR and Low RR and Altered TempHigh (≥ 6 points) High RR and Low HR and Altered Temp High RR and Low HR and Altered TempHigh (≥ 6 points) SAT < 90

6.3.2. Service Samples: Managing Alerts and Patient’s InformationAmong the multiple instances of the service ontology, we develop a set of services to support alerts and information

management of this case study. These services can be reused to support multiple activities and business processes.The following services might be triggered whenever a notification is issued to physicians:

• A service to display general information of patients and related issued alerts: patients’ general information,chronic diagnosis and data related to the last decompensation. This list is sorted by patients’ risk level. Besidesthis, healthcare professionals can see a list of generated alerts, as well as their status.

• A service to show an overview of a specific patient selected by a healthcare professional. This service displayspersonal data, baseline health indicators for each vital sign, initial diagnosis and previous crisis, among otherissues.

• A service to visualize several vital sign behaviors per patient. This service allows healthcare professionalsto identify the evolution of different indicators regarding a patient health. It has graphs to visualize the datatransmitted in the last period, for example, the last 24 hours. The relevant issue here is that the healthcareprofessional has all the necessary information to detect any anomalies regarding the patient health status.

• In case extra information is needed, a temporal analysis can be performed in any health indicator by choosing adate interval.

Also, we develop multiple mobile services that run in the Android platform to allow physicians to check informa-tion at real time. Figure 3 shows some of these services, which allow to manage alerts and health records.

U-health Service Evaluation. The usefulness and usability of these services are validated by a user study with healthprofessionals of the EGCPH. Three test cases of patients with the following ages are analyzed: two months, one year

Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000 11

c) d)

Fig. 3. Mobile Services to Manage Alerts and Health Records.

Table 4. Mobile Services Usability Results.

ID Item Average Score Confidence Interval (95%)

1 I find the services attractive 4.8 [4.61 - 5.00]2 The services are useful 4.8 [4.53 - 4.97]3 The services are easy to use 4.1 [3.73 - 4.40]4 The services allow to view relevant patient data 4.6 [4.25 - 4.87]5 The services allow to generate actions in a timely manner 4.4 [3.98 - 4.77]6 The services allow to visualize the information transmitted correctly 4.4 [4.02 - 4.73]7 The services generates adequate notifications based on patient risk 4.0 [3.69 - 4.31]8 I am satisfied with the services features 4.1 [3.73 - 4.40]9 The services display valuable information for decision making 4.3 [3.92 - 4.70]

General Evaluation from 1 a 7 6.2 [5.92 6.42]

with two months and eight years. The simulation is performed by using a web form, where vital signs are enteredthrough a tablet device. The mobile service GUIs are deployed on a smartphone.

This simulation is validated through a survey that uses a Likert scale of five levels. A total of 16 health professionalsare surveyed. The composition of the sample consists of 6% of nurses, 19% of physicians, and 75% of kinesiologists.Table 4 shows that every evaluated item has an average greater or equal to 4.0, indicating that users consider theservices as useful (100%), easy to use (81%) and contributing to trigger preventive actions in a timely manner (81%).In relation to preventive notifications, 63% agree that the services generate appropriate notifications regarding patientsrisk, and 19% strongly agree this.

We use the alpha Cronbach indicator as a proxy to assess the reliability of the sample. This indicator is based onthe following parameters: number of items, average covariance within the couple of items, and the variance of thetotal score. The alpha Cronbach of the sample has a value of 0.84, considering a total of 9 items and 16 people. Thisindicator shows good internal consistency of the sample, indicating that the results are quite reliable. Additionally weconduct a statistical analysis of the results to determine the confidence interval for each item with 95% of confidence.From Table 4 it can be seen that the best rated items correspond to usefulness (item 2) and attractiveness of the services(item 1). The worst evaluated item corresponds to the usability of the services (item 3), and notifications based onpatient risk. These results indicate that the main areas for improvement are related to the services’ GUI to facilitatenavigation within them, and how the information associated to the patient status is displayed. A correlation analysisis performed in order to provide insights about the features that users value most. Results show that items with highercorrelation with the overall assessment of the services are the item related to the generation of appropriate notificationsbased on patient risk (item 7, correlation 0.84) and the item regarding to the capacity to view relevant patient data(item 4, correlation 0.73).

12 Angel Jimenez-Molina et al. / Procedia Computer Science 00 (2015) 000–000

7. Conclusion

This paper proposes a semantically-based framework for continuous u-health services provisioning for chronicallyill patients. Their health needs are represented in business processes, which are mapped to available u-health services.Also, we define a semantic description model of u-health business processes, activities, u-health services, medicalcontext, and environmental context. In addition, we propose a u-health business process selection mechanism on topof this model.

As part of our future work we plan to extend the semantic model to include existing medical ontologies in theliterature, as well as apply our framework to more chronic diseases. Also, we plan to explore the possibility ofapplying an ontology evolving approach to allow an autonomous expansion of the semantic description model.

Acknowledgements

This work was supported by CONICYT - IDeA FONDEF programme, project code: CA13i-10300, and by CON-ICYT - FONDECYT programme, project code: 11130252. Also, authors would like to thank the continuous supportof “Instituto Sistemas Complejos de Ingenierıa” (ICM: P-05-004- F, CONICYT: FBO16).

References

1. Organization, W.H.. Innovative care for chronic conditions: building blocks for action: global report. 2002.2. B. Arnrich O. Mayora, J.B.G.T.. Pervasive healthcare: paving the way for a pervasive, user-centered and preventive healthcare model.

Methods Inf Med 2009;49(1):67 – 73. doi:10.3414/ME09-02-0044.3. Fortier P., V.B.. Development of a mobile cardiac wellness application and integrated wearable sensor suite. In: SENSORCOMM2011, The

Fifth International Conference on Sensor Technologies and Applications. 2011, p. 301–306.4. Gao, R.. A phone-based e-health system for osas and its energy issue. In: 2012 International Symposium on Information Technology in

Medicine and Education (ITME). IEEE; 2012, p. 682–686.5. F. Miao X. Miao, W.S., Li, Y.. Mobihealthcare system: Body sensor network based m-health system for healthcare application. E-Health

Telecommunication Systems and Networks 2012;1(1):12 – 18. doi:10.4236/etsn.2012.11003.6. Fotiadis, D.I., Likas, A., Protopappas, V.. Intelligent Patient Monitoring. John Wiley and Sons, Inc.; 1st ed.; 2006.7. Patil, D., Wadhai, V.M., Gund, M., Biyani, R., Andhalkar, S., Agrawal, B.. An adaptive parameter free data mining approach for

healthcare application. CoRR 2012;abs/1211.1788.8. Serhani, M.A., Benharref, A., Badidi, E.. Towards dynamic non-obtrusive health monitoring based on SOA and cloud. In: HIS. 2013, p.

125–136.9. Omar, W.M., Ahmad, B., Taleb-Bendiab, A., Karam, Y.. A software framework for open standard self-managing sensor overlay for web

services. In: Proceedings of the Seventh International Conference on Enterprise Information Systems. 2005, p. 72–81.10. Kawamoto K Honey A, R.K.. The hl7-omg healthcare services specification project: Motivation, methodology, and deliverables for enabling

a semantically interoperable service-oriented architecture for healthcare. Journal of the American Medical Informatics Association: JAMIA2009;16(6):1874 – 881. doi:10.1197/jamia.M3123.

11. Kim J., A.S.S.J..C.K.. U-health platform for health management service based on home health gateway. In: IT Convergence and Security.2012, p. 351–356.

12. Han D., K.I.. An evolvable mobile u-health platform. In: IEEE. 2009, .13. Paganelli, F., Giuli, D.. An ontology-based system for context-aware and configurable services to support home-based continuous care.

Information Technology in Biomedicine, IEEE Transactions on 2011;15(2):324–333. doi:10.1109/TITB.2010.2091649.14. Jimenez-Molina, A., Kim, J.S., Koo, H.M., Kang, B.S., Ko, I.Y.. A semantically-based task model and selection mechanism in ubiquitous

computing environments. In: Knowledge-Based and Intelligent Information and Engineering Systems. Springer Berlin Heidelberg; 2009, p.829–837.

15. Jimenez-Molina, A., Ko, I.Y.. Spontaneous task composition in urban computing environments based on social, spatial, and temporalaspects. Engineering Applications of Artificial Intelligence 2011;24(8):1446 – 1460. URL: http://www.sciencedirect.com/science/article/pii/S0952197611000881. doi:10.1016/j.engappai.2011.05.006.