Designing an architecture for monitoring patients at home ontologies and web services for clinical...

896 IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 3, MAY 2014

Designing an Architecture for Monitoring Patientsat Home: Ontologies and Web Services for Clinical

and Technical Management IntegrationNelia Lasierra, Alvaro Alesanco, and Jose Garcıa, Member, IEEE

Abstract—This paper presents the design and implementation ofan architecture based on the combination of ontologies, rules, webservices, and the autonomic computing paradigm to manage datain home-based telemonitoring scenarios. The architecture includestwo layers: 1) a conceptual layer and 2) a data and communica-tion layer. On the one hand, the conceptual layer based on ontolo-gies is proposed to unify the management procedure and integrateincoming data from all the sources involved in the telemonitoringprocess. On the other hand, the data and communication layerbased on REST web service (WS) technologies is proposed to pro-vide practical backup to the use of the ontology, to provide a realimplementation of the tasks it describes and thus to provide ameans of exchanging data (support communication tasks). A casestudy regarding chronic obstructive pulmonary disease data mana-gement is presented in order to evaluate the efficiency of the ar-chitecture. This proposed ontology-based solution defines a flexi-ble and scalable architecture in order to address main challengespresented in home-based telemonitoring scenarios and thus pro-vide a means to integrate, unify, and transfer data supporting bothclinical and technical management tasks.

Index Terms—Home-based telemonitoring scenarios, manage-ment, ontologies, representational state transfer (REST), webservices.

NOMENCLATURE

COPD Chronic obstructive pulmonary disease.EM External manager.GUI Graphical user interface.HG Home gateway.HMAC Keyed-hash message authentication code.HOTMES Home ontology for integrated management in

home-based scenarios.HTTP Hypertext transfer protocol.HTTPS Hypertext transfer protocol secure.JSON JavaScript object notation.

Manuscript received September 23, 2012; revised January 3, 2013, April 14,2013, and July 24, 2013; accepted September 16, 2013. Date of publicationSeptember 24, 2013; date of current version May 1, 2014. This work was sup-ported under Project TIN-2011-23792 from the Spanish Ministry of Economyand Commerce (MINECO), in part by the European Regional DevelopmentFund, in part by the Aragon General Council (DGA), and in part by the Euro-pean Social Fund (ESF).

The authors are with the Communications Technologies Group (GTC).Aragon Institute of Engineering Research (I3A). University of Zaragoza,50009 Zaragoza, Spain (e-mail: [email protected]; [email protected];[email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/JBHI.2013.2283268

MAPE Monitor analyse plan execute.MD Medical device.OWL Web ontology language.RDF Resource description framework.REST Representational state transfer.SNMP Simple network management protocol.SOAP Simple object access protocol.SPARQL SPARQL protocol and RDF query language.SWRL Semantic web rule language.TS Telemonitoring server.URI Uniform resource identifier.WS Web service.XML Extensible markup language.

I. INTRODUCTION

PATIENT empowerment is considered as a philosophy ofhealth care based on the perspective that better outcomes

are achieved when patients become active participants in theirown health management. This new paradigm is a central ideain the European Union (EU) health strategy supported by in-ternational health organizations including the World HealthOrganization among others [1], and its effectiveness in yieldingquality of care is an obvious and essential area of research. Thisnew idea invites to look for new ways of providing healthcare,e.g., by using information and communications technologies. Inthis context, home-based telemonitoring systems can be usedas self-care management tools, while collaborative processesamong healthcare personnel and patients are maintained, thusthe patient’s safe control is guaranteed. Telemonitoring systemsface the problem of delivering medicine to the current growingpopulation with chronic conditions while at the same time co-vering the dimensions of quality of care and new paradigmssuch as empowerment can be supported. By periodically co-llecting patients’ themselves clinical data (located at their homesites) and transferring them to physicians located in remote sites,patient’s health status supervision and feedback provision arepossible. This type of telemedicine system guarantees patientcontrol while reducing costs and avoiding hospital overflows.These two sites (home site and healthcare site) comprised atypical home-based telemonitoring system. At home site, dataacquired by using MDs together with the patient’s feedback arecollected in a concentrator device (HG) used to evaluate and/ortransfer the acquired data outside the patient’s home if necessary.At the health-care site, a server device is used to manage in-formation from the home site as well as to manage and storethe patient’s monitoring guidelines defined by physicians (TS,

2168-2194 © 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications standards/publications/rights/index.html for more information.

LASIERRA et al.: DESIGNING AN ARCHITECTURE FOR MONITORING PATIENTS AT HOME 897

telemonitoring server). In fact, this telemonitoring process, andconsequently the evolution of the patient’s health status, is mana-ged through the indications or monitoring guidelines providedby physicians.

Although significant contributions have been made in thisfield in recent decades [2]–[11], telemedicine and in e-healthscenarios in general still pose numerous challenges that need tobe addressed by researchers in order to take maximum advan-tage of the benefits that these systems provide and to supporttheir long-term implementation. Interoperability and integrationare critical challenges that also need to be addressed when deve-loping monitoring systems in order to provide effective health-care and to make possible seamless communication among thedifferent heterogeneous health entities that participate in themonitoring process [3]–[11]. This integration should be addre-ssed at both end sites of the scenario but also in the commu-nication link, thus integrating the way of transferring and ex-changing information efficiently between them. In addition,providing personalized care services and taking into accountthe patient’s context have been identified as additional require-ments [12], [13]. Furthermore, apart from clinical data aspects,technical issues should be also addressed in this scenario. Tech-nical management of all the devices that comprise the telemoni-toring scenario (e.g., the MDs and HG) is an important task thatmay or may not be integrated under the same architecture asclinical management. Hence, at this technical level, research isstill required to address these challenges. Consequently there isa need for the development of new telemonitoring architectures.

Great efforts have been made in recent years in developingstandards to deal with interoperability at different points of thee-health communication infrastructure such as the ISO/IEEE11073 (X73) for MDs interoperability, the OpenEHR initiativefor storage, management and retrieval of electronic health record(EHR) information or as the standardized Health Level Seven7(HL7) messages to solve clinical data transferences [14]–[16].Nevertheless, additional efforts are required to enable themto work together and ultimately provide a higher level ofintegration.

Specifically, in this telemonitoring scenario, there is not aunique standard-based solution to address data and manage-ment integration. Since several standards can be used (some ofthem in combination with proprietary protocols or other stan-dards) at different points of this scenario, the interoperabilityproblem remains unsolved unless these standards would mergeinto one or alignments and combination of them would be done.According to Berges et al. [17], interoperability does not mean tohave a unique representation but a semantically acknowledgedequivalent one. That is the reason to propose in this study anontology-based architecture in order to provide with a commonknowledge about the exchanged data and the management ofsuch data. This ontology constitutes the knowledge equivalentone. Then, at both ends of the architecture other standards couldbe used for other managing purposes relating this model with thespecific desired approach. Using this alternative, a knowledgemodel is first provided that avoids alignment of models two bytwo, while all being related through the main ontology.

Ontologies-based solutions have been popularized over thepast few years. Ontologies provide a higher level of abstraction

and have been successfully used in telemonitoring scenariosand other areas to provide knowledge representation and se-mantic integration, thus a common understanding about dataexchanged by all the entities. Furthermore, its combination withrules allows providing personalized management services andthus personalized care [6], [18]. Although there are works thatdescribe the details of an ontology approach in this domain,they do not devote much attention to the architecture implemen-tation and the communication used to exchange the informationdescribed. Consequently, few works have given details about thispractical implementation of the ontology-based system whichmay be of interest for the development of other ontology-basedapplications in and outside the e-health domain.

This paper presents an ontology-driven architecture to inte-grate data management and enable its communication in a tele-monitoring scenario. It enables to not only integrate patient’sclinical data management but also technical data managementof all devices that are included in the scenario. The proposedarchitecture includes two layers: the conceptual layer (the on-tology) and the communication and data layer. The conceptuallayer uses the HOTMES and its extensions introduced in [19].Specifically, the OWL-DL language was selected to define thisontology model [20]. The second layer is based on WS tech-nologies. WSs have been successfully used in network manage-ment [21] and also in other works to exchange data modeledby an ontology such as [6] and [9]. However, our proposal,inspired on the representational state transfer (REST) style andbased on a generic communication method, provides a differentdesign approach that may be reusable for other systems basedon ontologies [22]. Furthermore, security issues have been con-sidered. The aim is to define a flexible and scalable architecturein order to address main challenges presented in home-basedtelemonitoring scenarios and thus provide a means to integrateand transfer data supporting both clinical and technical datamanagement.

The remainder of the paper is organized as follows. Section IIprovides a detailed background description of ontologies andREST(ful) web services. Section III discusses related work.Section IV presents the proposed architecture describing in de-tail main components and technical features of the involvedlayers. Section V describes a case study including tests per-formed. Finally, a discussion and the conclusions of the reportare summarized in Section VI.

II. ONTOLOGIES AND WEB SERVICES:BACKGROUND INFORMATION

A. Ontologies

According to one of the most widely accepted definitions ofontologies in computer science, an ontology can be describedas “an explicit and formal specification of a shared conceptua-lization” [23]. In simple words, ontologies represent conceptsand basic relationships for the purpose of comprehension ofa common knowledge area. To develop an ontology means toformalize a common view of a certain domain.

1) OWL Language: In computer science, there are plentyof formal languages that can be used to define and construct


ontologies. These languages allow encoding knowledge con-tained in an ontology in a simple and formal way. However, thestandardized RDF and OWL have been gaining popularity inthe semantic web world [20], [24]. An ontology can be formallydescribed in OWL using following basic elements: 1) classes;2) individuals; and 3) properties. These elements are used inorder to describe concepts, instances, or members of a classand relationships between individuals of two classes (objectproperties) or to link individuals with datatype values, respec-tively (datatype properties). Apart from these basic elementsOWL provides with class descriptors used to precisely describeOWL classes which includes properties restrictions (value andcardinality constraints), class axioms, properties axioms, andproperties over individuals.

2) Rules: Generally, ontology-based solutions combineknowledge presented in ontologies with dynamic knowledgepresented by the use of rules [6], [18]. A system based on theuse of rules usually contains a set of if-then rules (which indi-cate what should be done according to a situation) and a ruleengine used to apply them. By using rules, the behavior of in-dividuals can be expressed inside a domain. Hence, they can beused to generate new knowledge and can also be used to pro-vide personalized services. One of the most popular languagesfor rules definition is SWRL [25]. However, in our study, weused SPARQL to define some rules [26]. Although this is aquery language it can be used as a rule language by combiningCONSTRUCT clause and FILTER restrictions. On the one hand,the CONSTRUCT query form returns a single RDF graph builtbased on the results of matching with the graph pattern of thequery and by taking the specified graph template. On the otherhand, the FILTER clause can be used to restrict solutions tothose which the filter expression considers as TRUE. Only if thefilter function evaluates to true is the solution to be includedin the solution sequence. Note that although this language wasgood enough for our purpose, its limitations should be studiedfor other purposes (e.g., recursive tasks) and the adequacy ofSWRL could be studied for complex applications.

B. Web Services

Web services are used in this study as software technologyto access and exchange information modeled by the ontology.According to the W3C, a WS is a “software system designedto support interoperable machine-to-machine interaction over acommunication network” [27]. Systems may interact with theweb services by exchanging SOAP messages serialized in XMLfor its message format and sent over other application layerprotocols, usually HTTP. Although SOAP-based web servicesare the most popular types of WSs, there are other styles ofprogramming a WS such as the REST style.

1) Rest Style for Designing Web Services: REST is a style ofsoftware architecture for distributed hypermedia systems suchas the World Wide Web first defined in 2000 by Fielding. Thisstyle is based on the idea of transferring the representations ofresources, a resource being any item of interest. One of the keyadvantages of the REST architecture are scalability of compo-nents and generality of interfaces [22]. Although REST wasinitially described in the context of HTTP, this paradigm can

be applied to other protocols or implementations. Web servicescan also be described using this style. A WS implemented usingHTTP and the principles of REST architecture is designatedas REST(ful) WS [28]. Requests made from the client andresponses from the WS are used to transfer resources infor-mation. Each resource is identified through an URI. Statelessbehavior of data using XML and/or JSON and explicitly usedHTTP methods (PUT, GET, POST, DELETE) to exchange re-sources are the key characteristics of a REST(ful) WS.

One of the advantages of the REST WS is that SOAP packa-ges are avoided so the message payload is decreased. It is alsosimpler to be used. The REST(ful) WS use the HTTP proto-col directly in data exchange providing fast interactions. On theother hand, the advantages of SOAP-based architectures are thedefinition of complex methods and the use of other transportlayers apart from HTTP such as simple mail transfer protocol(SMTP). Both approaches have advantages and disadvantagesand it is up to developers to make a decision (see [29]). Specifi-cally in this study, the REST WS style was selected in orderto improve the flexibility and base the proposed architecture onexchanging elements of the ontology in a generic way (as re-sources). This resources-based communication allowed to reusethe communication structure to provide both clinical and techni-cal services and provides flexibility for future modifications ofthe ontology (being the communication methods independent onthe knowledge expressed in the ontology) or additional home-based services by means of new extension of the HOTMESontology.

III. RELATED WORK

Ontology definition has gained in importance in recent timesfor knowledge representation and semantic integration in manyareas including health care [6]–[11], [17], [19], [30]. Specifi-cally, a plethora of experiences have been reported in the lastdecade regarding ontologies usage for providing remote careassistance [6]–[10], [30]. They have been proposed as a so-lution to address interoperability and data integration. Goodexamples of ontology usage in the telemonitoring domain forspecific chronic patients’ supervision have been reported in [7]or [9]. However, there is a wide range of patients with differentchronic and multichronic conditions that can be monitored athome site. That is the reason other works have address per-sonalization issues and present a solution to monitor in generalany patient with a generic chronic disease. See for example the4KCare project [11], which offers a complete architecture toprovide remote telemonitoring services for chronic patients in-cluding ontologies for formalizing actors involved, care plansand diseases [8] or the Aingeru system [10]. Another example isERMHAN architecture [6], a context-aware architecture tosupport health information exchange and alerts managementfor continuous supervision of elderly at home. This studyoffers a flexible solution to provide personalized services by us-ing a set of predefined rules. However, while great solutions havebeen presented to address clinical challenges in the e-health sce-nario, few approaches have considered remote technical mana-gement [31] and its integration within the same architecture.As a matter of fact, this is one of the key differences of our


Fig. 1. General architecture proposal.

solution. Also, an interesting feature of our approach is thegeneral structure of the monitoring profiles described in ourHOTMES ontology. It contributes to achieve a clear solution ofhow to manage data at home site that can be reusable for othertypes of required management.

An additional difference and contribution of our study re-main at the data and communication level of the solution,where the development of a REST WS is proposed. This is ac-tually, together with the HOTMES ontology, a key element ofour architecture, to integrate technical management tasks. Al-though an ontology model would stay at the conceptual model ofsimilar reported solutions [6]–[8], [10], different technologiesare proposed to provide with the practical support of the commu-nication method based on the exchange of the information pre-sented in the ontology. For example, the experience presentedin [6] includes a J2EE application and web services technolo-gies based on SOAP messages exchange over HTTP to allowthe communication among distributed components of the ar-chitecture. Similarly, the work presented in [7] makes use ofSOAP messages and semantic web services. In contrast, ourarchitecture is based on REST(ful) web services. In combi-nation with our ontology, this approach provides three advan-tages to our architecture: 1) efficiency; 2) reusability to includeadditional features, e.g., technical management; 3) flexibility tomodify the ontology that governs the architecture. Since RESTis becoming more popular for the development of web servicesapplications and ontologies for knowledge representation, itscombination is presented as an interesting approach to enhancethe flexibility and reusability of developed solutions. Indeed, ithas been adopted by the National Center for Biomedical On-tologies (NCBO) to browse and manage available ontologies inthe BioPortal [32]. An additional example is EXPRESS [33].This tool is used to develop a REST(ful) WS to allow accessto the resources described in an ontology (classes, instances,and relationships). It simplifies the deployment process whileproviding an interface to access the resources described in anOWL ontology. This is an interesting contribution to the seman-tic web. Our solution offers a different approach. Since bothend-sites of the architecture that exchange information sharesthe same ontology, the elements that are described as resourcesare the OWL elements and not the entities described in theontology.

IV. GENERAL MANAGEMENT ARCHITECTURE DESCRIPTION

The ontology-based architecture proposed in this study hasbeen depicted in Fig. 1. This is divided into two layers: theconceptual and the data and communication layers. As shownin the figure, the conceptual layer deals with data representationand includes the ontology for interpreting the data transferredfor the communication of end sources of the architecture. Thedata and communication layer deals with data management andtransmission.

From a physical point of view, the telemonitoring systemcomprises the TS, placed in the health-care site, and severalHGs linked to it. The TS could be any device used to manageinformation provided by the different HG placed at home sites.Then, the communication between both end-sites is driven bythe pair WS (installed in the TS) and the web client (installedin the HG). In addition, two management modules in the TSand the HG are included in the data and communication layer.This architecture allows a communication over HTTPS and ithas been used to provide two types of services: 1) monitoringpatients with different types of chronic conditions, thus clinicalmanagement services and 2) providing remote management ofMDs and the HG, that is to say, technical management.

A. Layer Structure: Data Representationand Communication Method

1) Conceptual Layer: Both end sites of the telemonitoringscenario have to deal with heterogeneous information comingfrom different data sources. Although the same information isnot managed at both end sites, data provided by the differentsources are related given that these sources take part in the samemonitoring process (for technical or clinical purposes). Theidea proposed and implemented was to develop an ontology toclearly describe the managed data and explicitly describe in theontology how to manage such data. In this way, the developedontology represents shared knowledge in order to achieveintegration at both end sites of the architecture and also in theircommunication link. This conceptual layer includes both the on-tology and the definition of rules. In particular, rules are used incombination with the ontology to provide personalized services.

Note that the managed data described in the ontologydepends on the management service supported with the


Fig. 2. Main classes of the HOTMES ontology.

architecture. Consequently, first a generic ontology for describ-ing general management was designed and then two extensionsof the ontology were proposed to support each clinical and tech-nical application. This generic developed ontology was termedas HOTMES (the details of the ontology can be seen in [34]). Thetwo extensions were named as HOTMES clinical and HOTMEStechnical (see Fig. 2). More information about the HOTMESclinical ontology and its evaluation can be found in [35].

The HOTMES ontology provides a unified view of how tomonitor, control, and evaluate the managed information. In fact,the main idea of using the ontology is to provide a generic frame-work to define what has been termed as a management profile.The structure of the management profile was inspired from theautonomic computing initiative [36]. Autonomic systems areable to self-control their internal functions thanks to the auto-nomic element. This element implements a closed-control loopthat dictates the workflow of the system behavior also known asMAPE loop. Thus, a management profile includes four differenttasks: a monitoring task, an analysis task, a planning task, andan execution task (see Fig. 2). By using this idea, the HG is pro-vided with some level of autonomic behavior capability. Then, asdepicted in Fig. 2, each HOTMES extension provides with a uni-fied view of the managed data (clinical or technical). Dependingon the management profile content, an HG will be enabledto monitor its state or information provided by the differentsources (described within the instances of the monitoringtask included in the profile), analyze acquired information(according to the analysis tasks and the related rules), reactto abnormal findings, and inform about changes in its contex-tual environment (according to the planning and execution tasksconfigured within each profile). As shown in Fig. 2 two types ofmonitoring tasks can be defined (Polling or Event). Each ana-lysis task will be associated with a monitoring task and finally aplanning task (including a set of actions) will be activated accor-ding to the analysis result linked to it. To provide data integra-tion, each HOTMES extension describes within the monitoringtask the structure of the information that is of interest for man-agement purposes. Data provided by the different sources in-cluded in the managed scenario will be mapped into these classes

and transformed into ontology instances. In the case of technicalmanagement, an instance of the management profile could bedesigned to technically manage all the MDs that are linked tothe HG (and even its own technical features) providing persona-lized technical management for each specific HG. In the caseof a clinical application, an instance of the management profilecould be designed to remotely monitor and control clinical datafrom a patient. As shown in Fig. 2, environmental information,qualitative data, or vital-body measurements can be included tobe monitored in the profile.

Then, a set of rules should be provided together with themanagement profile in order to indicate when the analysis taskprovides with a positive or negative value (related to detectan abnormal finding) and when the planning task should beactivated (related to execute actions to correct the abnormalfinding).

2) Data and Communication Layer: In the data layer, thecommunication between the end sites is established using WStechnologies. Consequently, a WS has been designed to beplaced in the TS and also a web client to be installed in theHG (to establish a communication with the TS). This commu-nication allows the HG to ask for its associated managementprofile to the TS and to transmit acquired information from theHG to the TS.

A REST WS was developed in order to enhance the scala-bility and flexibility of the architecture and improve the per-formance (efficiency). This WS comprises and defines a setof operations over the following resources: an OWL ontology,the rules (transferred by means of an XML), OWL individuals(sent by the IndividualWS structure), properties datatype valuescorresponding to an individual (identified by the URI of theindividual and the URI of the property sent in a string generictype), and inform messages to provide some control functionsto the web pair communication. Each one of these resourceswas identified by an URI, and a set of operations was definedfor each particular resource using HTTP methods (e.g., GETor PUT). This WS interface allows information described inthe ontology to be exchanged in a generic manner. This is onekey that contributes to the reusability and easy extension of the


TABLE IRESOURCES AND METHODS DESCRIBED WITHIN THE WEB SERVICE

architecture. Described communication methods do not dependon the knowledge itself described in the ontology (related to theservice) but on the fact of using an ontology to represent suchknowledge. A summary of the resources and defined operationsis depicted in Table I.

As mentioned in the description of the converter module,individuals are exchanged by using a developed structure desig-nated as IndividualWS. Using OWL language, an individual ofthe ontology can be described as a member of a class with in-dividual axioms or facts as individual property values (datatypeand object properties). Our proposed structure for exchanginginformation permits individuals to be described, containing theinstance name (unique name assumption is considered), the URIof the class it belongs to, its list of data property values and therelations it has with other individuals of the ontology throughobject properties. Classes at the same level described in theontology have been marked as disjoint classes; hence, an indi-vidual cannot be a member of two classes at the same time. Asthe object properties link individuals to others individuals, thisobject structure allows individual definitions to be chained. Thisfact plays an important role in our architecture. By using thisstructure, the complete management profile can be transferredfrom the TS to the HG as an instance of the management profilechained to task instances through object properties. Not only isthe instance of interest transferred to the remote site, but also therelated information (object and datatype properties) required toput the transferred information completely into context. In thesame way, data acquired (and related context) at home site (HG)can be transmitted using the same structure and methods thanthe management profile.

B. System Modules: HG and TS Management Modules

Two management modules and web technology modulesinside the HG and the TS constitute the main parts of thetelemedicine system (see Fig. 1). The modules that comprisethe architecture have been developed using Java technologies.Specifically, the Jena framework (version 2.8.6) has been used toprocess the ontology and create new instances, data acquisition,and manipulation when the rules are applied [37]. Regardingthe web modules, Jersey v.1.12 was used to deploy both the WSand client program [38].

The components of the remote management module installedin the TS are depicted in Fig. 1. This management moduleincludes the following three components:

1) Ontology knowledge base module: This module con-tains the ontology knowledge models and the instances ofthe registered management profiles. The TDB triple-store

(version 0.87) has been used to store the ontology modeland new instances in this knowledge base module [39].

2) Converter module: The communication module of this ar-chitecture is mainly based on OWL instances exchangedgenerically by means of a developed object structurenamed IndividualWS. The converter module is used towrap and unwrap the individuals managed by Jena intothe IndividualWS structure used to exchange informationwith web clients. Furthermore, this module incorporatessome reasoning tasks. Ontology-based reasoning is usedin order to check instances before including new infor-mation in the model and to ensure the consistency of themodel.

3) Rules module: This module is used to store rules asso-ciated with each management profile. These rules are sub-sequently transferred by means of an XML file.

As shown in Fig. 1, an additional GUI is required in order tomake easier for EM, technical or clinical (physician), the processof defining the profiles and the rules. We are currently working inthe development of this GUI combining ontology visualizationtechniques and usability methods. The methodology used todesign this interface can be seen in [40].

The components of the management module installed in theHG are equally depicted in Fig. 1. This last management mo-dule has been designated the “Semantic Autonomic Agent.” Thismodule plays a key role in the architecture. It is in charge of in-tegrating incoming data and executing the management tasksdescribed in the management profile. The communicationbetween this agent and the management module installed atthe remote site is established through a web client connectionto the WS installed in the remote TS. The architecture of theagent comprises the ontology knowledge base module, the rulesmodule, the converter module, and the following modules.

1) MAPE module: This module constitutes the computingcore of the agent. It will be used to run the tasks specifiedin each management profile, hence to execute the closedloop from the MAPE loop process.

2) Integrator module: Information transferred by MDs andalso contextual data provided by patients will be acquiredin this module, which integrates data coming from diffe-rent data sources.

3) Reminders and alarms module: This module includesclock functionalities to ask patients about data (reminders)or to collect information from a specific software resource.

4) Actions module: This last module is used to execute ac-tions described within the execution tasks of the manage-ment profile if an abnormal finding occurs.


Fig 3. Workflow procedure (step 1: download MP).

As shown in Fig. 1, an additional GUI is required for users tointeract with the agent (integrator and reminders module). Thefirst version of this interface allows users to download the mana-gement profiles, visualize information regarding its content, vi-sualize active reminders, and visualize activated alarms bothfor technical and clinical management tasks. Note that severalclinical profiles for patients can be handled (if there are diffe-rent patients at home) but only one technical profile is expected.Additional work is expected in order to improve it in terms ofaccessibility and usability.

Some basic security measures have been included in this ar-chitecture for user authentication and to guarantee data integrityand reliability of exchanged data. First, to provide security inthe communication link, a TSLv1 protocol encryption layer withHTTP (or HTTPS) is used between the web ends points to securethe communication against eavesdroppers and thus provide con-fidentiality. Furthermore, a complete public-key infrastructurehas been deployed using both the server and the client X.509certificates for authentication. In addition, each client requestshould include an HMAC code value encoded in base64. Thiscryptographic code is calculated through the data that is to betransferred and using a cryptographic hash function (SHA-1in this implementation) in combination with a secret key (per-sonal for each user that holds a management profile). This codeprovides both data integrity and authenticity to the message.

C. Communication Flow and Workflow Performance

Figs. 3 and 4 depict the interaction among all the modules andsources involved in the management procedure. The first step(see Fig. 3) consists in the download of the management profile(patient profile or technical profile). First of all, an instance ofthe management profile should be configured by an EM placedat a remote site. Furthermore, a set of individual rules should beconfigured for each particular management purpose. As shownin Fig. 3, the designed GUI helps the physician with the ontologyinstantiation process and the rules definition. The outputs of

this interface (which uses selected classes of the ontology as anavigation tool) are a personalized management profile and aset of rules gathered in an XML file. Other functionalities suchas queries over acquired data or crossing data among patients totake some decisions could be of interest to be included in thistool.

The communication is always initiated by the user (web clientat HG). Through a connection to the web service, the user (thepatient in the telemonitoring scenario) situated at home site willacquire the required management profile. As shown in Fig. 3, ifthe user requests for an update of his/her management profile,then the version of the available profile at the TS will be re-quested for its evaluation (GET property value). When the userrequests a new management profile, first, it is checked whetherthe ontology to download it is available (GET ontology). Afterthat, the rules and the management profile will be downloadedwhen required. The methods involved are 1) GET (rules) and2) GET (individual). Note that the TLS authentication phaseis not depicted in Fig. 3, but it is initially carried out in orderto allow the web client connection to the web service. As de-picted in Fig. 3, the associated management profile is extractedfrom the ontology and the instances of the ontology managedby Jena are wrapped into the IndividualWS structure throughthe converter module. Once the management profile is in theHG, it will be processed into the converter module, unwrapped,and inserted as individuals managed by Jena in the ontology.Once the management profile has been included in the onto-logy knowledge base module of the HG, it will be evaluatedin the MAPE module and the management procedure will beperformed by running the tasks specified in the profile. An erroroccurring regarding the download process of the managementprofile will be notified to the user (e.g., incorrect identificationprofile-password match or network connection error) using apop-up alert in his/her GUI. The user will have to establish anew communication to ask for the management profile.

Data acquired from the data sources (e.g., MDs, sensors,HG characteristics, or user feedback) is integrated and then


Fig. 4. Workflow procedure (step 2: evaluate and transfer data).

evaluated in the MAPE module. This information is acquiredaccording to the monitoring tasks specified in the managementprofile. These data will be transferred to the HG by using theparticular format or protocol appropriate to each one. As de-picted in Fig. 4, data provided by the different sources includedin the managed scenario (e.g., users by means of the user’s GUIor MDs) will be mapped into the ontology model and thus trans-formed into ontology instances. These data may be transmittedto the remote site according to the specifications of the profile(PUT individual). Then, according to the analysis task descrip-tion included in the management profile, these monitored datawill be analyzed. This analysis will have a positive or negativeresult after the execution of the corresponding rules. This posi-tive or negative value will lead to the activation of a planningtask and consequently the execution of the actions required toface the detected problem (e.g., indicate the patient to repeata measurement or send an e-mail to the external manager). Asdepicted in Fig. 4, the activation of the analysis and planningtask will be conditioned by the associated rules. Data resultsfrom the analysis may be transmitted to the TS too. Data willbe stored at HG if the communication fails and will be retrans-mitted with later new data acquired. In addition, the user will bewarned about reported errors and will be indicated to contact theexternal manager if necessary. Note that different communica-tion channels are expected to be used to send important alarmsto physicians (e.g., e-mails or mobile messages).

V. CASE STUDY: COPD CLINICAL AND

TECHNICAL MANAGEMENT

In order to study the application and efficiency of this pro-posed architecture, two management profiles were designed re-garding clinical and technical management tasks for a COPDpatient [41]. An example of the tasks included in these pro-files is first provided. Then, two tests conducted to measure theefficiency of the architecture are presented.

A. Qualitative Costs Evaluation: Profile Example

COPD patients were identified as candidates to be monitoredat home sites. From a clinical point of view, it was an interes-ting case study (some estimations suggest that up to 10% ofthe European population suffers COPD). From a technical pointof view, the case of the COPD patient led to define a complextechnical management profile (because different MDs are re-quired to be used by the patient) and interesting option to testthe performance of the agent. Hence, one patient profile wasdesigned according to the clinical HOTMES ontology and onetechnical management profile was designed according to thetechnical HOTMES ontology. The patient profile includes therequired tasks to monitor a COPD patient such as controlling theFEV1 measurement in order to detect the presence and severityof the airway obstruction. It was configured by a primary carephysician by means of published clinical guidelines [35]. Thispatient profile included 15 monitoring task, 11 analysis task, 9planning task, and 3 execution task. This configuration led toinclude 144 new instances and to configure 18 rules. The de-tails of this profile and its evaluation to configure other type ofprofiles can be seen in [35].

The technical management profile was designed to monitorthe state of the MDs used by the COPD patient (weighing scale,a blood pressure monitor, a pulse-oximeter, and a glucometer)and the consumption of resources of the correspondent HG.These actions led to configure 13 monitoring tasks, 7 analysistasks, 7 planning tasks, and 2 execution tasks. In addition, 11rules were configured and 83 new instances were required tobe configured in the technical management profile. Additionalinformation of the application of the HOTMES ontology fortechnical tasks can be seen in [34].

Fig. 5 shows an example of the instances that should beincluded in this specific COPD patient profile in order to controlthe SpO2 (oxygen saturation) measurement. As depicted, first amonitoring task should be configured (1 MT), then an analysistask should be included to detect when this measurement is


Fig. 5. Example of a patient profile for monitoring SpO2.

TABLE IITEST1: EVALUATION PERFORMANCE RESULTS

under 90% (1AT), and then a plan should be configured in orderto execute two actions (warn both the patient and the physician)if this abnormal finding is detected (1PT, 2ET). The relatedrules that activate the analysis and the planning tasks have beenincluded in the figure.

B. Quantitative Cost Evaluation: Agent Efficiency

Two mapping modules were developed to integrate data trans-ferred from an MD and data collected from the HG resourcesusing SNMP. These modules were included as part of the inte-grator module. Hence, in our implementation, data (clinical andtechnical) from an MD was simulated to be transferred from anX73 manager like in [31] and technical data regarding the HGresources was transferred from an SNMP agent.

Two different tests were performed to evaluate the architec-ture. During the first one, actions related to the step 1 of theworkflow procedure (see Fig. 3) were evaluated. It means, forthe COPD profiles given in the case study, simulations of co-nnections and data transferences between the client and the WSwere carried out in order to download the COPD profiles and theassociated rules. The performance of the architecture was eva-luated in this test in terms of network cost and execution time.The network cost metric refers to the total amount of informa-tion that needs to be transmitted through the network betweentwo entities to perform an action. Traffic measurements weredone using RawCap and Wireshark software. Network usagecost was measured by gathering the total amount of exchangedkilobytes. The execution time refers to the time required bythe agent to insert each management profile thus the time spentin the converter module. Both the HG and TS managementmodules run in a 1.6 GHz i7 Intel Core running Windows 7machine. The results of this evaluation are shown in Table II.

Initially, the client downloads the OWL files of the ontologies(if they are not available yet). “Network cost Onto” depicts thenetwork cost that involves exchanging this information with

the remote site. Then, the agent asks for the correspondingmanagement profile and the rules (“Network cost MP and rulesfor both clinical and technical cases)”. Once in the client side,these profiles are examined in the converter module in order tocheck its correctness before inserting them into the HG databaseand start the evaluation of the tasks. “E. Time” indicates therequired time to execute this task.

The second test evaluated actions related to the step 2 ofthe workflow procedure (see Fig. 4). It consisted on runningboth the patient profile for a COPD patient and its technicalmanagement profile together (in the semantic autonomic agent).The agent was evaluated in terms of memory and computationalcost. Data from MDs and the HG were simulated in order toactivate the alarms specified in the management profile and thusdemonstrate the functionality of the MAPE module and thewhole semantic autonomic agent. Running the patient profileand the technical management profile together does not affectthe agent performance in terms of storage cost or network costas there are no dependences in the process of downloading themanagement profile and the rules are stored in different stores.Similarly, the execution time required in the converter modulewas not affected. In fact, running both profiles at the same timeonly affects the memory cost, and very slightly. The averagemaximum CPU observed was 0.9%.

During this second test, the efficiency of the semantic au-tonomic agent was evaluated. The execution time required tocompletely close the MAPE loop was also measured for all theconfigured tasks in the profile. During this process the followingtasks are done: 1) to configure a new instance of the acquireddata according to the ontology; 2) to process data according tothe analysis; 3) to extract and execute the rules (an average of 2or 3 rules are applied); and 4) to evaluate the plan and to executethe actions. All these actions are executed in an atomic manner.For instance, the mean execution time required to evaluate aSpO2 measurement (the task given in the example from Fig. 5)leading to the activation of an alarm was 4198 ± 12 ms. Discar-ding additional time invested by patients to provide feedback forsome measurements evaluation, there was no difference worthto mention regarding the required time in the MAPE module forthe evaluation of the rest of tasks included in the profile.

After the initial test period, all the events simulated (alarms)were detected by the agent and consequently the associated ac-tions were executed. Light improvements were introduced in theontology in terms of properties modifications to solve conflicts


regarding the activation of the rules. Note that actions includedin our tests involved only pop-up messages to the patient anddata transferences to the TS. Additional tests should be con-ducted to test the efficiency and effectiveness of the system formonitoring a patient in a real scenario. Modules to send e-mails,mobile messages, or sound alarms for patients could be includedin our architecture to enhance its effectiveness and improve itsfunctionalities to handle alarms.

VI. CONCLUSION

This study describes an architecture to enable data integra-tion and its management in an ontology-driven telemonito-ring solution implemented in home-based scenarios. This is aninnovative architecture that facilitates the integration of severalmanagement services at home sites using the same softwareengine. The architecture has been specifically studied to su-pport both technical and clinical services in the telemonitoringscenario, thus avoiding installing additional software for tech-nical purposes. In fact, it is oriented to supporting any extensionof the HOTMES ontology used at the conceptual layer to des-cribe a management profile. On the one hand, our ontology con-tributes to integrate data and its management offering benefitsin terms of knowledge representation, workflow organization,and self-management capabilities to the system. Its combinationwith rules allows providing personalized services. Note that thisapplication ontology could be in future improved by intro-ducing concepts from a domain ontology [42]. On the otherhand, the data and communication layer of the architecture,based on the REST WS, was oriented to minimizing the con-sumption of resources and providing reusable key ideas forfuture ontology-based architecture developments.

Our architecture is in line with other related solutions basedon WS technologies to exchange data [6], [9]. Nevertheless, thecommunication method proposed in this study enables us to goone step further as it is based on the exchange of generic OWLinstances, thus making the WS description of the knowledgeexpressed in the ontology independent. Note, that this commu-nication method could be easily reused in other implementationsbased on ontologies and no major changes would be requiredto include additional services based on the HOTMES ontologysuch as, for example, an environmental-sensor application. Bydeploying a WS in the data and communication layer indepen-dent from the information described in the ontology used forthe conceptual layer, a flexible and reusable architecture basedon ontology usage is achieved for the communication betweenthe end sites. This is a secure and scalable architecture with asimple communication method.

Both the design of the HOTMES ontology and the WS-communication method contribute to the scalability andreusability of the proposed ontology-based architecture. On theone hand, an additional extension could be done of the HOTMESonto-logy in order to monitor other type of data at home site,e.g., for sports and training purposes. In the same way, additionalinformation could be included in the HOTMES clinical or theHOTMES technical if required. As the communication methoddoes not depend on the content expressed in the ontology theseadditional uses of the HOTMES ontology would imply simple

modifications regarding the mapping modules used to integratedata at home site into the ontology-based system. The rest of thecommunication method would stay the same. Furthermore, thiscommunication method could be reused for other systems basedon the use of an ontology to represent the knowledge exchangedbetween several entities. On the other hand, the potential appli-cation and scalability of this architecture were demonstrated bystudying its application for managing and transferring clinicaland technical data for a COPD patient. The results showed usthat the architecture does not consume many resources. Lowbandwidth cost is required to transfer the management profileand its management results.

This solution represents a further step toward the possi-bility of establishing more effective home-based telemonito-ring systems and thus improving the remote care of patients withchronic diseases. As it was reported in [43], good telemedicineimplementations are developed after a process where thedynamic interaction among a combination of socio-technicaland also clinical factors is optimized. It means that additionalwork should be done (e.g., to measure the interaction of thepatient–doctor using the system and also the truthfulness of thesystem for a long period of time) before adopting this solutionin a real scenario. After its complete development, first, a con-cordance study should be conducted in order to determine itsclinical efficiency. Then, a social impact study should be con-ducted in order to determine how the system allowed improvingpatient’s quality of life. Regarding these last studies, the resultspresented in [44] evidence the benefits of telemonitoring sys-tems while linking their success to the usability design issuesand features. In addition, further research should be performedin order to integrate mature standards of healthcare with on-going ontology-based solution in order to achieve complete andend to end interoperable architectures in the e-health field.

REFERENCES

[1] WHO, World Health Organization. (last accessed 2013). [Online]. Avail-able: http://www.euro.who.int/en/home

[2] N. Maglaveras, I. Chouvarda, V. G. Koutkias, G. Gogou, I. Lekka, D.Goulis, A. Avramidis, C. Karvounis, G. Louridas, and E. A. Balas, “Thecitizen health system (CHS): A modular medical contact center providingquality telemedicine services,” IEEE Trans. Inf. Technol. Biomed, vol. 9,no. 3, pp. 353–362, Sep. 2005.

[3] I. Martinez et al., “Seamless integration of ISO/IEEE11073 personalhealth devices and ISO/EN13606 electronic health records into an end-to-end interoperable solution,” Telemed. J. E. Health, vol. 16, no. 10,pp. 993–1004, 2010.

[4] M. Figueredo and J. Dias, “Service oriented architecture to support real-time implementation of artifact detection in critical care monitoring,” inProc. IEEE. Annu. Int. Conf. Eng. Med. Biol. Soc., 2011, pp. 4925–4928.

[5] JD. Trigo, I. Martınez, A. Alesanco, A. Kollmann, J. Escayola, D. Hayn,G. Schreier, and J. Garcıa, “An integrated healthcare information systemfor end-to-end standardized exchange and homogeneous management ofdigital ECG formats,” IEEE Trans. Inf. Technol. Biomed., vol. 16, no. 4,pp. 518–529, Jul. 2012.

[6] F. Paganelli and D. Giuli, “An ontology-based system for context-awareand configurable services to support home-based continuous care,” IEEETrans. Inform. Tech. Biomed., vol. 15, no. 2, pp. 324–333, 2011.

[7] F. Latfi, B. Lefebvre, and C. Descheneaux, “Ontology-based managementof the telehealth smart home, dedicated to elderly in loss of cognitiveautonomy,” OWLED, vol. 2058, 2007.

[8] D. Riano, F. Real, J. A. Lopez-Vallverdu, F. Campana, S. Ercolani, P.Mecocci, R. Annicchiarico, and C. Caltagirone, “An ontology-based per-sonalization of health-care knowledge to support clinical decisions forchronically ill patients,” J. Biomed. Informat., vol. 45, no. 3, pp. 429–446,2012.


[9] V. F. S. Fook, S. C. Tay, M. Jayachandran, J. Biswas, and D. Zhang,“An Ontology-based context model in monitoring and handling agitationbehavior for persons with dementia,” presented at IEEE 4th Annu. Int.Conf. Pervasive Computing. Communications. Workshops, Pisa, Italy,2006.

[10] A. Tablado, A. Illarramendi, M. I. Bagues, J. Bermudez, and A. Goni,“An intelligent system for assisting elderly people,” in M.-S. Hacid, N. V.Murray, Z. W. Ras, and S. Tsumoto, Eds. in Proc. 15th Int. Symp. Found.Int. Syst., 2005, pp. 466–474.

[11] F. Campana, A. Moreno, D. Riano, and L. Varga, “K4Care: knowledge-based homecare e-services for an ageing Europe. chapter in book agenttechnology and e-health,” in Whitestain Series in Soft Agent Technolo-gies and Autonomic Computing. Switzerland: Birkhauser Basel, 2008,pp. 95–115.

[12] D. Zhang, Z. Yu, and C. Y. Chin, “Context-aware infrastructure for person-alized healthcare,” Stud. Health Technol. Informat., vol. 117, pp. 154–163,2005.

[13] N. Saranummi, “It applications for pervasive, personal, and personalizedhealth,” IEEE Trans. Inf. Tech. Biomed., vol. 12, no. 1, pp. 1–4, 2008.

[14] IEEE Standards Association. (2009). Personal Health Devices Standard(X73-PHD). Health Informatics. [P11073-104xx. Device Specializations][P11073-20601. Application Profile—Optimized Exchange Protocol],ISO/IEEE11073, 1st ed. [Online]. Available: http://standards.ieee.org/

[15] OpenEHR. (last accessed 2013). [Online]. Available:http://www.openehr.org/home.html

[16] HL7. Health Level Seven. Devices Special Interest Group. (last accessed2013). [Online]. Available: http://www.hl7.org/Special/committees/healthcaredevices/index.cfm

[17] I. Berges, J. Bermudez, and A. Illarramendi, “Towards semantic interop-erability of electronic health records,” IEEE Trans. Inf. Technol. Biomed.,vol. 16, no. 3, pp. 424–431, May 2012.

[18] J. E. Lopez de Vergara, V. A. Villagra, C. Fadon, J. M. Gonzalez,J. A. Lozano, and M. Alvarez-Campana, “An autonomic approach to of-fer services in OSGi-based home gateways,” Comput. Commun., vol. 31,no. 13, pp. 3049–3058, 2008.

[19] N. Lasierra, A. Alesanco, J. Garcıa, and D. O’Sullivan, “Data managementin home scenarios using an autonomic ontology-based approach,” in Proc.of the 9th IEEE Int. Conf. Pervasive Workshop on Manag. UbiquitousCommun. Services part of PerCom, 2012, pp. 94–99.

[20] M. K. Smith, C. Welthy, and D. L. McGuiness. OWL web Ontol-ogy language guide. W3C Recommendation. (2004). [Online] Available:http://www.w3.org/TR/owl-guide/

[21] G. Pavlou, P. Flegkas, S. Gouveris, and A. Liotta, “On management tech-nologies and the potential of web services,” IEEE Commun. Mag., vol. 42,no. 7, pp. 58–66, Jul. 2004.

[22] X. Feng, J. Shen, and Y. Fan, “REST: An alternative to RPC for Web ser-vices architecture,” in Proc.1st Int. Conf. Future Inf. Netw., 2009, pp. 14–17.

[23] R. Studer, V. R Benjamins, and D. Fensel, “Knowledge Engineering: Prin-ciples and methods,” Data Knowledge Eng., vol. 25, no. 1–2, pp. 161–197,Mar. 1998.

[24] O. Lasilla and R. Swick, Eds. Resource Description Framework (RDF)Model and Syntax Specification, W3C Recommendation. (2004). [Online].Available: http://www.w3.org/TR/REC-rdf-syntax

[25] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof,and M. Dean, “SWRL: A semantic web rule language combiningOWL and RuleML,” (2004). [Online]. Available: http://www.w3.org/Submission/SWRL/

[26] SPARQL Query Language for RDF. W3C Recommendation, (2008). [On-line]. Available: http://www.w3.org/TR/rdf-sparql-query/

[27] W3C Working Group. Web Services Architecture. (2004). [Online]. Avail-able: http://www.w3.org/TR/ws-arch/

[28] L. Richardson and S. Ruby, RESTful Web Services. Sebastopol, CA,USA: O’Reilly Media, 2007.

[29] G. Mulligan and D. Gracanin, “A comparison of SOAP and REST im-plementations of a service based interaction independence middlewareframework,” in Proc. Winter Simul. Conf., 2009, pp. 1423–1432.

[30] A. Valls, K. Gibert, D. Sanchez, and M. Batet, “Using ontologies forstructuring organizational knowledge in home care assistance,” Int. J.Med. Informat., vol. 79, no. 5, pp. 370–387, 2010.

[31] N. Lasierra, A. Alesanco, and J. Garcıa, “An SNMP based solution toenable remote ISO/IEEE 11073 technical management,” IEEE Trans. In-form. Tech. Biomed., vol. 16, no. 4, pp. 709–719, Jul. 2012.

[32] P. L. Whetzel, N. F. Noy, N. H. Shah, P. R. Alexander, C. Nyulas, T.Tudorache, and M. A. Musen, “BioPortal: Enhanced functionality via

new Web services from the National Center for Biomedical Ontology toaccess and use ontologies in software applications,” Nucleic Acids Res.,vol. 39, no. 2, pp. W541–W545, 2011.

[33] A. Alowisheq, D. E. Millard, and T. Tiropanis, “EXPRESS: EXPressingREstful semantic services using domain ontologies,” in The SemanticWeb-ISWC 2009. Berlin, Germany: Springer, 2011, pp. 941–948.

[34] N. Lasierra, A. Alesanco, D. O’Sullivan, and J. Garcıa, “An autonomicontology-based approach to manage information in home-based scenarios:From theory to practice,” Data and Knowledge Eng., pp. 185–205, 2013,doi: 10.1016/j.datak.2013.06.004.

[35] N. Lasierra, A. Alesanco, S. Guillen, and J. Garcıa, “A three stageontology-driven solution to provide personalized care to chronic patientsat home,” J. Biomed. Inform., vol. 46, pp. 516–529, 2013.

[36] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,”Computer, vol. 36, no. 1, pp. 41–50, 2003.

[37] Jena Framework. (last accessed 2013). [Online]. Available:http://jena.sourceforge.net/

[38] Jersey API. (last accessed 2013). [Online]. Available: http://jersey.java.net/

[39] TDB component for triple store. (last accessed 2013). [Online]. Available:http://openjena.org/TDB/

[40] N. Lasierra, A. Kushniruk, A. Alesanco, E. Borycki, and J. Garcıa, “Amethodological approach for designing a usable ontology-based GUI inhealthcare,” Stud. Health Technol Informat., vol. 192, pp. 1040–1040,2013.

[41] The Global Initiative for Chronic Obstructive Lung Disease (GOLD)Pocket Guide to COPD Diagnosis, Management, and Prevention, Revised2011.

[42] N. Guarino, “Formal ontology in information systems,” in Proc. 1st Int.Conf., 1998, vol. 46, pp. 3–15.

[43] R. L. Wears and M. Berg, “Computer technology and clinical work: Stillwaiting for Godot,” JAMA, vol. 293, no. 10, pp. 1261–1263, 2005.

[44] E. Seto, K. J. Leonard, J. A. Cafazzo, J. Barnsley, C. Masino, andH. J. Ross, “Mobile phone-based telemonitoring for heart failure man-agement: A randomized controlled trial,” J. Med. Internet Res., vol. 14,no. 1, 2012.

Nelia Lasierra received the M.S. degree in telecommunication engineeringfrom the University of Zaragoza, Zaragoza, Spain, the Master’s degree inbiomedical engineering from the Aragon Research Engineering Institute (I3A),and the Ph.D. degree (Honors), all from University of Zaragoza in 2007, 2009and 2012, respectively.

Her current research interests include telemedicine and e-health architec-tures, ontologies applications, semantic technologies, and network managementamong others.

Alvaro Alesanco received the Master’s degree in telecommunications engi-neering and the Ph.D. degree (Honors) from the University of Zaragoza (UZ),Zaragoza, Spain, in 2001 and 2007, respectively.

He is currently an Assistant Professor in the telematics engineering area inthe UZ, where he is a member of the Communications Technologies Group, I3A.His research interests include electrocardiogram and echocardiography videocoding and transmission in wireless e-health environments, network manage-ment, and other related topics.

Jose Garcıa (M’07) received the M.S. degree in physics and the Ph.D. degree(with Honors) from the University of Zaragoza (UZ), Zaragoza, Spain, in 1994and 1998, respectively.

He is a Professor in the telematics engineering area, UZ, and member of theI3A. He is also the founder and responsible for the Telemedicine research groupin the I3A. He has published more than 100-refereed international journal andconference papers. His research interests are in telemedicine, biomedical signalcoding and transmission, wireless communications, network management, andother related topics.

Designing an architecture for monitoring patients at home ontologies and web services for clinical...

Education

Transcript of Designing an architecture for monitoring patients at home ontologies and web services for clinical...