iSEE:A Semantic Sensors Selection System for Healthcareltu.diva-portal.org/smash/get/diva2:1033985/FULLTEXT01.pdf · iSEE:A Semantic Sensors Selection System for Healthcare Jean Paul

iSEE:A Semantic Sensors Selection System for Healthcare

Jean Paul Bambanza

Computer Science and Engineering, masters level 2016

Luleå University of Technology Department of Computer Science, Electrical and Space Engineering

iSEE:A Semantic SensorsSelection System for Healthcare

Jean Paul Bambanza

Luleå University of TechnologyDept. of Computer Science, Electrical and Space Engineering

September 2016

ABSTRACT

The massive use of Internet-based connectivity of devices such as smartphones and sen-sors has led to the emergence of Internet of Things(IoT). Healthcare is one of the areasthat IoT-based applications deployment is becoming more successful. However, the de-ployment of IoT in healthcare faces one major challenge, the selection of IoT devicesby stakeholders (for example, patients, caregivers, health professionals and other gov-ernment agencies) given an amount of available IoT devices based on a disease(for ex-ample, Asthma) or various healthcare scenarios (for example, disease management, pre-vention and rehabilitation). Since healthcare stakeholders currently do not have enoughknowledge about IoT, the IoT devices selection process has to proceed in a way that itallows users to have more detailed information about IoT devices for example, Qual-ity of Service (QoS) parameters, cost, availability(manufacturer), device placement andassociated disease. To address this challenge, this thesis work proposes, develops andvalidates a novel Semantic sEnsor sElection system(iSEE) for healthcare. This thesisalso develops iSEE system prototype and Smart Healthcare Ontology(SHO). A Java ap-plication is built to allow users for querying our developed SHO in an efficient way.The iSEE system is evaluated based on query response time and the result-set for thequeries. Further, we evaluate SHO using Competency Questions(CQs). The conductedevaluations show that our iSEE system can be used efficiently to support stakeholderswithin the healthcare domain.

iii

AKNOWLEDGEMENT

This thesis work has been carried out at Luleå University of Technology(LTU), in Elec-trical and Space Engineering Department under the supervision of Dr Saguna Sagunaand Dr Karan Mitra. I highly acknowledge My supervisor Dr Saguna Saguna, and myco-supervisor Dr Karan Mitra for their excellent guidance, inspiration, motivation andconstant supervision throughout this research work. Their supervision was constructive,vibrant, and full of brilliant ideas. Sincere appreciations for their courage and commit-ment. I greatly thank the Swedish Institute(SI) and the government of Sweden for givingme the hectic opportunity to do my Master’s studies in such awesome country and ina great university with excellent education standards. I owe a deep sense of gratitudeto the staff and professors of Mobile Systems and Pervasive Computing program; theyhave given me a solid knowledge and exceptional practical experience in different fieldsof computer engineering. The knowledge that I acquired will be a valuable asset for myfuture career. Much dedications go as well to my dad and my siblings, especially EricBambanza, Emmanuel Bambanza, Sabin Mugabo, David Bambanza, Dusabe Nathalieand Marie-Josee Gikundiro; they always encouraged me to go forward. A special dedi-cation of this thesis work goes to my late mother; she left too earlier, but her guidance,love and advice through my childhood are the light of all things that I achieved so far.I also like to thank my classmate Haidar Chikh; it was nice to have him as a classmate.Finally and above all, I thank the Almighty God for his everlasting mercy, grace, andgoodness upon me.

Luleå, September 2016Jean Paul BAMBANZA

v

CONTENTS

CHAPTER 1 – INTRODUCTION 71.1 Thesis Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Research Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Thesis Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

CHAPTER 2 – BACKGROUND AND LITERATURE REVIEW 152.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2 Defining the Internet of Things(IoT) . . . . . . . . . . . . . . . 16

2.2 IoT for Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1 IoT-based Healthcare Applications . . . . . . . . . . . . . . . . 172.2.2 IoT Devices Used in Healthcare . . . . . . . . . . . . . . . . . 232.2.3 IoT Device Description . . . . . . . . . . . . . . . . . . . . . . 24

2.3 Interoperability as a Challenge . . . . . . . . . . . . . . . . . . . . . . 272.4 Semantic Web and Ontology . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.1 Ontology Interoperability . . . . . . . . . . . . . . . . . . . . . 312.4.2 Semantic Sensors Network Ontology . . . . . . . . . . . . . . 32

2.5 Related Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

CHAPTER 3 – SEMANTIC SENSORS SELECTION SYSTEM FOR HEALTH-CARE 363.1 iSEE System Architecture . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.1 User Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.2 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . 393.1.3 Ontology Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.4 Systems Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Smart Healthcare Ontology(SHO) . . . . . . . . . . . . . . . . . . . . 403.2.1 Disease Ontology . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.2 Extension of SSNO . . . . . . . . . . . . . . . . . . . . . . . . 433.2.3 Integrated Smart Healthcare Ontology(SHO) . . . . . . . . . . 46

3.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CHAPTER 4 – IMPLEMENTATION AND RESULTS 484.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2 Development Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.2 Apache Fuseki Jena . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 iSEE System Implementation . . . . . . . . . . . . . . . . . . . . . . . 494.3.1 SHO Implementation . . . . . . . . . . . . . . . . . . . . . . . 494.3.2 Prototype Implementation . . . . . . . . . . . . . . . . . . . . 53

4.4 iSEE System Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 564.4.1 Evaluation of SHO Correctness . . . . . . . . . . . . . . . . . 564.4.2 Prototype Evaluation . . . . . . . . . . . . . . . . . . . . . . . 61

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

CHAPTER 5 – CONCLUSION AND FUTURE WORK 675.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.1 Design Output Interpretation . . . . . . . . . . . . . . . . . . . 685.2.2 Objectives Fulfillment . . . . . . . . . . . . . . . . . . . . . . 685.2.3 Contribution to Practice . . . . . . . . . . . . . . . . . . . . . 685.2.4 Implication of Knowledge . . . . . . . . . . . . . . . . . . . . 69

5.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

APPENDIX A – TOOLS DEPLOYEMENT 70A.1 Protégé Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.2 Fuseki Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . 70

viii

List of Figures

1.1 Various Semantic Web standards and frameworks defined by W3C [1]. . 81.2 The description of the first scenario. A patient travels to a long distant

hospital regularly for further disease treatments. Thus, a doctor recom-mends him a smart healthcare technology for remote assistance. . . . . 10

2.1 High level picture of IoT applications in various areas[2]. . . . . . . . . 162.2 Example of remote chronic disease management. . . . . . . . . . . . . 182.3 Example of a pill box that allows patients to adhere to their medications[3] 192.4 Example of fitness activities tracking for diseases rehabilitation and

prevention[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Example of a typical Smart-home monitoring system[5]. . . . . . . . . 222.6 Some examples of IoT devices used in healthcare domain. . . . . . . . 242.7 IoT application layer competing protocols. . . . . . . . . . . . . . . . . 252.8 IoT competing protocol stacks. . . . . . . . . . . . . . . . . . . . . . . 262.9 The overview of the interoperability aspect in a smart city. The upper

part of the figure shows different smart city domains and the lower partpresents the smart city’ domains location. [6]. . . . . . . . . . . . . . . 28

2.10 Semantic web architecture [7]. . . . . . . . . . . . . . . . . . . . . . . 292.11 The SSNO, key concepts and relations, split by conceptual modules[8]. 332.12 The Stimulus-Sensor-Observation Pattern [8]. . . . . . . . . . . . . . . 343.1 iSEE System proposed Architecture. . . . . . . . . . . . . . . . . . . . 373.2 Screenshot of iSEE system User Interface. . . . . . . . . . . . . . . . . 383.3 Semantic Healthcare Ontology (SHO) as an extension of SSN ontology

for iSEE: Semantic sensors selection in healthcare. . . . . . . . . . . . 413.4 Typical disease meta-data. . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Smart Equipment class and its subclasses. . . . . . . . . . . . . . . . . 433.6 List of modeled sensors. . . . . . . . . . . . . . . . . . . . . . . . . . 443.7 Smart healthcare scenarios class and its Subclasses . . . . . . . . . . . 453.8 High level abstraction diagram for disease-device integration. . . . . . . 464.1 Tree view of classes in the SHO. . . . . . . . . . . . . . . . . . . . . . 514.2 Tree view of classes object properties in the SHO. . . . . . . . . . . . . 52

1

4.3 Some instances usage with hasDevices object property in the SHO. . . . 534.4 Sequence diagram of iSEE system components interaction. . . . . . . . 544.5 A typical User-iSEE System interaction. . . . . . . . . . . . . . . . . . 554.6 iSEE system disease entry point. . . . . . . . . . . . . . . . . . . . . . 624.7 iSEE system disease entry point(chart). . . . . . . . . . . . . . . . . . 634.8 iSEE system Smart healthcare scenarios entry point. . . . . . . . . . . . 644.9 iSEE system Smart healthcare scenarios entry point(chart). . . . . . . . 644.10 iSEE system Hospital Location entry point. . . . . . . . . . . . . . . . 654.11 iSEE system location entry point(chart). . . . . . . . . . . . . . . . . . 65

2

List of Tables

4.1 A LIST OF COMPETENCY QUESTIONS. . . . . . . . . . . . . . . . 574.2 A LIST OF QUERIES AND RESPONSES(1). . . . . . . . . . . . . . 584.3 A LIST OF QUERIES AND RESPONSES(2). . . . . . . . . . . . . . 59

3

List of Abbreviations

3G Third Generation of mobile telecommunication technology

6LoWPAN IPv6 over Low power Wireless Personal Area Networks

AI Artificial Intelligence

CoAP Constrained Application Protocol

CQs Competency Questions

DO Disease Ontology

DOID Disease Identification

ECG Electrocardiography

GPS Global Positioning System

GSM Global System for Mobile communications

HTTP Hypertext Transfer Protocol

ICD International Classification of Diseases

ICT Information and Communications Technology

IoT Internet of Things

iSEE Semantic sEnsor sElection System for Healthcare

Kbps kilobits per second

KR Knowledge Representation

LTU Luleå Tekniska Universitet

MeSH Medical Subject Headings

MQTT Message Queue Telemetry Transport

NCI National Cancer Institute

4

OEEC Organization for European Economic Co-operation

OWL Web Ontology Language

QoS Quality of Service

RDF Resource Description Framework

SHO Smart Healthcare Ontology

SPARQL SPARQL Protocol and RDF Query Language

SSNO Semantic Sensor Network Ontology

W3C World Wide Web Consortium

WHO World Health Organization

WiFi Wireless Fidelity

WWW World Wide Web

XML Extensible Markup Language

Xref Cross-reference

5

CHAPTER 1

Introduction

The massive use of Internet-based connectivity of devices such as smartphones andsensors has led to the emergence of Internet of Things(IoT). Healthcare is one of theareas that IoT-based applications deployment is becoming more successful. Accordingto Forbes, it is projected that by year 2020, IoT in healthcare area will be a $117 bil-lion market [9]. Practically, in healthcare IoT applications involve the use of connecteddevices to gather and analyse patients data to allow healthcare professionals to providefurther diagnosis and treatments. For example, the IoT for healthcare focuses on vari-ous applications such as chronic disease management [10], fitness and personal healthmanagement for disease management and prevention [11], and as well as care for theelderly population [12].

Nevertheless, that large-scale adoption of IoT devices in healthcare remains challeng-ing due to many issues, including the search and selection of IoT devices among theavailable number of IoT devices [13] based on particular medical-related criteria, forexample, a particular disease or disease symptoms. This challenge is worsened whenstakeholders(i.e, nurses, doctors, patients and other healthcare professionals) do nothave enough knowledge related to the IoT technology. That challenge clearly showsa need for a system that helps users for IoT devices search and selection among avail-able IoT-based healthcare devices. Since the primary intent of that application is toassist stakeholders to select IoT devices that are helpful for certain criteria(for example,disease), it is beneficial to add more information related to the selected devices. Theinformation that stakeholders need to know can be the description of the device, thecompatibility with an already existing system, i.e., the communication protocol, Qual-ity of Service (QoS) parameters, cost, manufacturer(availability), device placement andassociated disease.The expected system intends to assist patients, caregivers, health pro-

7

8 INTRODUCTION

fessionals and other government agencies health officers.

The interoperability is another challenge when considering to build a system that inte-grates two different domains(i.e. IoT and Healthcare) [14, 15]. To cope with that, the useof the Semantic Web is crucial. According to the World Wide Web Consortium(W3C),the Semantic Web provides the ability to share and reuse data across community bound-aries, enterprises, and applications. In 2001 Tim Barners-Lee, the director of W3C andthe creator of World Wide Web(WWW) published an article in Scientific American,suggesting a Semantic Web resulting out of the expanding WWW [16]. It aims to builda web of data, contrary to the principles of the current web; its primary intent is to pro-vide a standard format to enable the integration and combination of data drawn fromdiverse sources. Moreover, the Semantic Web defines a set of techniques(figure 1.1)and models proposed by W3C; such as Resource Description Framework(RDF), vari-ous data exchange formats including RDF/XML, Turtle and N-Triples. As well as theannotation techniques specifically RDF Schema and Web Ontology Language(OWL).The latter annotation techniques aim to provide standard structure and conceptualizationof data across domains.

Figure 1.1: Various Semantic Web standards and frameworks defined by W3C [1].

Some organization have already deployed the Semantic Web technology, such as

1.1. THESIS MOTIVATION 9

Facebook through the Open Graph1, Google Squared2, and British Broadcasting Corpo-ration(BBC)3. Using ontology engineering and the Semantic Web provide many bene-fits; such as the integration of two or more ontologies representing certain domains [17,18]. The use of upper ontologies (already existing ontologies) enable terminologies andvocabularies reuse. This thesis focuses on the use of the Semantic Web and the ontol-ogy engineering to build a Smart Healthcare Ontology(SHO), and use it to develop iSEEsystem, a novel semantic sensors selection system for healthcare. iSEE system assiststhe stakeholders to search and select IoT devices based on a certain disease.

1.1 Thesis Motivation

This thesis is motivated by scenarios in the smart healthcare domain by showing a needfor a system to allow the healthcare personnel for the selection of IoT-based applica-tion(IoT devices) based on a particular disease or a healthcare scenario. Thus, wepresent three scenarios for the motivation of this thesis. In the first scenario, a patient hasto be recommended and choose a chronic disease(for example, diabetes) managementapplication(figure 1.2), in the second scenario, the health department in the organisationseeks for an IoT-based application for the prevention of diseases related to their employ-ees’ work. And further in the third scenario, the caregiver and the family member helpa patient to install recommended IoT-based healthcare application.

Scenario 1: A diabetes remote management application for a patient

Tobias is an elderly person suffering from diabetes disease, and his blood glucose levelneeds to be checked regularly by his doctor to prevent further serious complications,and to feel healthy while living with that disease. Since he lives in Boden (far fromthe Luleå hospital), traveling costs him money and takes a lot of time. To avoid thoseextra traveling costs and to save time. He needs a remote diabetes management systemthat allows the doctor to get the diabetes status updates remotely and regularly. Fromthat, we consider that the doctor can recommend him a remote diabetes managementsystem to assist him using a particular smart healthcare system. And further Tobias andhis family can also be interested in knowing the mode of operation and other detailsrelated to the recommended diabetes management system, for example, his family canbe interested in requirements posed by the diabetes management system. For example,type of network connectivity and bandwidth.

1http://www.semantic-web-journal.net/content/facebook-linked-data-graph-api2https://ahrefs.com/blog/google-processes-queries-semantic-web-environment/3http://www.bbc.co.uk/ontologies

10 INTRODUCTION

Figure 1.2: The description of the first scenario. A patient travels to a long distant hospitalregularly for further disease treatments. Thus, a doctor recommends him a smart healthcaretechnology for remote assistance.

Scenario 2: Disease prevention application for field employees

Field jobs can be risky for the employees’ health. Therefore, employees need a formof disease prevention either from injuries or any other diseases related to their everydayjobs. For example, VickBjorx AB is a mining company that takes care of its employees.Depending on how field workers are exposed to the coal dust, it is easy to get respiratorydiseases. The health officer in that organisation can decide to buy an IoT-based health-care application that allows the remote monitoring of the respiratory conditions of theminers. Such a system can be used to easily monitor the vital signs of the miners.

Scenario 3: Smart home for Alzheimer’s patient

Josh is an elderly person who suffers from Alzheimer’s disease at the early-stage, one ofhis son and the caregiver plan to monitor Josh’s condition using IoT-based applicationwhile Josh is at home(for example, the time he spends sleeping or watching the televi-sion). To deploy IoT system his son and the caregiver might be interested in informationrelated to those required IoT devices, such as the availability, communication protocol,QoS(Bandwidth requirements), and the placement of devices.

1.2. AIMS AND OBJECTIVES 11

The above mentioned scenarios highlight our research motivation and a need for a sys-tem that can help healthcare professionals as well as patients to efficiently select IoTdevices based on a disease of interest and to get detailed information about selectedIoT device. Such system needs to be semantically interoperable to enable integration ofhealthcare and IoT domains

1.2 Aims and Objectives

The aim of this thesis is to analyse the smart healthcare domain and from found analyses,build an iSEE system that allows stakeholders to select a set of IoT devices from anumber of IoT devices based on particular disease in the healthcare domain. To achievethat, the main objectives of this thesis are listed as follows:

• The first objective is to analyse requirements for an efficient integration of health-care and IoT domains, by doing so, extend the Semantic Sensor Network Ontol-ogy(SSNO) [8] and incorporate the Disease Ontology(DO) [19] as human dis-ease glossary, with the aim of building an integrated Smart Healthcare Ontol-ogy(SHO).

• The second objective is to propose and develop an iSEE system that incorporatesSHO. Then realise the iSEE system protoype for efficient IoT devices selection inthe healthcare domain.

1.3 Research Challenges

In the last decades, the deployment of IoT devices in healthcare has increased consider-ably. However, there are still remaining a number of challenges in the adoption of IoTin healthcare:

• The difficulties in selection and deployment of most relevant and correct IoT de-vices(for example, sensors) to assist patients with different diseases.

– There are a number of aspects to consider while choosing IoT devices suchas the compatibility between devices, point of attachment, network require-ments(throughput) and type of network.

– So far, it is also challenging for the users and hospital professionals who donot have enough knowledge in technology, to compare and choose amongavailable IoT devices based on a disease of interest.

12 INTRODUCTION

• Another challenge is the interoperability related to the integration of IoT deviceswithin the healthcare domain. Further, there is a need for a standardized mecha-nism for linking IoT devices relating to specific diseases and healthcare scenarios.

1.4 Thesis ContributionThis thesis focuses on IoT devices selection based on the disease or a healthcare scenarioof interest. Driven by defined research challenges, this thesis proposes, develops andvalidates iSEE system, a novel semantic sensors selection system for healthcare. Thisresearch work contribution can be divided into two parts:

• This thesis analyses the smart healthcare domain requirements for efficient de-velopment of a Smart Healthcare Ontology (SHO), as an extension of SemanticSensors Network Ontology (SSNO); and incorporate the Disease Ontology (DO)to enable sensors selection for standardised disease descriptions.

• This thesis proposes and validates the iSEE system architecture that is based ondeveloped SHO and from that realise a prototype that allows stakeholders to selectand deploy efficiently IoT devices and then provide detailed information on theselected IoT devices.

1.5 Thesis outlineThe remaining part of our thesis work includes following parts: the background and lit-erature review, the proposed architecture and developed prototype, implementation andresults collection, and the evaluation, conclusion and future work. The thesis chaptersare structured as follow:

• Chapter 2 reviews the related work in the field of smart healthcare. This chapterhighlights the state of the art in IoT-based healthcare applications. This chapterreviews as well the Semantic Web technology as a solution to the semantic in-teroperability and data reusability challenges. The current used IoT devices inhealthcare and their possible descriptions are reviewed as well.

• Chapter 3 presents the proposed iSEE system architecture as well as its respectivelayers. This chapter presents as well the extensions made to the SSNO and howthe DO is used as human disease glossary to build SHO.

• Chapter 4 describes the iSEE system prototype implementation and analyses itsperformance. In the first section of this chapter, we present the prototype imple-mentation which comprises the seven steps for SHO development as well as the

1.5. THESIS OUTLINE 13

entire prototype implementation, and further, we evaluate SHO using CompetencyQuestions(CQs), expressed in both natural and SPARQL queries languages. Fur-thermore, we evaluate the iSEE system performance using benchmarking resultsbased on query response times and query response result-set elements.

• Chapter 5 concludes the thesis, presents the evaluation of the achievements forthe fixed objectives at the beginning of this thesis and then gives the future orien-tation of this work.

CHAPTER 2

Background and literaturereview

2.1 IntroductionThe previous chapter introduced our thesis work and presented the challenges, motiva-tions, objectives and contribution of this thesis. This chapter reviews the state of thearts in the smart healthcare domain; such as current IoT- healthcare based applicationsand used IoT devices in healthcare as well as their possible description. This chapteralso discusses the background of the Semantic Web and how it solves the semantic in-teroperability challenge. We also discuss the already existing projects related to ourthesis. This chapter begins with the definitions of healthcare and IoT in section 2.1.1and 2.1.2 respectively. Section 2.2 presents the IoT in healthcare; the subsection 2.2.1summarises the state of the arts for IoT-based healthcare applications. In section 2.3we review the interoperability challenge. Section 2.4 reviews the background related tothe Semantic Web, as well as the ontology engineering; in subsection 2.4.1 we discusshow the ontology solves the interoperability issue and in subsection 2.4.2 we review theSSNO. Further, Section 2.5 discusses the projects similar to our thesis.

2.1.1 Healthcare

Every individual desire to be healthy and productive. Thus, a person is healthy whenis having the high level of physical, mental and social well-being. World Health Orga-nization(WHO) 1 defines ’healthy’ as "a state of full physical, psychological and socialwell-being and not simply the absence of disease or illness". In general, activities to

1http://www.who.int/about/definition/en/print.html

15

16 BACKGROUND AND LITERATURE REVIEW

cure, prevent or rehabilitate humans are undertaken by healthcare providers. There aremany definitions of healthcare; the word ’Healthcare’ is defined in the Oxford dictio-nary as "an organised procurement of medical care to persons or community by healthprofessionals". Further, Business2 Dictionary defines ’Healthcare’ as" the act of prac-tising preventive or necessary medical procedure to improve a person’s well-being. Andthat task is done by performing the surgery , administration of medicine or other alter-ation in person’s lifestyle. And those services are offered through health care formed byhospitals and physicians". In this work, we consider the business definition.

2.1.2 Defining the Internet of Things(IoT)

Figure 2.1: High level picture of IoT applications in various areas[2].

IoT has been a trending technology in the last three decades. It allows physical things’objects’ to get connected to the Internet and be accessed by remote systems for smarterprocesses, or such. In this regards, each physical object entails sensing or actuating de-vices for either gathering sensing data or reacting to triggers sent by remote systems.

2http://www.businessdictionary.com/definition/health-care.html

2.2. IOT FOR HEALTHCARE 17

There is no consensus about the definition of IoT. Thus, many definitions have beenprovided by different researchers. Gartner defines IoT as "a network of physical thingsthat embeds technology devices with the intention of communicating, sensing and com-munication with the external surroundings or their internal states."3. Further, webope-dia defines IoT as "a growing network of things that get an IP address to enable itsconnection to the internet. Then allow the interaction between them or other internetconnected systems and objects."4. Besides, iotwiki defines IoT as "an interconnectionof devices(objects) comprising embedded sensors, software and network connectivityincluding necessary electronics devices enabling them the gathering and interchangeof data by making them responsive."5. Thus, from the before-mentioned definitions,we can define IoT as "a network of physical things that entails sensing and actuatingdevices to allow on one way the sensing and transmitting data to the remote or embed-ded central systems for further processing, or the other way, to receive signals from theremote central system to trigger environmental events. "In this work, we consider IoTdevices, any object or device that has defined features. Figure 2.1 depicts different phys-ical objects that embed sensing and actuating devices, and they can be either vehicle,motorbikes, home appliances and other items. The next section explores and presentsthe IoT applications in Healthcare sector.

2.2 IoT for Healthcare

IoT paradigms are remodelling healthcare through numerous deployment of IoT-basedapplications. Refer to the provided definitions of IoT and Healthcare, the deployment ofIoT in healthcare consists of networks of IoT-enabled medical devices connected with apurpose of gathering and sending vital information to a local or remote processing com-mand system for further processing. Using collected medical information, it is possibleto perform remote diagnosis and other medical activities. This section reviews someIoT-based healthcare applications, a sample of today IoT devices used in healthcare,and some descriptions parameters that can help users to gain more knowledge aboutIoT devices.

2.2.1 IoT-based Healthcare Applications

Research in IoT for healthcare focuses on various applications including and not lim-ited to chronic diseases management [20, 21], home automation, ambulatory medical

3http://www.gartner.com/it-glossary/internet-of-things/4http://www.webopedia.com/TERM/I/internet-of-things.html5http://internetofthingswiki.com/internet-of-things-definition/


interventions, care for the aged population, rehabilitation and much more. In follow-ing sub-sections, we review the chronic disease management, disease rehabilitation andprevention management, and care for elderly population.

2.2.1.1 Chronic Disease Management

Figure 2.2: Example of remote chronic disease management.

The chronic disease management [22, 10, 23] is an active research area in smart health-care domain. It facilitates the assistance for patients with chronic ailments such asdiabetes [24], asthma [25], Alzheimer’s disease [26], alzheimer’s disease [26], conges-tive heart failure [27] and chronic hepatitis to name few. Chronic disease managementapplications include a set of IoT devices to distinguish patients lifestyle patterns [10]and to detect health abdominals using four common vital signs 6 namely; heart rate,blood pressure, body temperature and respiratory rate. In [28, 29, 3, 30] authors presentvarious trending smart healthcare technologies to assist patients with chronic diseasemanagements.

In [28] authors present a personal device for diabetes management that enhances in-sulin therapy dosage calculation, with more factors in consideration. The proposedarchitecture is based on IoT devices and connects RFID personal card for patients’ pro-file management, and a 6LowPAN enabled device, to support connections between the

6https://www.nlm.nih.gov/medlineplus/ency/article/002341.htm


hospital personnel’s desktop applications that manage the patient health cards, patient’sweb portal and glycemic index information storage.

In [29] David and Asthmapolis Inc. describe a USB, WiFI and GPS enabled spiroscoutinhaler that uses Inhaler sensors combined with mobile applications and analytics totrack every asthma patient’s crisis and record the device usage based on the location andfrequency by connecting patient’s smartphone. With the support of the usage patternand other stored records, the physicians can adjust patient’s medication.

Figure 2.3: Example of a pill box that allows patients to adhere to their medications[3]

Despite, patients suffering from chronic diseases are mostly prescribed medicines,thus, in[3], authors present a smart pillBox(figure 2.3) to help patients to adhere to theirmedications, it includes automated and timely alert system to refill tablets and to remindthe patient when He/She forgot to take medicines. It contains an alarm clock with lightslot and a GSM module for alerts management.

Furthermore, in [30] authors present a personalised cloud-based healthcare system forchronic disease patients management. The proposed architecture and the produced pro-totype provide the patients monitoring both at the hospital or home. Moreover, the


patient’s profile is stored on a Virtual Machine(VM) running on the hospital’s cloud,and synchronized with portable and home installed IoT devices. Figure 2.2 shows anexample of a remote chronic disease management.

2.2.1.2 Rehabilitation and Prevention of Diseases

Figure 2.4: Example of fitness activities tracking for diseases rehabilitation and prevention[4]

Healthcare is not only limited to the disease curing but also diseases rehabilitation [31]and prevention [32]. Thus, fitness and personal health [33] activities are very helpfulwhen considering both rehabilitation and prevention of diseases. This area of IoT-basedhealthcare applications uses mostly wearable devices, for gathering, and storing healthinformation either locally or remotely. In most of the cases, both the user(performingfitness or personal health activities) and hospital personnel can access stored data forfurther physiological treatments. In [34, 35, 36, 37] wearable based healthcare applica-tions projects are presented sequentially and are mostly used for fitness activities.

In[38] authors present a prototype that assists the orthopaedics rehabilitation process


for a patient while located either at home or hospital. The presented prototype allowsthe user to monitor immediate feedback related to the executed exercises. Further, thephysiotherapists can monitor or analyse collected data from the system, and adjust ther-apy if necessary. The prototype implements a particular smart watch [39] that tracksheart beat rate and wearable clothes that gather vital signs [40, 41, 11] measurements toperform physical monitoring activities.

In [42] authors presents wearable sensors based rehabilitation training assessment mech-anism using three wearable sensors attached to the chest, thigh and shank of the movingleg to facilitate the patients with knee osteoarthritis to manage their rehabilitation pro-cess. In this work, frequency-domain, time-domain, characteristics and angle data ofthe motion sensor signals are used to distinguish the exercise type and identify eithertheir positions are proper or not.

Moreover, In [43] authors propose a home based system that tracks the patient’s re-habilitation program, and gives a real-time based biofeedback during the rehabilitationprogress and informing the patient about achieved results and further goals to succeed.Moreover, users can download recommended rehabilitation protocols according to theuser’s conditions. The system is composed of a sensor unit, visualisation and commu-nication unit and virtual clinical revision server. The sensor unit is constituted by anaccelerometer, a Bluetooth module and a microprocessor and that calculates the move-ment tilt angle and send it to the synchronised visualisation unit that is constituted by aPersonal Digital Assistant(PDA). And the recapitulation calculations are performed andsend to the clinic and the patient for further diagnosis decisions.

In [44], Bill et al. summarise the state of the arts in IoT-based healthcare applica-tions that use wearable sensors in particular. Figure 2.4 depicts an example of fitnessactivities tracking for diseases rehabilitation and prevention.


2.2.1.3 Care for the Elderly and Paediatric Population

Figure 2.5: Example of a typical Smart-home monitoring system[5].

The elderly and paediatric population are more affected by the disease because of theirbody immunity vulnerability. Mainly, the aged population are vulnerable to chronic ill-ness. Despite, most of them don’t want to spend their daily basis life in the elderly carehomes. Thus, it is necessary to create a safe, cheap and friendly environment to assistthem while staying independent and active. Currently, researchers put much effort inthe development of robust and effective IoT-based healthcare applications related to falldetection solutions [45, 46, 47, 48], smart homes [12, 49, 50], and vital signs abnormaldetection using wearable or implantable devices [51, 52].

Since fall is a risk for elderly, in [53] authors proposed a fall detection system. Thatsystem is composed of a wireless internet enabled smartphone that entails a triaxial ac-celerometer. And uses two algorithms; Support Vector Machine(SVM) algorithm used


for data processing and the combination of Kernel Fisher Discriminant(KFD) and Near-est Neighbor(K-NN) algorithms to add more precision classification to the system.

Further, In [54] authors proposed a fall detection prototype that uses a tiny device wornon the waist and a home enabled fixed network motes. The proposed prototype imple-ments a MEMS accelerometers that allow fall detection and RF signal strength usedfor the elderly localization. Moreover, in [55] authors proposed a real time monitoringambulatory and fall detection system that uses blue-tooth connection, accelerometer, tiltsensor and gyroscope to estimate the posture of patient body as well as a fall detectionalgorithm.

Furthermore, in [56], authors present a solution to support the elderly person sufferingfrom dementia based on detection and monitoring of Behavior of Personal with Demen-tia(BPD) parameters, using simple sensing equipment that monitors and store data, andfurther create behaviour patterns that enable the detection of abnormal behaviour andalert the caregiver.

Moreover, in [57] authors present two smart home scenarios defined by Telia Inc. tohelp elderly persons to stay home and be monitored by caregivers. The first scenarioimplements the basic monitoring functionalities based on emergency button, ip camera,voice-connection, motion sensor and wall plugin. Further, in the second scenario, se-curity features are enhanced using the emergency button, ip camera, door lock module,motion sensor, wall plugin and smoke alarm sensor. Figure 2.5 depicts an example of atypical smart home.

2.2.2 IoT Devices Used in Healthcare

As before-mentioned, IoT devices can be used to enable the remote health monitoringand emergency notification systems in healthcare. Thus, IoT devices can be classifiedbased on their usage or their physical placement. From that point of view, there areIoT devices which are used directly to the patients body, and are mostly wearable orimplantable, such as, body temperature sensor, Electrocardiography(ECG) [58, 59, 60],electromyography(EMG) [61], accelerometer [62, 63, 64], Heart rate [65, 66, 67] andpulmonary monitor [68, 69]. In contrast, other types are environmental IoT devices,that should be placed in patient’s room or another part of the building, such as firedetection [70], window and door sensors, emergency button trigger, motion sensor andpressure mat sensor. Further, some IoT devices can be placed anywhere such as, suchas RFID module [71, 72, 73]. More about IoT devices can be found here [74, 75, 76,77, 78, 79, 80, 81]. Figure 2.6 shows an example of IoT devices that are mostly used in


healthcare.

Figure 2.6: Some examples of IoT devices used in healthcare domain.

2.2.3 IoT Device Description

In the previous section, we reviewed the IoT-based healthcare applications and todayused IoT devices. However, users need to get more knowledge about those IoT devices.In this subsection, we present some sensors descriptions that can influence users to selecta particular IoT based application and its devices, such as physical placement, Qualityof Service(QoS) or throughput requirements, availability(manufacturer) and communi-cation protocol stack.


2.2.3.1 Throughput Requirements

Throughput (QoS) parameter is the rate of successful message transmission over acommunication channel(similar to the required digital bandwidth consumption). Thethroughput parameter depends on the network protocol used by IoT devices in the con-text of network communication. Throughput is sometimes measured in percentage or bitper seconds(bps). The most popular deployed protocols by IoT-based applications(2.7)are Hypertext Transfer Protocol, Message Queue Telemetry Transport and ConstrainedApplication Protocol.

Figure 2.7: IoT application layer competing protocols.

• Hypertext Transfer Protocol (HTTP) [82] is a network protocol adopted to estab-lish the communication between two entities in particular between the server(for,e.g., a node hosting a web-site) and the client(for, e.g., a web browser). HTTPoften uses Transmission Control Protocol (TCP) as a transport protocol thus itsreliability, and rarely, HTTP can use User Datagram Protocol(UDP) instead ofTCP.

• Message Queue Telemetry Transport(MQTT) [83] is a network communicationprotocol built on top of TCP/IP and mostly used in Machine to Machine(M2M)communication for IoT devices. It’s a lightweight protocol( header size of 2bytes), and it adopts the pub-sub model that includes the subscriber, broker andpublisher.

• Constrained Application Protocol (CoAP) [84] is a request-response protocol thatused mostly in the client-server model. Nevertheless, the functions of client andserver are regularly interchangeable in M2M communications. CoAP is built ontop of User Datagram Protocol(UDP).


2.2.3.2 Point of Attachment

The point of attachment parameter describes the physical placement of IoT devices inHealthcare. Some IoT devices can be used directly to the patient’s body, and they aremostly wearable or implantable with purpose of measuring the patient’s body temper-ature, heart rate and much more. Other IoT devices can be placed in patient’s room tocapture environmental parameters, such as fire alarm, window and door sensors, motionsensors and much more. This parameter can influence the stakeholder for IoT devicechoice depending on its physical placement and his health conditions.

2.2.3.3 Manufacturer

The manufacturer parameter refers to the company or the vendor of IoT devices. Usingthe manufacturer’s web pages, this parameter can help users to check updated productsand their availability, as well as other detailed description. There are famous companiesthat manufacture IoT devices such as, IBM, Samsung and Fibaro Inc. to name few.

2.2.3.4 Communication Protocol Stack

The protocol stack is the implementation of a group of protocols running concurrentlyfor a deployment of a network protocol suit. To date, there are many IoT-based applica-tions system solutions built based particularly on a particular communication protocolstack. Nevertheless, each solution is defined by the manufacturer (for e.g., In home au-tomation, Fibaro system uses Z-wave standard). Thus, there are limited circumstancesthat different system can co-operate each other if they are from different manufacturer.Currently, there are various protocols(figure 2.8) in IoT-based healthcare applicationssuch as Zigbee, Z-wave, WiFi, Bluetooth and Body Area Network(BAN) to name few.

Figure 2.8: IoT competing protocol stacks.

• Zigbee is a Radio Frequency(RF) wireless mesh network based on IEEE 802.15.4standard with 256 as the maximum network size. In ZigBee, to forward informa-

2.3. INTEROPERABILITY AS A CHALLENGE 27

tion, each device acts as a relay.

• Z-wave [85] is a mesh network and half low-level duplex RF communicationprotocol with a data range of 100 Kbit/sec. It is designed to allow the communi-cation between the slave node(s) and the control node(s). The Z-wave maximumnetwork size is 232.

• BAN [86] is an ad-hoc network based on sensors, actuators, communication en-tities and the processing unit. BAN has two kinds of communication; Intra-BANrefers to when the communication occurs among entities that make up the BANbased on wireless networks like Bluetooth or ZigBee. And extra-BAN refers towhen the communication goes beyond the BAN.

• Bluetooth[87] is a standard wireless communication and a P2P Personal Area Net-work(PAN) technology, with nine devices as the maximum network size. Blue-tooth 4.0 is the latest standard and was approved in 2010.

• Wireless Fidelity(WiFi)[88] or wireless Internet access is a wireless technologymainly used in offices and homes with high-speed of up to 433 Mbps. WiFi isused mostly in Smart Homes systems.

The communication protocol stack parameter can affect the user’s choice depending onthe needed device compatibility with the system that He/She already owns.

2.3 Interoperability as a Challenge

The previous section presents the IoT-based applications in healthcare. Nevertheless,there is a big challenge of selecting appropriate technologies that can be helpful for aparticular disease or a symptom of interest. Further, the search and selection issue ariseswith lack of sufficient knowledge about IoT devices description, therefore, IoT devicescan be annotated with additional information to allow stakeholders to get more detailsabout available IoT devices. Furthermore, to be able to build such system, there is aneed for a technique that can be used to combine the human diseases or related symp-toms and relevant IoT-based healthcare applications domains. Thus, to solve presentedissues, both domains should be represented semantically to integrate the semantic inter-operability feature. In [89] authors define the semantic interoperability "as the ability oftwo domains to exchange meaningfully and accurately the information to produce usefulresults and both parties must comply with a common data interchange reference model".

From that, in [14] authors explore and define contexts that the semantic interoperability


Figure 2.9: The overview of the interoperability aspect in a smart city. The upper part of thefigure shows different smart city domains and the lower part presents the smart city’ domainslocation. [6].

fits on. They also mention issues that follow the lack of semantic interoperability, aswell as different solutions that have to address the same problem in IoT-based appli-cations, when considering the integration of more than two domains. Further, authorssummarize the foremost requirements affiliated to the development of the IoT appli-cations and services reference to the semantic interoperability requirements. Further,in [90] authors highlight how the domain knowledge interoperability feature is a keyfor building the semantic web of things. Authors also put stress on the use of SemanticWeb when considering interlinking domains, as well as the enhancement of terminol-ogy reusability and common understanding among interlinked domains. Furthermore,authors in [6], present an Integrated Semantic Platform (ISSP), a prototype developedbased on semantic interoperability, and that brings support for common understandingand services reusability across smart city services domains, where the semantic inter-

2.4. SEMANTIC WEB AND ONTOLOGY 29

operability and reusability are inherited from ontology integration and extension. Thefigure 2.9 depicts the overview of interoperability in smart cities. From that, we takea conclusion that the Semantic web is a good technique to combine the both the IoTand healthcare. The next sections explore the Semantic Web and Ontology, as well asthe ontologies integration techniques to enable IoT devices selectivity based on an aparticular criteria.

2.4 Semantic Web and Ontology

In the previous section, various authors mentioned the cruciality of the use of SemanticWeb when considering the integration of two or more domains to enable reusability andinteroperability. Moreover, in [16] authors describes the Semantic Web as" a set of stan-dards that provide a common framework to allow data to be reused and shared acrosscommunities and domain applications", and also provide detailed description of RDF,RDF schema and OWL as Semantic Web standards.

Moreover, In [7]authors describe the semantic web as an extension of the current web,in which the information tallied a well-defined meaning, and that enables services tobe automatically annotated, searched, discovered, composed and advertised. That paperalso describes the semantic web architecture(figure 2.10) with six layers, described asfollow:

Figure 2.10: Semantic web architecture [7].


• URI and Unicode: layer helps to identify and locate resources using the UniformResource Identifier(URI). i.e. each resource is assigned a unique URI, and theUnicode part is the model for computer character representation.

• XML+NS+xmlschema: layer comprises of a markup language. The meaning ofmarkup language implies that is machine-readable and possesses its format. Eachdocument includes a namespace declaration using XML Namespace.

• RDF+rdfschema layer presents the first layer of the semantic web as such. RDFis a structure to use and represent the metadata and by describing the semanticsof data in a machine-accessible way. Moreover, resources and the relationshipbetween them are identified by URIs. Despites, RDF schema is simple modellinglanguage that defines resource concepts and relationships among them and imple-ments a simple reasoning framework.

• Ontology vocabulary layer contains the ontology which is a way of describingthe semantic of the data. It allows the communication of various parties to be ableto comprehend each other. As a semantic web, it provides standard grammar andvocabulary for the published data as well as the semantic description to keep themready for inference.

• Logic and Proof layers comprise the mechanisms that considered when buildinga semantic web on a logic basis and follows the ontology structure. And the prooflayer contains reasoning mechanisms used to check and resolve the consistencyproblems and make new inferences.

• Trust layer contains the integrity of the information on the Web to provide anassurance of its quality.

The ontology vocabulary layer is an essential layer of the Semantic Web and it com-prises of the ontology which is the key component for data reuse and semantic inter-operability. The world ontology was primarily used in philosophy to define the "thetheory or study of the explanation of being."; and thus it represents the entity and itsrelationship with activities in its environment. Further, in software engineering and AI,the ontology is defined as" an explicit formal specification of a shared conceptualiza-tion". Thus, the pillars of this definitions are: firstly, "all knowledge" an ontology musthave an unambiguous specification. Secondly, an ontology is "conceptualization" i.e.has a universally understandable concepts. Thirdly, the ontology should be "shared", toindicate an explicit meaning among domains of interest. And lastly, "Formal" relatesto the foundation of representation in well-agreed logic and any ontology should bemachine-processable.


Concerning the knowledge representation, the ontology encounters four componentsnamely concepts, relations, instances and axioms. And those components can be de-fined as follow:

• Concepts: or classes are abstract sets of objects that share common properties andconcepts can subsume other sub-concepts. And they are fundamental elements ofa domain.

• Instances: or objects are the lowest granularity of the domain conceptualization,they are the representation of a specific elements of a class. For e.g., "Sweden"could be an object of the class Europe ".

• Relations: or slot describe the relationship between instances or objects in a cer-tain domain. It also represents the relationships between instances of two classesin a particular domain, and specifically the domain and range concepts. For, e.g.,"Study" can be the relationship between "Person" and "University" classes.

• Axioms: are used to check the consistency of the ontology. They are used toimpose restrictions on the values of classes or instances and expressed using logic-based languages such as Fuzzy description logic.

The ontology applications was deployed for the first time in AI [91], and thereforeadapted in other fields such as semantic web [92], multi-agent [93] and search en-gines [94].

2.4.1 Ontology Interoperability

Since the aim of using the ontology in this thesis is to use the semantic interoperabil-ity and build knowledge intensive system by combining the IoT-based application andhuman disease domains. Thus, to enable the interoperability ontology support acrossvarious domains of interest there are several presented techniques as follow:

• Ontology Merging: is the creation of a coherent ontology from existing sourceontologies related to the same domain to infer a new ontology and replaces usedsource ontologies [95, 96].

• Ontology Mapping: is a process that establishes the semantic relationships andcorrespondence between entities of different entities. Despite, that operation doesnot change respective source ontologies since the process concerns about linkingtheir concepts[97, 98, 99, 100].


• Ontology Integration: process derives a new ontology from two or more sourceontologies, Thus, from this perspective, two different ontologies D and E may bereplaced by a new inferred E ontology. The difference between this operation andthe ontology merging is that it operates across different domains[96].

• Ontology alignment: is the process of forming a consistent link between twoor more ontologies by bringing those source ontologies into an agreement. For,e.g., Suppose two ontologies F1 and F2, the mapping process means that eachentity in F1 ontology tries to find a corresponding entity (i.e. by using matchingalgorithms), that has the same dedicated meaning, in F2 ontology [101, 102, 103,104].

Moreover, there are additional techniques that support the semantic integration of do-main ontologies such as upper ontologies(also known as a Fundamental or top-levelontology). In [105] authors define Upper ontology as" generic ontologies that describegeneral concepts that are the same(agreed) across knowledge domains. Thus, they de-scribe general entities that do not belong to a particular problem domain. Often, con-sistent ontology has an upper ontology. Some of the famously known upper ontologiesare; Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE)7that in-tends to capture the ontological underlying human common sense and natural language.And Basic Formal Ontology(BFO)8 that contains a series of sub-categories of differentcategories. For instance, BFO counts more than 150 known extension ontologies.Moreabout upper ontologies can be found in [106], the same research work describes andcompares seven ontologies.

2.4.2 Semantic Sensors Network Ontology

In the previous section, we reviewed upper ontologies. The SSNO is an upper ontologydeveloped by W3C to provide a shared and agreed set of common concepts to enablesemantic interoperability across semantic sensor network domain. The defined goalduring SSNO development was to begin a formal process for building ontologies thatrepresent semantically capabilities of sensors and sensor network [8]. SSNO is based onOWL2 and is available at"http://purl.oclc.org/NET/ssnx/ssn" and it was designed in oneyear within three phases. Firstly, the core classes and slots were designed(observations,sensors, features and properties, and systems). The second phase added the operatingand survival restrictions, measuring capabilities, and capabilities. Finally the Dolce-Ultra-Light(DUL) and further the realisation of the core Stimulus-Sensor-Observation

7http://www.loa.istc.cnr.it/old/DOLCE.html8http://ifomis.uni-saarland.de/bfo/


Figure 2.11: The SSNO, key concepts and relations, split by conceptual modules[8].

ontology design pattern [8] were added. The SSN ontology comprises of ten conceptualmodules as shown in figure 2.11. The full SSNO contains 41 classes and 39 objectproperties and extends DOLCE-Ultralite(DUL) upper ontology. Thus, including DULextension, it is composed of 117 concepts and 142 objects in total. Thus, The SSNontology aligns DUL upper ontology for further explaining classes and object propertiesand restricting possible interpretations of the ontology. Moreover, the ontology is builtbased on a core and central part that describes the relationship between the Stimulus-Sensor-Observation(SSO) pattern(Figure 2.12) [8]. Thus, the SSO pattern links thesensing device, the environment and the process. The pattern parts are summarized asfollow:

1. Stimuli: describes environmental states (dul: Event) that the sensor device candetect and use to measure a particular property. Therefore, a stimulus (ssn:Stimulus)is a proxy (ssn:isProxyfor) for an observable property (ssn:Property) or an amountof observable properties. For, e.g., variations in electrical resistance as a proxyfor temperature in a thermistor.

2. Sensors: described as (ssn:Sensor), Sensors are physical objects that observeand then convert the observed(incoming) stimuli (ssn:detects) within another,and mostly digital representation (ssn:SensorOutput). Sensors are anything that


Figure 2.12: The Stimulus-Sensor-Observation Pattern [8].

senses, and can be a sensing system, hardware devices or human run laboratorysetups.

3. Observations: also represented as (ssn: Observation), an observation links andput all in an interpretative context from the action of sensing(dul:includesEvent),the stimulus(dul:includesEvent), the method (ssn:sensingMethodUsed), the sen-sor(ssn:observedBy), the result(ssn:observationResult), the property (ssn:observedProperty)and observed feature(ssn:featureOfInterest).

Since our aim is to represent semantically IoT devices, the sensors(ssn:Sensor) partof SSO pattern is only extended. The added concepts and objects properties are fullydescribed in the next chapter.

2.5 Related Projects

In this section, we discuss the related work. There are no much projects implementedin this field yet. Nevertheless, in [107] authors present an ontology alignment inferredfrom bioinformatics ontologies namely disease symptoms(SYMP), Foundation Modelof Anatomy(FMA), Disease Ontology(DO), and the extension of Semantic Sensors Net-work Ontology (SSNO) with wearable devices. The research aims to allow healthcareprofessionals the ability to search and select for wearable devices based on disease,

2.6. CHAPTER SUMMARY 35

symptoms and anatomy. Authors also intend to expose specific issues with aligning on-tologies and specifically to highlight the need for a compatible ontology design method-ologies to ease the alignment of different ontologies. Further, in [13], Perera and al.proposed a context-aware sensor search, selection, and ranking model (CASSARAM)for IoT, a sensor search, selection and ranking solution when considering that a numberof available sensors. The selection and search for sensors consider a set of characterssuch as accuracy, reliability, and batterie life. Concerning sensors ranking and indexing,authors used the weighted Euclidean distance comparison in multidimensional spacetechnique. And further, authors used both semantic web and static reasoning for effi-cient sensors searching, indexing and selection.

2.6 Chapter SummaryIn this chapter, we reviewed the background work about the IoT-based healthcare ap-plications, IoT devices and some devices description needed for sensors annotations.The need for semantic web in IoT devices selection based on healthcare criteria ofinterest was highlighted. In the first section of this chapter, healthcare and IoT defi-nitions respectively are presented. The second section bestows the review of the IoTapplications in healthcare and today used IoT devices in healthcare. Further, the thirdsection presents the semantic interoperability as challenges that IoT-based healthcareapplications integration are facing. Furthermore, the fourth section shows the use of theSemantic Web to solve semantic interoperability issue. The Firth section presents therelated work.

CHAPTER 3

SEMANTIC SENSORSSELECTION SYSTEM FOR

HEALTHCARE

The previous chapter reviewed the background and related work to the IoT-based health-care applications and the Semantic Web as a solution for domains interoperability. Thischapter begins by describing the iSEE system proposed architecture as well as its con-stituent layers. Further, we give more details about the Disease Ontology(DO), theextension of the SSNO and the integration of the extended SSNO and DO for develop-ing a Smart Healthcare Ontology(SHO). This chapter is structured as follow: the iSEEsystem architecture and its layers are described in 3.1 section. In section 3.2 we presentthe SHO. therefore the DO and the SSNO extension are presented in 3.2.1 and 3.2.2 sub-sections respectively as well as the integration of DO and SSNO to build SHO. Finally,Section 3.3 concludes the chapter.

3.1 iSEE System ArchitectureTo build the iSEE system, a novel semantic sensors selection system for healthcare, weproposed an architecture(figure 3.1). The proposed iSEE system architecture comprisesfour layers; the first layer is the User layer, it describes the way stakeholders interactwith the iSEE system depending on their preferences. The Application is the secondlayer of the iSEE system architecture; it is the intermediary layer between the User andthe Ontology layer, and it helps to query the SHO in an efficient manner. The third layeris the Ontology layer; it comprises the Fuseki server running remotely and that hosts theSHO, and the fourth layer is the Systems layer, it comprises the physical smart systems

36

3.1. ISEE SYSTEM ARCHITECTURE 37

and it wraps the healthcare IoT devices, health application gateways and the networkinfrastructures sublayers.

Figure 3.1: iSEE System proposed Architecture.

38 IOT BASED SEMANTIC SENSORS SELECTION TOOL

3.1.1 User Layer

Figure 3.2: Screenshot of iSEE system User Interface.

The User layer is the first layer of our proposed iSEE system architecture; This layerdefines how the stakeholders(i.e. the doctors, nurses, caregivers, patients, and relevantGovt departments) interact with the system based on their requirements and preferences.For example, a caregiver can be interested in IoT devices constituting a particular IoT-based healthcare application and contrary; a doctor might be interested only in an IoT-based healthcare application to assist a patient with a specific disease. This layer alsocontains the iSEE system desktop Graphic User Interface (GUI, figure( 3.2)) that allowsusers to interact with the system in a quick and friendly fashion. The iSEE System GUIis developed using JavaFX as a set of media and graphics packages for the developmentof a rich client desktop application. our desktop application uses the Model View Con-troller(MVC) design pattern and the MainController class is the view class. It constructs

3.1. ISEE SYSTEM ARCHITECTURE 39

the GUI and starts the application. Moreover, the GUI is partitioned into two areas, theNavigation Panel and the Metadata Panel, each area serves a particular role in present-ing data from the SHO. The Navigation Panel allows the user to explore the SHO in ahierarchical manner, and the Metadata Panel displays the additional information relatedto the selected SHO component.

3.1.2 Application Layer

The Application layer allows the user to query our SHO, this layer contains an Endpointapplication that allows the user to interact with the SHO. The Endpoint application isdeveloped using Java programming language. To be able to manipulate and processthe semantic triples data, we use the Apache Jena API. This layer contains two mainclasses; the Reasoner class that controls the behaviour of the iSEE system dependingon the user preferences and the QueryEngine class that represents SPARQL queriesencoded dynamically in the Java programming language. The communication betweenthis layer and the Ontology layer follows Restful style. We present more informationabout this layer in the prototype implementation section, since, the application is one ofthe layers where the prototype implementation has been carried out.

3.1.3 Ontology Layer

The Ontology layer contains the Apache Jena Fuseki Server which hosts our devel-oped SHO and allows the management of the SHO datasets. Jena Fuseki is a SPARQLserver that enables the communication of the Ontology layer and the Application layerby providing the REST-style SPARQL query, by using the SPARQL protocol overHTTP(Wrapping a SPARQL query in an HTTP request). Our integrated SHO that theFuseki server hosts, is the combination of the extended Semantic Sensor Network Ontol-ogy(SSNO) and the Disease Ontology(DO). Despite the SSNO and DO, SHO containsthe healthcare scenarios-related concepts and relationships. The healthcare scenarios’concept subsumes the disease monitoring, disease rehabilitation, and disease prevention.The IoT device data annotation can allow the annotation of data coming from the Sys-tems layer with more information details such as accuracy, accessibility and availabilityto be useful to the Stakeholders.

3.1.4 Systems Layer

The Systems is the fourth layer of our proposed iSEE system architecture. It includesthree sublayers; namely, the Healthcare IoT devices, the Health application gateway andthe Network infrastructure sublayers.


• The Healthcare IoT devices sublayer comprises healthcare IoT devices to measurehuman body temperature, respiratory rate, blood pressure, heart rate and muchmore. This sublayer also contains home automation devices to assist patientsat home or hospital room such as the power switch, room temperature sensor,door sensor, window sensor and much more. The devices in this sublayer collecthealthcare related information and forward it to the Healthcare application gate-way for additional processing. more about IoT devices have been presented inSection 2.2.2 of Chapter two.

• The Health applications gateway sublayer comprises a set of IoT-based Healthcareapplications that can collect raw data from the Healthcare IoT devices sublayerand do further processing tasks, such as filtering and encryption. Here we can givean example of a smartphone that can act as a gateway for data streaming fromwireless body area network devices. Another example can be the smart watchwhich can serve as a gateway for information coming from wearable heart rate andaccelerometer sensors(more about such IoT-based healthcare applications can befound in Section 2.2 of the second chapter). After performing the data processingtasks from the gateway layer, the data can be sent to consumer(Monitoring orother services) using the network infrastructures.

• The Network infrastructure is the last sublayer of our Systems layer. It transmitsdata from the Systems layer to the Ontology layer for further IoT devices dataannotations. Currently, there are various network infrastructures such as fiberoptics, network cellular(3G, 4G) and mobile broadband. The transmission processcan be performed using either the WiFi or Ethernet technologies.

3.2 Smart Healthcare Ontology(SHO)

The section 2.4 of the previous chapter highlights the significance of the use of the se-mantic web and ontology to enable the semantic interoperability and data reuse throughthe ontology integration. Consequently, for the healthcare and IoT-based domains in-tegration and fusion, we used the Disease Ontology (DO) and extended SSNO to buildthe Smart Healthcare ontology(SHO). This section describes the DO and the extensionof the SSNO as well as their integration. Figure 3.3 represents Semantic Healthcare On-tology (SHO) as an extension of SSNO for iSEE: Semantic sensors selection system inhealthcare. The blue sky highlighted part represent the DO concepts and relationship,and yellow boxes represent our extension to the SSNO. Besides, square boxes repre-sent classes and circle box shows class instances, while the boxes marked with triplex(xxx) represent omitted parts and arrows represent the relationship between ontology

3.2. SMART HEALTHCARE ONTOLOGY(SHO) 41

Figure 3.3: Semantic Healthcare Ontology (SHO) as an extension of SSN ontology for iSEE:Semantic sensors selection in healthcare.

entities. The integration of extended SSNO and DO, as well as the extension of theSSNO as such, can be expressed using the First-order Logic(FOL) to represent the mostimportant aspects of the integrated SHO in an explicit fashion.


3.2.1 Disease Ontology

DO is an open source and standardised glossary of human diseases. It implementsshared concepts and relationships across human diseases knowledge domain. DO iscross-platform of biomedical ontologies and integrates semantically medical vocabular-ies of the comprehensive knowledge base of 8043 inherited human diseases. Each dis-ease is annotated with metadata that contains the DOID(Disease Id), the disease name,its definition, synonyms, cross-reference(xrefs) and its relationship(mostly ’is-a’ rela-tionship). The semantic integration of disease and clinical vocabularies is performed

Figure 3.4: Typical disease meta-data.

through the integration and mapping of International Classification of Diseases(ICD),National Cancer Institute(NCI’s thesaurus), Medical Subject Headings(MeSH), System-atized Nomenclature of Medicine(SNOMED CT) and Online Mendelian Inheritancein Man(OMIM) disease-specific identifiers and terms. Hence, the DO overcomes thecomplexity of disease nomenclature using the integration of OMIM, MeSH, SNOMEDCT and ICD concepts and IDs. DO terms and their DOIDs have been used to anno-tate disease concepts in many significant biomedical resources such as the Rat GenomeDatabase(RGB)1,the Immune Epitope Database (IEDB)2 and Neuroscience InformationNetwork (NIF) Standard ontology(NIFSTD)3 to name few. In this thesis work, we don’textend this ontology, but it serves us as human diseases glossary.

1http://rgd.mcw.edu/2http://www.iedb.org/home-v2.php3https://bioportal.bioontology.org/ontologies/NIFSTD


3.2.2 Extension of SSNO

The SSNO is an upper ontology that enables the ontology designers to model sensorsnetwork domains by reusing and extending already defined concepts and relationships.During the SSN ontology extension, we only focused on the sensor unit of the SSOpattern. The sensor unit is composed of many classes and we are interested in the phys-ical object (ssn:PhysicalObject) class. Thus, this class is extended with IoT devices andsystems subsuming the actuator (ssst:Actuator) and sensor instances(ssn: Sensingde-vice) classes and subclasses. The extended classes on SSNO are highlighted in yel-low(figure 3.3). The main SSNO extensions classes are the smart equipment,systems,sensor and actuator devices, and triggers.

3.2.2.1. Smart Equipment class and its subclasses

Figure 3.5: Smart Equipment class and its subclasses.

The smart equipment(SmartEquipment @ System @ PhysicalObject) class is asubclass of the System class. We created this class and its subclasses as an extension toSystem class to represent a set of IoT-based healthcare applications semantically. Thehighlighted parts of the figure 3.5 represents our extension parts to the System class.Further, the represented IoT-based healthcare applications are; the Smart spiroscoutInhaler, Smart wheelchair, Smart Pillbox, Smart life shirt and Smart watch. and canbe represented using FOL as follow (SmartEquipment A GlucoMonitoring ∧


SmartLifeShirt∧ SmartP illBox ∧ SmartSpiroScoutInhaler ∧ smartWatch ∧SmartWheelChair). Each of those IoT-based healthcare application’s class is instan-tiated with at least one specific IoT-based application product(for example, the AppleSmartWatch is an instance of the SmartWatch class) and annotated with further metadatato give more information to the stakeholders about the selected IoT-based healthcare ap-plication.

3.2.2.2 Device Class and its Subclasses

In our work, we aim to map diseases to the IoT-based healthcare applications, those ap-plications implement a range of IoT devices. In this regards, we extended the Device(ssn :

Device) class with a set of IoT devices, classified into three types such as Actuat-ing devices(ssst : ActuatingDevice), Sensing devices(ssst : SensingDevice) andtriggers(ssst : Trigger).The Device(ssn:Device) class is also a subclass of the designartifact and the system classes (ssn : Device @ ssn : System∧ssn : DesignedArtifact).Assume that x represents any of added IoT device.

Figure 3.6: List of modeled sensors.

∀x, x ∈ ssst : ActuatingDevice @ ssst : Actuating ∧ ssn : Device (1)∀x, x ∈ ssn : SensingDevice @ ssn : Sensor ∧ ssn : Device (2)∀x, x ∈ ssst : Trigger @ ssn : PhysicalObject ∧ ssn : Device (3)From the above equations 1, 2 and 3,ssn : Device @ (ssst : ActuatingDevice ∧ ssn : SensingDevice ∧ ssst : Trigger)


⇒ ∃x, x ∈ ssst : ActuatingDevice ∨ ssn : SensingDevice ∨ ssst : Trigger

� x ∈ ssn : Device(4).The formulae (1), (2) and (3) led to formula (4) that generalizes our extension to thedevice class with IoT devices namely the Actuators, Triggers and Sensors. Further-more, metadata are added to each device and smart system such as, the device name,description, required MQTT throughput, required HTTP throughput, required CoAPthroughput, the way the device is controlled, the manufacturer and the communicationprotocol stack. The annotated metadata were added to the annotation properties.

3.2.2.3 Smart Healthcare scenarios class and its Subclasses

Figure 3.7: Smart healthcare scenarios class and its Subclasses

In addition to the extension of the SSNO and the Disease Ontology(DO), we added thesmart healthcare scenarios to the SHO as well to represent scenarios found in health-care . The smart healthcare scenario(ssst : SmartHealthcareScenario) class com-prises the disease monitoring(ssst : DiseaseMonitoring), disease prevention(ssst :

DiseasePrevention) and disease rehabilitation(ssst : DiseaseRehabilitation) sub-classes. Further, the disease rehabilitation class represents semantically and subsumesthe post curing treatment activities, such as the outdoor therapy(ssst : OutDoorTherapy)and fitness(ssst:Fitness) activities subclasses. Furthermore, the disease monitoring rep-resents three patient monitoring scenarios, and particularly the three scenarios definedby Telia. Next, the disease prevention class represents semantically the methods andtechniques used for a particular disease prevention such as fitness(ssst:Fitness) and otherwork-related protections(ssst:WorkProtection).Using the following equation, we cansummarize our Smart healthcare scenarios extensions: ssst : SmartHealthcareScenario A


(ssst : DiseasePrevention A (ssst : Fitness ∧ ssst : workProtection) ∧ ssst :

DiseaseRehabilitation A (ssst : Fitness ∧ssst : OutDoorTherapy) ∧ ssst :

DiseaseMonitoring(ssst : DiseaseMonitoring A ssst : IrhemoScenarios))(5)

3.2.3 Integrated Smart Healthcare Ontology(SHO)

Figure 3.8: High level abstraction diagram for disease-device integration.

The SHO(figure 3.3) is the integration of both the extended SSNO and DO and thesmart healthcare scenarios class and its subclasses. The integration between those twoontologies has been carried out on class granularity. Figure 3.8 represents a high levelof disease- IoT devices integration. The link between diseases and IoT-based healthcareapplications (smart systems) is achieved using object properties. For the experimentspurposes, we used three diseases namely the Asthma disease, Alzheimer’s disease andDiabetes disease. Furthermore, we categorized medical services in different consideredhospitals based diseases or healthcare scenarios specialists. In our prototype, we con-sidered three public hospitals. To link diseases to respective IoT-based healthcare ap-plications and IoT-based healthcare applications to their implemented IoT devices, theObject properties have been extended with new object properties such as, hasAutoma-

3.3. CHAPTER SUMMARY 47

tion, hasDevices, isUsedFor, usesDevices, and isDecribedBy. Some of those Objectsproperties link the diseases to the IoT-based healthcare applications, for example, theAsthma Disease and IoT-based healthcare applications can be linked as follow:DOID : 2841 @ DOID4 ∧ useDevice(ssst : SmartSpiroscoutInhaler ∧ ssst :

SmartP illBox.)(6). Further, the Diabetes disease and respective IoT-based healthcareapplications can be linked also as follow: DOID : 9351 @ DOID4∧usesSmart(ssst :

SmartP illBox ∧ ssst : GlucoMonitoringSystem)(7)And furthermore, the Alzheimer’s disease respective IoT-based healthcare applicationscan be linked as follow:DOID : 10652 @ DOID4 ∧ hasAutomation

(ssst : SmartP illBox∧ ssst : SmartHome.)(8)In addition, the (ssst : hasDevices)helps us to link the IoT-based healthcare applications to the IoT Devices. Let’s havean example of the Smart Life shirt. Therefore, refer to the formula (9) the Vivomet-ricsLifeShirt with is an instance of the mart Life shirt implements the Accelerometer,Healt rate sensor, Blood pressure sensor and ECG. Hence, ssst : SmartLifeshirt A(ssst : V ivometricsLifeShirt ⇒ (usesDevices(ssst : Accelerometer ∧ ssst :

HeartBRate ∧ ssst : BloodPressureSensor ∧ ssst : ECG))) (9)

3.3 Chapter SummaryThis chapter presented the iSEE: a novel Semantic Sensors Selection System for health-care. Thus, we introduced the proposed architecture and its respective layers. It containsfour layers namely the Application layer, the User layer, the Ontology layer and theSystems layer. The first part of this chapter presented the proposed architecture and itslayers. The integrated Smart Healthcare Ontology(SHO) and the used ontologies(SSNOand DO), as well as their integration, have been shown in the second section.

CHAPTER 4

Implementation and Results

4.1 Introduction

The previous chapter presents the iSEE system proposed architecture. This chapterpresents the overview of the implementation and performance results analysis of theiSEE system prototype. The first section of this chapter describes the frameworks thatwe used during the iSEE system implementation, the second section bestows the iSEEsystem prototype, which includes the design of the SHO and development of the pro-totype based on developed SHO. Further, we evaluate the prototype, firstly we evaluatethe SHO using defined Competency Questions(CQs) in both natural and SPARQL querylanguages. Further, the last section evaluates the iSEE system performance based on re-sponse time and reply result-set elements.

4.2 Development Frameworks

The development of iSEE system has been completed in two phases; the first phasecomprises of the elaboration of the SHO and the second phase is about the deploymentof the SHO on a remote server plus the development of the endpoint as a mean of query-ing the SHO. During the first stage, we used Protégé to design and integrate the SHO.Within the second phase, we used Eclipse Luna for the development of the endpoint ap-plication and the Apache Fuseki for the SHO remote deployment. The full developmentand testing processes have been completed on Sony Vaio VPCSE model.

48

4.3. ISEE SYSTEM IMPLEMENTATION 49

4.2.1 Protégé

Protégé is an open-source platform used to create and edit ontologies that can be down-loaded and utilized by anyone. Protégé fully supports the OWL-2 language and RDFspecifications defined by the W3C. It provides a robust and user-friendly interface aswell as more advanced options to work on ontology. Thus, it enables users to save on-tologies in various file extensions, such as RDF, OWL, Turtle, and more. It also hasplug-in support for visualizing ontologies as graphs. For further consistency checking,the Protégé version 5.0.0 and above have a built-in HermiT reasoner. By definition, areasoner is an inference engine that analyses the ontologies consistence. Thus, the rea-soner takes the ontology as input and tries to generate statements and relations from it asoutput. If there are inconsistencies in concepts or properties, the reasoner will indicateyou where these can be found. The installation setup can be found in the appendixessection.

4.2.2 Apache Fuseki Jena

Apache Fuseki Jena is a Semantic Web open source framework for Java which providesan API for both data extraction from and writes to the RDF graphs. The stored triplesare depicted as an abstract model. Thus, a model is referenced as a combination of datafrom database and URLs. A model is thus queried via SPARQL language. Further,Fuseki is a Jena product which is developed as a servlet serving as an HTTP interfaceto RDF/OWL-2 data. It supports as well SPARQL updating.

4.3 iSEE System Implementation

The iSEE system implementation has been carried out in two parts; the first part is thedevelopment of the SHO as an extension of the SSNO and the incorporation of the DOas a human disease glossary. And the second part consists of the elaboration of the iSEEsystem prototype that is based on previously developed SHO. This section describes theimplementation of both the SHO and the iSEE system prototype.

4.3.1 SHO Implementation

During the beginning for the development of the SHO, various techniques have beentested for the development a consistent ontology, and one of those techniques is theguide proposed by Noy and McGuinness in Ontology 101 [108]. The guide describesseven steps that can be utilized during the development process and a mechanism thatcan help the designer to evaluate the generated ontology. As we have already stated that

50 RESULT

at the beginning of this chapter, we used the Protégé IDE to design and manage SHOontology. During the development process, we used several iterations of creations andeditions before reaching the final SHO. The development process comprised of sevensteps proposed by Noy and McGuinness.

• Step1: Determine the domain and scope of the ontology: in the guide providedby Noy and Nathalie, there is a list of questions that their answers help the ontol-ogy designers to determine a precise scope of the ontology. Those questions aimto highlight the domain and scope of the ontology, the purpose of its development,what questions should the information in the ontology answer and stakeholders ofthe developed ontology. For our thesis work, the scope and the domain were fixedfrom the beginning. i.e., we focused on the smart healthcare domain, which com-bines healthcare and IoT- application fields; that implies the combination of thediseases and IoT-based healthcare applications(IoT-devices)help the stakeholdersto select the IoT-based healthcare applications and IoT devices for a particulardisease. As well as the inclusion of metadata for further to get more details aboutthe selected IoT-based healthcare application and devices.

• Step2: Consider reusing existing ontologies: from the beginning of the on-tology development, it’s very beneficial to examine if there are already existingontologies, for either to be helpful as a reference to the current work or as upper-level ontologies. As we described often in the previous sections, we have com-pared various ontologies and because of their richness and robustness, we havechosen to use the DO as a human disease glossary and SSNO as a sensor networkupper-level ontology.

• Step3: Enumerate important terms in the ontology: before start designing theontology, it is crucial to writing down all terminologies that could be useful inan ontology. Because of the wideness of SHO, we cannot enumerate all terms.However, there are key terms such as the DOID, Name and Disease descriptionfrom the DO, system, Physical object, sensing device from the SSNO, and addedkeywords such as Actuating devices, disease monitoring, disease rehabilitationand disease prevention, smart equipment and much more.

• Step 4: Define the classes and the class hierarchy: while developing an on-tology, it is beneficial to take into consideration the hierarchical of super classes.The guide fixes some rules related to the definition of concepts. For, e.g., theclass should contain more than one subclass. Our ontology includes four su-per classes namely, the Disease Ontology(obo: DOID-4), Hospital(ssst:Hospital),Healthcare scenarios(ssst:SmartHealthcareScenarios) and SSNO(ssn:ssno). Fur-


ther, those superclasses subsume other subclasses that serve as umbrella defini-tions for individuals in the subclass. The figure 4.1 shows SHO hierarchy fromProtégé.

Figure 4.1: Tree view of classes in the SHO.

• Step 5: Define the properties of classes and individuals: this step consists ofdefining useful classes properties. The aim is to separate individuals and definetheir ranges and domains. The properties can be specified in two categories suchas data properties(to link individuals and their values), and Object properties todefine how individual functions in relation to others; in this regards, propertieswere added accordingly. Below image describes our objects properties presentedin Protégé.

52 RESULT

Figure 4.2: Tree view of classes object properties in the SHO.

• Step 6: Define the facets of the properties: In ontology engineering, propertiescan have different facets to describe such as supported values, the number of val-ues(cardinality), property inverse. Thus, for, e.g., the properties implementedByand isDescribedBy are an inverse of each other. Therefore, if you add one prop-erty on IoT device and run the reasoner in Protégé, its inverse property will beadded automatically to that IoT device by semantic logic.

• Step 7: Create instances (individuals) individuals are the lowest granulari-ties of the ontology. Thus, individuals have inherited properties from classesthat they belong to.The definition of individuals requires few steps as follow:(1)choose a class of interests, (2)create an instance and (3)finally assign instancesto slots(properties) values. In our ontology instances are IoT devices objects andspecific IoT applications, for e.g. Apple smart watch, is an instance of the smartwatch. And ’hasDevices’ object property links specific IoT application system tothe devices that it implements.


Figure 4.3: Some instances usage with hasDevices object property in the SHO.

4.3.2 Prototype Implementation

For the iSEE system development and validation, we realised the prototype from thepreviously proposed architecture. Since, we are not using physical IoT devices the cur-rent implementation has been carried out in three layers from proposed four layers of theiSEE system architecture namely; the User, Application layer and the Ontology layer.The sequence diagram(figure 4.4) shows the execution flow of the iSEE system.

54 RESULT

Figure 4.4: Sequence diagram of iSEE system components interaction.

• In the proposed architecture, the user layer defines how the stakeholder interactswith the iSEE system application depending on their preferences. In this regards,we created a GUI to allow the stakeholders to use our system in an efficient andfriendly fashion. The GUI was developed using JavaFX libraries. On the fig-ure 4.4, the user interacts with the GUI and in its turn, the GUI sends variousrequests to the Reasoner class based on the user’s preferences and therefore re-ceives the results to present to the user from the reasoner.

• Refer to the iSEE system proposed architecture, the Ontology layer contains SHOtriples hosted on Fuseki Apache Jena to be able to handle SPARQL queries overHTTP, the server can be deployed either on a remote server or locally. For ourprototype implementation, we chose to run the server remotely to enable the ac-cessibility for more than one endpoint application.

• In contrast, the endpoint application development has been carried out at the appli-cation layer. The endpoint application allows the user(through the GUI) to query


the ontology efficiently. The SHO ontology runs on a remote server, and queriesare sent following RESTful style. The endpoint application is built using Javaprogramming language, and it employs Apache Jena library to be able to manipu-late and process semantic data. Moreover, the java application endpoint containsvarious entities such as; the Reasoner entity that represents a set of classes thatdefine the flow of the application runtime, The query engine that is a class to ex-press SPARQL queries in dynamic fashion, and Apache Fuseki server representsthe remote server that hosts the SHO.

Figure 4.5: A typical User-iSEE System interaction.

Further, refer to the sequence diagram(4.4) during the user interaction with the proto-type application, the application flow happens as follow; when the application starts(figure (4.5)), the user selects the entry point of interests(in the Navigation panel of theapplication) such as the location of the hospital, diseases, health care scenarios, and de-vices. Next, assume that the user selected the disease entry, the application returns all

56 RESULT

the available diseases. Further, the user can select the disease of interest. Hence, theiSEE system returns IoT-based healthcare applications that can help the patient sufferingfrom the select disease. Assume that the user selected Asthma disease, the applicationindicates that the patient can use the smart pill box and smart spiroscout inhaler. Fur-thermore, the user can send a request for a list of available specific products for selectedIoT device. Therefore, if the user chooses to use the smart pill box, then the systemreturns the Tricella smart pill box as a particular product of smart pill box. Next, theuser can request details about the selected product. And that will allow the user to com-pare the available products based on the communication protocol, placement and theway devices are controlled as presented in the metadata label of the GUI. Moreover, theuser can go further and check more details about the GPS and BeagleBoard as the IoTdevices that the Tricella smart pill box implements.

4.4 iSEE System Evaluation

This section evaluates and analyses iSEE prototype. As illustrated in the previous partof this chapter, the prototype implementation is composed of the SHO and the endpointapplication. The first subsection of this section deals with the SHO analysis and thesecond subsection benchmarks the performance of the iSEE system as a combination ofboth SHO and the endpoint application.

4.4.1 Evaluation of SHO Correctness

During the development of the SHO we used seven steps, in the first steps, we definedCQ. In this regards, this section evaluates and analyses the developed SHO as a part ofthe iSEE system prototype. The evaluation is carried out using the Competency Ques-tions(CQs) expressed in both natural and SPARQL1 languages. The CQ methodologyis a good way to determine the scope of the ontology, and they have to be defined inthe first step of the previously presented seven steps of the ontology development lifecycle. Further, the defined CQs are used later as a litmus test to check the consistency,completeness and conciseness of the ontology, and evaluate if the ontology contains suf-ficient axioms and information related to the modelled domain. Since our thesis workis motivated by scenarios, we formulated our CQs based on defined scenarios in thefirst chapter. We present a list of fifteen competency questions(Table 4.1) and responsesare thus the interpretation of the results for formulated SPARQL queries. Meanwhile,the SPARQL query syntax comprises two parts namely the namespace with prefixesbindings and the Data descriptions expressed in triples. The first CQ asks about the

1https://www.w3.org/TR/rdf-sparql-query/

4.4. ISEE SYSTEM EVALUATION 57

Table 4.1: A LIST OF COMPETENCY QUESTIONS.

technology that can be used to help a patient with Alzheimer’s disease. The first queryand the query response of the table 4.2 can be used to answer that question. The sameCQ syntax can be used by doctors or other healthcare personnel to select devices thatcan be used to help any patient. Consequently, for instance, a patient with Alzheimer’sdisease can be assisted using the disease monitoring with some mechanisms for moni-toring the instant patient conditions plus behaviour patterns and the smart pill box formedication management.

58 RESULT

Table 4.2: A LIST OF QUERIES AND RESPONSES(1).

The second CQ asks about the network requirements for the motion sensor, the querynumber 4 in table 4.2, can be used to return the query response. The query responseresult-set comprises the name of the device and the throughput requirements. The net-work throughput requirements parameter is expressed using MQTT, HTTP, and COAPprotocol stacks. The difference between those three has been explained in the secondchapter. The motion sensor requires 12.14 kbps when it is connected to the system im-plementing the MQTT protocol stack, 9 kbps for HTTP and 8.3 kbps when CoAP isused. This CQ is mostly beneficial for the second scenario when the caregiver and fam-


ily members aim to get more knowledge about an IoT device and its QoS requirements.Further, the third CQ is used to get a particular product of the smart pill box. This

Table 4.3: A LIST OF QUERIES AND RESPONSES(2).

information is very beneficial for the users since they need to know more about theavailability of products and how they differ. Thus, this CQ response contains the Tri-cella smart pill box as a particular type of smart pill box. The query syntax can beutilised as well to all IoT-based healthcare application systems. The fourth CQ requeststhe smart healthcare scenarios that SHO represents semantically. Therefore, currentavailable smart healthcare scenarios are returned with query number three of queries ta-ble; namely the disease monitoring, disease rehabilitation and disease prevention. Therequested information can be beneficial if the stakeholder needs to know the IoT-based

60 RESULT

healthcare applications used to help in patients monitoring plus rehabilitation activitiesfor the patient after being cured and second scenarios if the stakeholder is interestedin the disease prevention. Besides, as the continuation of the response for the fourthCQ, the fifth CQ can be utilised when a physiotherapist wants to know available reha-bilitation activities to prescribe to a patient after curing a disease. Thus, using the fifthquery of queries table, the tool returns both fitness and outdoor activities. In the sameperspective, the physiotherapist can go further and use the sixth CQ to request about thetechnology that can be utilised for fitness activities. In this case, the sixth query fromthe queries table can be used, and it returns smart watch as an IoT device system usedfor the fitness activities. The same query syntax can also be used for other rehabilitationand prevention activities to request for IoT device systems that can be used in those ac-tivities. Moreover, the stakeholder can be interested in the manufacturer of a particulardevice for further product descriptions search, using the seventh CQ and the seventhquery from the CQs and queries tables, the user can get the related information. In thiscase, the manufacturer of Tricella smart pill box is Tricella Inc.

Furthermore, the stakeholder can also be interested in knowing the particular devicesthat smart systems products implement. In this regards, the eighth query of query tablecan be used to identify IoT devices implemented by Vivometrics life shirt namely theblood pressure sensor, Blood pressure sensor, ECG, Accelerometer and heart rate sen-sors. This query is beneficial if the user wants to have more knowledge about the system,such as the throughput requirements for the constituent IoT devices of the system andthe smart system as such. Furthermore, the user interested in knowing the specific prod-ucts of the smart watch can use the ninth query from table 4.3 to get available smartwatch products on the market. Thus, our SHO currently includes semantically the Ap-ple smart watch as a particular smart watch product.The tenth CQ requests the CoAPrequirements for the smoke detector. Therefore, the query number ten of the contin-uation for the queries table returns thus 8 kbps as CoAP throughput requirements. Itdiffers to the query number four since it only requests CoAP throughput requirementsinstead of all three protocols; CoAP, HTTP and MQTT. The 11th CQ is very crucial forthe third scenario where the Health Department of the company wants to recommendthe work-related diseases prevention application for employees working in mining, thususing the query eleven the ontology proposes to use the smart life shirt. The twelfth CQrequests the what kind of the disease monitoring modelled by the ontology. Thus, usingthe query number twelve the ontology returns three monitoring scenarios, namely thesecurity and basic monitoring, advanced monitoring and basic monitoring. The thirteencompetency question requests services offered at Luleå Hospital. Thus, the query num-ber thirteen replies with represented services provided at Luleå Hospital. And all are re-lated to the disease management systems. Moreover, as a typical example, our ontology


represents semantically three hospitals associated with offered services namely Luleå,Piteå and Skellefteå. Using the same query syntax the user can request services providedat those hospitals respectively. The fourteenth CQ requests the outdoor activities thatcan be helpful for the patient after curing for a disease. Thus, the SHO returns the smartwheelchair. Moreover, In the last CQ, the user asks if the smart pill box He/She wants tobuy can be controlled using his smartphone, using the query, SHO returns the Bluetoothas a communication protocol and the smartphone application(android and ios) as a con-troller. Thus, the compatibility is possible. Finally, based on the above CQs and theirresponses analysis, we conclude that the ontology covers the smart healthcare domain.

4.4.2 Prototype Evaluation

This section evaluates and analyses the iSEE system performance concerning the re-sponse time and the number of the result-set elements. Thus, for each query responsetime, we take into consideration the time it takes to retrieve the information(TT) as thesum of the average (time to send the query(QRstT), Triples Processing Time(TPT) andQuery Response Time(QRspT)). The performance evaluation comprises three experi-ments based on the user’s preferences primary entry point; namely the disease, health-care scenarios and disease. The first subsection of this section illustrates the setup ofthe experiments and the second subsection presents the performance analysis results.

A. Prototype Setup

The iSEE system prototype consists of the SHO and the Java client application devel-oped in Java. The SHO is hosted on apache Jena fuseki running on a remote server, andthe Java application endpoint runs on my laptop computer. As connected to the LTUnetwork the server is assigned the IP address of 130.240.5.93, and the laptop machinegets the IP address of 130.240.157.231. The apache Fuseki server serves RDF data overHTTP.

B. Benchmarking and Data analysis

The performance analysis of iSEE system is judged based on the response time and thenumber of the result-set elements. Thus, refer to the following formula, the average total

62 RESULT

time(TT) for the query response is computed based on the sum of the average of time ittakes to send the query(QRstT) plus the average time for SHO triples processing (TPT)and query response average Time(QRspT). Therefore, based on the user preferences, inthis section we conduct three experiments. Each experiment is composed of a set ofqueries to help a user during the execution flow of the application.The considered Entrypoints are the Health scenarios, Disease, and Hospital location-based services.

1. Entry point as ’Disease’:

Figure 4.6: iSEE system disease entry point.

The figure 4.6 presents the interaction between the User and the iSEE system during thefirst experiment and the graphic 4.7 shows the experiment results, thus, according to theuser preferences, four queries have been issued, the user interacts with the applicationby selecting the keyword of interests(for e.g., Asthma as a disease) in the navigationPanel(fig 4.6). Therefore on the graphic, the amount of time(in milliseconds) is rep-resented by red bars for the average Total Time(TT) and blue for the average TriplesProcessing Time (TPT), and the number of result set elements is represented by orange


bars. Four queries have been used to request available IoT technologies for asthma dis-ease. The first query requests the available diseases. The second query is the numberof technologies that can help the patient with asthma. The third query represents thenumber of the available specific Smart pill box. The fourth query requests the descrip-tion of the Tricella smart pill box and the devices it implements. The figure 4.7 showsclearly that the last query takes a longer time than the fourth query. The main reason isthat the last query returns the Tricella pill box description as well as the IoT devices itimplements namely GPS and BeagleBoard.

Figure 4.7: iSEE system disease entry point(chart).

2. Entry point as ’Smart healthcare scenarios’:

For the second experiment the figure 4.8 presents the interaction between the User andthe iSEE system during this experiment and the graphic 4.9 presents the results of thesecond experiment. Again, for each query, the amount of time(in milliseconds) is rep-resented by red bars for the average Total Time(TT) and blue for the average TriplesProcessing Time (TPT), and the number of result set elements is represented by or-ange bars. During the execution flow, the first query retrieves the available healthcarescenarios. The second query requests the available type of activities for rehabilitationscenario. The third query requests available equipment for fitness activities. The fourthquery requests the available specific smart watches while the fifth query requests thedescription of the apple smart watch. It is clear that the fourth query takes less time thanthe remaining queries since it only returns one result-set element i.e Apple smart watch.

64 RESULT

Figure 4.8: iSEE system Smart healthcare scenarios entry point.

Figure 4.9: iSEE system Smart healthcare scenarios entry point(chart).

3. Entry point as’Hospital Location:’

For the third experiment the figure 4.10 shows the interaction between the User and theiSEE system during this experiment and the graphic 4.11 presents the results of the thirdexperiment. Again, for each query, the amount of time(in milliseconds) is representedby red bars for the average Total Time(TT) and blue bar for the average Triples Process-ing Time (TPT), and the number of result set elements is represented by orange bars.Five queries have been executed against SHO depending on the user preferences, for the


Figure 4.10: iSEE system Hospital Location entry point.

Figure 4.11: iSEE system location entry point(chart).

first query, the user requests for semantically represented hospitals based on their loca-tion. After receiving the result-set for the first query, the user selects Skellefteå Hospitalas the Hospital location entry point to get services offered onto that hospital. Further,the user get interested on asthma and sent the third query to get the technologies. The

66 RESULT

fourth query returns a list of technology to help a patient with Asthma disease suchas the smart pill box. Next, the fourth query returns Tricella smart pill box particularproduct of the Smart pill box. and finally, the fifth query returns the description of theTricella smart pill box.

For the benchmarking and data analysis, we ran many experiments for each entry point,but for the sake of brevity we included three kind experiments to show how stakeholderscan use iSEE system for efficient semantic sensors selection. From all the three exper-iments, it is shown clearly that the query response interval increases depending on thenumber of elements within the query response result-set.

4.5 ConclusionThis chapter described the implementation and the evaluation of the iSEE system pro-totype. The first section presented the framework we used to produce the prototype.Then, the second section evaluated the iSEE system. The evaluation of the iSEE systemhas been conducted in two phases; the first phase consists of the evaluation of the SHOusing Competency Questions(CQs) expressed in both natural and SPARQL languages.After the first phase, we concluded that the SHO covers the smart healthcare domain.Further, the second phase consists the evaluation of the iSEE system as such. In thisphase, we used three experiments to measure the performance of the system based onthe response time and the resultset elements.

CHAPTER 5

Conclusion and Future Work

In the previous chapters of this thesis report, we reviewed the cutting edge technologiesin the smart healthcare domain, explained the proposed iSEE system architecture, anddescribed the implementation and the evaluation of the prototype built based on the pro-posed architecture. In this chapter, we summarize and conclude the main contributionof this thesis. Further, we also present the future research directions based on this work.

5.1 Conclusion

This research work proposed, developed and validated the iSEE system, a semantic sen-sors selection system for healthcare domain. iSEE system enables the stakeholders(e.g.,patients, caregivers, health professionals and other government agencies) to select theIoT devices for a particular disease or health scenarios such as disease prevention. Theproposed iSEE system architecture comprises four layers: the Application layer, Userlayer, Ontology layer and Systems layer. Further, the iSEE prototype was developedfrom the proposed architecture. The prototype development consists of the develop-ment of the smart healthcare(SHO) that represents smart healthcare domain and a Javaapplication used to query the SHO. The SHO is built as an extension to SSNO and iscombined with the Disease Ontology(DO) as human disease glossary. Further, we de-veloped the endpoint application to query the ontology using the apache Jena and Java.Finally, We checked the correctness of the SHO using competency questions(CQs) ex-pressed in both natural and SPARQL query languages. Thus, the competency analysisfound that the ontology covers the smart healthcare domain. The experimental resultsof the prototype based on the query response time depends on a number of elements inthe query response result-set.

67

68 CONCLUSION, DISCUSSION AND FUTURE WORK

5.2 Discussion

This section discusses the holistic summary of the achievements accomplished duringthe research work in the development of the iSEE system. In this research work, sev-eral contributions can be claimed in both practice and theory. The analysis and resultsreached from the evaluation of iSEE system prove well the design utility and researchstrength. A detailed discussion advances different aspects as follow:

5.2.1 Design Output Interpretation

The iSEE system has been presented as an accurate product by adopted rigorous eval-uation and analysis methods. Defined and motivated by scenarios, final evaluation andanalysis demonstrate the utility of the iSEE system in the healthcare sector. Thus, theiSEE system can be used by stakeholders to select IoT devices based on disease orhealthcare scenario of interests.

5.2.2 Objectives Fulfillment

The development and validation work of iSEE system succeeded in the fulfillment ofthe initial objectives of this research defined in the first chapter. The first objective wasto build a SHO to represent the smart healthcare domain semantically. Accordingly,our thesis work has successfully analyzed the smart healthcare domain requirementsand from found requirements, we developed a Smart Healthcare Ontology (SHO) asan extension of Semantic Sensors Network Ontology (SSNO) and incorporating theDisease Ontology (DO) to enable accurate sensors selection for standardized diseasedescriptions. After conducting the evaluation of the SHO using CQs expressed in bothSPARQL and natural languages, we concluded that our objective had been achieved.The second initial objective was to develop a prototype that allows the stakeholdersto use the SHO. Therefore, we proposed iSEE system architecture and from that werealized a prototype that allow users to use the semantic healthcare ontology (SHO)and from that to accurately select and deploy sensors as well as to provide detailedinformation on the selected IoT devices. However, since we don’t stream or display IoTdevice data value or use any physical IoT-based healthcare applications, actual prototypeimplementation has been carried out only in three layers out of four layers.

5.2.3 Contribution to Practice

The thesis work contributes to the practical knowledge that enables the precise integra-tion of healthcare and IoT-based applications domains, as well as the development and

5.3. FUTURE WORK 69

validation of the iSEE system as such. The significance of iSEE to practice includes:(1) Doctors, nurses and other healthcare professionals can recommend the IoT-basedhealthcare applications to patients based on a disease of interests. (2) Caregivers andother patients’ relatives can be allowed to know more detailed information about IoTdevices such, as bandwidth requirements, description, placement, communication pro-tocol, and the manufacturer. (3) The health department within companies and othergovernments agencies can select IoT-based healthcare applications used for diseasesprevention with the purpose of protecting their employees against job-related diseases.(4) The iSEE system can be helpful in hospital finance to be used either in differentaccounting tasks or in getting potential manufacturers to work with insuring customers.Thus, those traits collectively bridges the prior existing gap in IoT devices selectionbased on a disease or healthcare scenario of interest.

5.2.4 Implication of Knowledge

This research work claims that the iSEE system presents an addition to the body ofknowledge by developing the SHO which semantically represents the Smart HealthcareDomain based on the integration of the DO and extended SSNO. The SHO developmentinvolves the definition of terminology for smart healthcare domain that can be reused inthe future. In this regards, our SHO ontology is shared online via SHOntology GitHubrepository (https://github.com/jeanpok8/SHOntology).

5.3 Future workThis research work has designed, developed and validated the iSEE system that containsthe Smart Healthcare Ontology(SHO) to represent the smart healthcare domain seman-tically. Further, the iSEE system comprises as well an endpoint application and the GUIto enable users querying the SHO. As future work, another feature can be added to theiSEE system so that stakeholders can be able to add trending technologies to the sys-tem on their own and from that, additional smart healthcare technologies can be addedto the SHO and mapped to the disease ontology. Further, a mobile application will bedeveloped as part of the iSEE system. Further, we propose that the physical IoT-basedhealthcare applications and IoT devices have to be incorporated as reference to iSEEsystem proposed architecture.

APPENDIX A

Tools deployement

A.1 Protégé Installation

To download the protégé 5.0.0. visit: <http://protege.stanford.edu/products.phpdesktop-protege>A. For windows:

1. Check if Java 8 is installed

2. Download the Protégé ZIP file on the above link

3. Unzip Protégé file and by navigating through folders choose the extraction folder.

4. Protégé will be unzipped to the selected destination into a folder called "Protégé 5.0.0"

5. Launch Protégé by double-click on run.bat file located in Protégé 5.0.0. folder.

B. For Linux:

1. Check if Java 8 is installed

2. Go to the previous link and click the "Download for Linux" button

3. Unzip downloaded file using this command in terminal <tar zxvf protege-5.0.0-linux.tar.gz>

4. Launch Protégé by double-click on run.sh file.

A.2 Fuseki Server Deployment

For full detailed information about the deployment of Fuseki server, please check:<https://github.com/ewg118/xEAC/wiki/Deploying-Fuseki>

70

REFERENCES

[1] K. Tolle, “Ontologies, knowledge management and semantic web at dbis,”September 10, 2014. [Online:Accessed August 2016].

[2] S. Cohen, “Internet of things as the next industrial revolution-how it will changethe industry in 2016,” July 13, 2016. [Online:Accessed August 2016].

[3] A. S. Salgia, K. Ganesan, and A. Raghunath, “Smart pill box,” Indian Journal ofScience and Technology, vol. 8, no. S2, pp. 189–194, 2015.

[4] Tutun Juhana,, “Iot security,” 2016. [Online:accessed August 2016].

[5] z-wave Alliance, “An journey through iot, security and programming,” 2015. ac-cessed 20-August-2016.

[6] M. Ryu, J. Kim, and J. Yun, “Integrated semantics service platform for the inter-net of things: A case study of a smart office,” Sensors, vol. 15, no. 1, pp. 2137–2160, 2015.

[7] M. M. Taye, “Understanding semantic web and ontologies: Theory and applica-tions,” arXiv preprint arXiv:1006.4567, 2010.

[8] K. Janowicz and M. Compton, “The stimulus-sensor-observation ontology de-sign pattern and its integration into the semantic sensor network ontology,” inProceedings of the 3rd International Conference on Semantic Sensor Networks-Volume 668, pp. 64–78, CEUR-WS. org, 2010.

[9] T. McCue, “$117 billion market for internet of things in healthcare by 2020,”August 2016. [Online:Accessed August 2016].

71

72

[10] H. Zheng, C. Nugent, P. McCullagh, Y. Huang, S. Zhang, W. Burns, R. Davies,N. Black, P. Wright, S. Mawson, et al., “Smart self management: assistive tech-nology to support people with chronic disease,” Journal of Telemedicine and Tele-care, vol. 16, no. 4, pp. 224–227, 2010.

[11] H. Zhou, H. Hu, and N. Harris, “Application of wearable inertial sensors in strokerehabilitation,” in Conf Proc IEEE Eng Med Biol Soc, vol. 7, pp. 6825–6828,2005.

[12] C. Gomez and J. Paradells, “Wireless home automation networks: A survey ofarchitectures and technologies,” IEEE Communications Magazine, vol. 48, no. 6,pp. 92–101, 2010.

[13] C. Perera, A. Zaslavsky, P. Christen, M. Compton, and D. Georgakopoulos,“Context-aware sensor search, selection and ranking model for internet of thingsmiddleware,” in 2013 IEEE 14th International Conference on Mobile Data Man-agement, vol. 1, pp. 314–322, IEEE, 2013.

[14] European research cluster on the Internet of Things, “Iot semantic interoperabil-ity:research challenges, best practices,recommendations and next steps,” 2015.[Online:accessed July 2016].

[15] W3C, “Semantic interoperability of health information,” 2016. [Online:accessedJune 2016].

[16] N. Shadbolt, T. Berners-Lee, and W. Hall, “The semantic web revisited,” IEEEintelligent systems, vol. 21, no. 3, pp. 96–101, 2006.

[17] J. De Bruijn, M. Ehrig, C. Feier, F. Martín-Recuerda, F. Scharffe, and M. Weiten,“Ontology mediation, merging and aligning,” Semantic web technologies, pp. 95–113, 2006.

[18] N. Choi, I.-Y. Song, and H. Han, “A survey on ontology mapping,” ACM SigmodRecord, vol. 35, no. 3, pp. 34–41, 2006.

[19] L. M. Schriml, C. Arze, S. Nadendla, Y.-W. W. Chang, M. Mazaitis, V. Felix,G. Feng, and W. A. Kibbe, “Disease ontology: a backbone for disease semanticintegration,” Nucleic acids research, vol. 40, no. D1, pp. D940–D946, 2012.

[20] M. Chui, M. Löffler, and R. Roberts, “The internet of things,” McKinsey Quar-terly, vol. 2, no. 2010, pp. 1–9, 2010.

73

[21] R. E. Glasgow, L. Ruggiero, E. G. Eakin, J. Dryfoos, and L. Chobanian, “Qualityof life and associated characteristics in a large national sample of adults withdiabetes,” Diabetes care, vol. 20, no. 4, pp. 562–567, 1997.

[22] R. Wootton, “Twenty years of telemedicine in chronic disease management–anevidence synthesis,” Journal of telemedicine and telecare, vol. 18, no. 4, pp. 211–220, 2012.

[23] A. Darkins, P. Ryan, R. Kobb, L. Foster, E. Edmonson, B. Wakefield, and A. E.Lancaster, “Care coordination/home telehealth: the systematic implementation ofhealth informatics, home telehealth, and disease management to support the careof veteran patients with chronic conditions,” Telemedicine and e-Health, vol. 14,no. 10, pp. 1118–1126, 2008.

[24] N. D. D. Group et al., “Classification and diagnosis of diabetes mellitus and othercategories of glucose intolerance,” Diabetes, vol. 28, no. 12, pp. 1039–1057,1979.

[25] C. A. M. Program, C. Ober, D. L. Nicolae, M. C. C. A. S. (MCAAS, et al., “Meta-analysis of genome-wide association studies of asthma in ethnically diverse northamerican populations,” Nature genetics, vol. 43, no. 9, pp. 887–892, 2011.

[26] J. Kang, H.-G. Lemaire, A. Unterbeck, J. M. Salbaum, C. L. Masters, K.-H.Grzeschik, G. Multhaup, K. Beyreuther, and B. Müller-Hill, “The precursor ofalzheimer’s disease amyloid a4 protein resembles a cell-surface receptor,” 1987.

[27] J. D. Keith, “Congestive heart failure,” Pediatrics, vol. 18, no. 3, pp. 491–500,1956.

[28] A. J. Jara, M. A. Zamora, and A. F. Skarmeta, “An internet of things–based per-sonal device for diabetes therapy management in ambient assisted living (aal),”Personal and Ubiquitous Computing, vol. 15, no. 4, pp. 431–440, 2011.

[29] PCWorld, “Gps inhaler tracks your every asthma attack,” 2011. [Online; accessed19-June-2016].

[30] S. Jeong, Y.-W. Kim, and C.-H. Youn, “Personalized healthcare system forchronic disease care in cloud environment,” ETRI Journal, vol. 36, no. 5, pp. 730–740, 2014.

[31] J. R. Menard, H. E. Smith, D. Riebe, C. M. Braun, B. Blissmer, and R. B. Patter-son, “Long-term results of peripheral arterial disease rehabilitation,” Journal ofvascular surgery, vol. 39, no. 6, pp. 1186–1192, 2004.

74

[32] S. Mendis, P. Puska, B. Norrving, et al., Global atlas on cardiovascular diseaseprevention and control. World Health Organization, 2011.

[33] U. S. P. H. S. O. of the Surgeon General, C. for Disease Control, P. (US), N. C.for Chronic Disease Prevention, H. P. (US), P. ident’s Council on P hysical Fit-ness, and S. (US), Physical activity and health: a report of the Surgeon General.Government Printing Office, 1996.

[34] B. P. Clarkson, Life patterns: structure from wearable sensors. PhD thesis, Cite-seer, 2002.

[35] S. Tachakra, X. Wang, R. S. Istepanian, and Y. Song, “Mobile e-health: theunwired evolution of telemedicine,” Telemedicine Journal and E-health, vol. 9,no. 3, pp. 247–257, 2003.

[36] S. Patel, H. Park, P. Bonato, L. Chan, and M. Rodgers, “A review of wearable sen-sors and systems with application in rehabilitation,” Journal of neuroengineeringand rehabilitation, vol. 9, no. 1, p. 1, 2012.

[37] M. Sung, C. Marci, and A. Pentland, “Wearable feedback systems for rehabilita-tion,” Journal of neuroengineering and rehabilitation, vol. 2, no. 1, p. 1, 2005.

[38] D. Tacconi, R. Tomasi, C. Costa, and O. Mayora, “A system for remote orthope-dics rehabilitation,” in 2013 7th International Conference on Pervasive Comput-ing Technologies for Healthcare and Workshops, pp. 313–314, IEEE, 2013.

[39] J. Akana, B. K. Andre, S. Aoyagi, A. M. Ashcroft, J. Bataillou, D. J. Coster,D. De Iuliis, M. E. Hankey, J. Hoenig, R. P. Howarth, et al., “Wearable device,”Aug. 25 2015. US Patent D737,159.

[40] D. Anzaldo, “Wearable sports technology??? market landscape and compute soctrends,” in 2015 International SoC Design Conference (ISOCC), pp. 217–218,IEEE, 2015.

[41] R. M. Davis and R. E. Gomez, “Wear next: An exploration into the future ofwearable technology,” 2015.

[42] K.-H. Chen, P.-C. Chen, K.-C. Liu, and C.-T. Chan, “Wearable sensor-based re-habilitation exercise assessment for knee osteoarthritis,” Sensors, vol. 15, no. 2,pp. 4193–4211, 2015.

75

[43] J. Brutovsky and D. Novak, “Low-cost motivated rehabilitation system for post-operation exercises,” IEEE Eng Med and Biol Soc, New York, pp. 6663–6666,2006.

[44] R. Billies, “Internet of things 2016,” 2016.

[45] M. Yu, A. Rhuma, S. M. Naqvi, L. Wang, and J. Chambers, “A posturerecognition-based fall detection system for monitoring an elderly person ina smart home environment,” IEEE transactions on information technology inbiomedicine, vol. 16, no. 6, pp. 1274–1286, 2012.

[46] D. Litvak, Y. Zigel, and I. Gannot, “Fall detection of elderly through floor vi-brations and sound,” in 2008 30th Annual International Conference of the IEEEEngineering in Medicine and Biology Society, pp. 4632–4635, IEEE, 2008.

[47] H. Foroughi, B. S. Aski, and H. Pourreza, “Intelligent video surveillance formonitoring fall detection of elderly in home environments,” in Computer andInformation Technology, 2008. ICCIT 2008. 11th International Conference on,pp. 219–224, IEEE, 2008.

[48] X. Yu, “Approaches and principles of fall detection for elderly and patient,” ine-health Networking, Applications and Services, 2008. HealthCom 2008. 10thInternational Conference on, pp. 42–47, IEEE, 2008.

[49] R. O. Launey, P. A. Grendler, D. L. Packham, J. M. Battaglia, and H. E. Levine,“Expandable home automation system,” Feb. 4 1992. US Patent 5,086,385.

[50] R. Harper, Inside the smart home. Springer Science & Business Media, 2006.

[51] M. Chan, E. Campo, D. Estève, and J.-Y. Fourniols, “Smart homes-current fea-tures and future perspectives,” Maturitas, vol. 64, no. 2, pp. 90–97, 2009.

[52] S. Martin, G. Kelly, W. G. Kernohan, B. McCreight, and C. Nugent, “Smarthome technologies for health and social care support,” Cochrane Database SystRev, vol. 4, 2008.

[53] T. Zhang, J. Wang, P. Liu, and J. Hou, “Fall detection by embedding an ac-celerometer in cellphone and using kfd algorithm,” International Journal of Com-puter Science and Network Security, vol. 6, no. 10, pp. 277–284, 2006.

[54] J. Chen, K. Kwong, D. Chang, J. Luk, and R. Bajcsy, “Wearable sensors for re-liable fall detection,” in Engineering in Medicine and Biology Society, pp. 3551–3554, 2005.

76

[55] J. Hwang, J. Kang, Y. Jang, and H. Kim, “Development of novel algorithm andreal-time monitoring ambulatory system using bluetooth module for fall detectionin the elderly,” in Engineering in Medicine and Biology Society, 2004. IEMBS’04.26th Annual International Conference of the IEEE, vol. 1, pp. 2204–2207, IEEE,2004.

[56] M. Yefimova and D. L. Woods, “Using sensor technology to monitor disruptivebehavior of persons with dementia.,” in AAAI Fall Symposium: Artificial Intelli-gence for Gerontechnology, 2012.

[57] M. K. Ngo, “Sensor communication in smart cities and regions: An efficientiot-based remote health monitoring system,”

[58] H.-L. Kim, Y.-H. Kim, and Y.-J. Kim, “Miniature electrocardiography sensor us-ing a flexible printed circuit and mems technology,” in Multisensor Fusion andIntegration for Intelligent Systems, 2008. MFI 2008. IEEE International Confer-ence on, pp. 545–550, IEEE, 2008.

[59] E. Nemati, M. J. Deen, and T. Mondal, “A wireless wearable ecg sensor for long-term applications,” IEEE Communications Magazine, vol. 50, no. 1, pp. 36–43,2012.

[60] R. Fensli, E. Gunnarson, and T. Gundersen, “A wearable ecg-recording systemfor continuous arrhythmia monitoring in a wireless tele-home-care situation,”in 18th IEEE Symposium on Computer-Based Medical Systems (CBMS’05),pp. 407–412, IEEE, 2005.

[61] E. Vavrinsky, M. Darícek, M. Donoval, K. Rendek, F. Horínek, M. Horniak,and D. Donoval, “Design of emg wireless sensor system,” in Applied Electronics(AE), 2011 International Conference on, pp. 1–4, IEEE, 2011.

[62] W.-Y. Chung, Y.-D. Lee, and S.-J. Jung, “A wireless sensor network compatiblewearable u-healthcare monitoring system using integrated ecg, accelerometer andspo 2,” in 2008 30th Annual International Conference of the IEEE Engineeringin Medicine and Biology Society, pp. 1529–1532, IEEE, 2008.

[63] Y.-D. Lee, S.-J. Jung, Y.-S. Seo, and W.-Y. Chung, “Measurement of motionactivity during ambulatory using pulse oximeter and triaxial accelerometer,” inConvergence and Hybrid Information Technology, 2008. ICCIT’08. Third Inter-national Conference on, vol. 1, pp. 436–441, IEEE, 2008.

77

[64] A. Purwar, D. U. Jeong, and W. Y. Chung, “Activity monitoring from real-timetriaxial accelerometer data using sensor network,” in Control, Automation andSystems, 2007. ICCAS’07. International Conference on, pp. 2402–2406, IEEE,2007.

[65] K. W. Fok, “Heart rate sensor,” 2015.

[66] E. G. Price and L. C. Rasmussen, “Wearable heart rate monitor,” Apr. 1 1980. USPatent 4,195,642.

[67] S. Venkatraman and S. G. J. Yuen, “Wearable heart rate monitor,” Feb. 3 2015.US Patent 8,945,017.

[68] P. Bonato et al., “Wearable sensors/systems and their impact on biomedical en-gineering,” IEEE Engineering in Medicine and Biology Magazine, vol. 22, no. 3,pp. 18–20, 2003.

[69] B. G. Steele, B. Belza, K. Cain, C. Warms, et al., “Bodies in motion: monitoringdaily activity and exercise with motion sensors in people with chronic pulmonarydisease,” Journal of rehabilitation research and development, vol. 40, no. 5, p. 45,2003.

[70] V. Jakkula, D. J. Cook, et al., “Anomaly detection using temporal data mining ina smart home environment,” Methods of information in medicine, vol. 47, no. 1,pp. 70–75, 2008.

[71] L. Ho, M. Moh, Z. Walker, T. Hamada, and C.-F. Su, “A prototype on rfid andsensor networks for elder healthcare: progress report,” in Proceedings of the 2005ACM SIGCOMM workshop on Experimental approaches to wireless network de-sign and analysis, pp. 70–75, ACM, 2005.

[72] C.-J. Li, L. Liu, S.-Z. Chen, C. C. Wu, C.-H. Huang, and X.-M. Chen, “Mobilehealthcare service system using rfid,” in Networking, Sensing and Control, 2004IEEE International Conference on, vol. 2, pp. 1014–1019, IEEE, 2004.

[73] E. W. Ngai, J. Poon, F. Suk, and C. Ng, “Design of an rfid-based healthcaremanagement system using an information system design theory,” InformationSystems Frontiers, vol. 11, no. 4, pp. 405–417, 2009.

[74] R. Paradiso, G. Loriga, and N. Taccini, “A wearable health care system basedon knitted integrated sensors,” IEEE Transactions on Information Technology inBiomedicine, vol. 9, no. 3, pp. 337–344, 2005.

78

[75] A. Pantelopoulos and N. G. Bourbakis, “A survey on wearable sensor-based sys-tems for health monitoring and prognosis,” IEEE Transactions on Systems, Man,and Cybernetics, Part C (Applications and Reviews), vol. 40, no. 1, pp. 1–12,2010.

[76] Y.-D. Lee and W.-Y. Chung, “Wireless sensor network based wearable smart shirtfor ubiquitous health and activity monitoring,” Sensors and Actuators B: Chemi-cal, vol. 140, no. 2, pp. 390–395, 2009.

[77] D.-O. Kang, H.-J. Lee, E.-J. Ko, K. Kang, and J. Lee, “A wearable contextaware system for ubiquitous healthcare,” in Engineering in Medicine and Biol-ogy Society, 2006. EMBS’06. 28th Annual International Conference of the IEEE,pp. 5192–5195, IEEE, 2006.

[78] D. O. Olguin, P. A. Gloor, and A. Pentland, “Wearable sensors for pervasivehealthcare management,” in 2009 3rd International Conference on PervasiveComputing Technologies for Healthcare, pp. 1–4, IEEE, 2009.

[79] K. Hung, Y. Zhang, and B. Tai, “Wearable medical devices for tele-home health-care,” in Engineering in Medicine and Biology Society, 2004. IEMBS’04. 26thAnnual International Conference of the IEEE, vol. 2, pp. 5384–5387, IEEE, 2004.

[80] A. Darwish and A. E. Hassanien, “Wearable and implantable wireless sensornetwork solutions for healthcare monitoring,” Sensors, vol. 11, no. 6, pp. 5561–5595, 2011.

[81] B. Zhang, S. Jiang, D. Wei, M. Marschollek, and W. Zhang, “State of the art ingait analysis using wearable sensors for healthcare applications,” in Computerand Information Science (ICIS), 2012 IEEE/ACIS 11th International Conferenceon, pp. 213–218, IEEE, 2012.

[82] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, andT. Berners-Lee, “Hypertext transfer protocol–http/1.1,” tech. rep., 1999.

[83] A. Stanford-Clark and H. L. Truong, “Mqtt for sensor networks (mqtt-s) proto-col specification,” International Business Machines Corporation version, vol. 1,2008.

[84] Z. Shelby, K. Hartke, and C. Bormann, “The constrained application protocol(coap),” tech. rep., 2014.

[85] Y. Rodriguez and B. Garcia, “Programmable multi-function z-wave adapter forz-wave wireless networks,” Feb. 14 2012. US Patent 8,117,362.

79

[86] E. Monton, J. F. Hernandez, J. M. Blasco, T. Hervé, J. Micallef, I. Grech, A. Brin-cat, and V. Traver, “Body area network for wireless patient monitoring,” IETcommunications, vol. 2, no. 2, pp. 215–222, 2008.

[87] J. Bray and C. F. Sturman, Bluetooth 1.1: connect without cables. pearson Edu-cation, 2001.

[88] L. B. Del Mundo, R. L. D. Ansay, C. A. M. Festin, and R. M. Ocampo, “Acomparison of wireless fidelity (wi-fi) fingerprinting techniques,” in ICTC 2011,pp. 20–25, IEEE, 2011.

[89] Association. CC-BY-SA, “Semantic interoperability of health information,”2011. [Online:accessed July 2016].

[90] A. Gyrard, C. Bonnet, and K. Boudaoud, “Domain knowledge interoperability tobuild the semantic web of things,” 2014.

[91] H. Mihoubi, A. Simonet, and M. Simonet, “An ontology driven approach to on-tology translation,” in International Conference on Database and Expert SystemsApplications, pp. 573–582, Springer, 2000.

[92] C. Bizer, T. Heath, and T. Berners-Lee, “Linked data-the story so far,” SemanticServices, Interoperability and Web Applications: Emerging Concepts, pp. 205–227, 2009.

[93] D. Fensel, D. McGuiness, E. Schulten, W. K. Ng, G. P. Lim, and G. Yan, “Ontolo-gies and electronic commerce,” IEEE Intelligent Systems, vol. 16, no. 1, pp. 8–14,2001.

[94] M. Paolucci, T. Kawamura, T. R. Payne, and K. Sycara, “Semantic matching ofweb services capabilities,” in International Semantic Web Conference, pp. 333–347, Springer, 2002.

[95] C. Ghidini and F. Giunchiglia, “A semantics for abstraction,” 2003.

[96] M. Schorlemmer and Y. Kalfoglou, “Progressive ontology alignment for meaningcoordination: An information-theoretic foundation,” in Proceedings of the fourthinternational joint conference on Autonomous agents and multiagent systems,pp. 737–744, ACM, 2005.

[97] F. Giunchiglia, P. Shvaiko, and M. Yatskevich, “Semantic schema matching,”in OTM Confederated International Conferences" On the Move to MeaningfulInternet Systems", pp. 347–365, Springer, 2005.

80

[98] Y. Kalfoglou and M. Schorlemmer, “If-map: An ontology-mapping methodbased on information-flow theory,” in Journal on data semantics I, pp. 98–127,Springer, 2003.

[99] R. Neches, R. E. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator, and W. R.Swartout, “Enabling technology for knowledge sharing,” AI magazine, vol. 12,no. 3, p. 36, 1991.

[100] E. Rahm and P. A. Bernstein, “A survey of approaches to automatic schemamatching,” the VLDB Journal, vol. 10, no. 4, pp. 334–350, 2001.

[101] M. Vargas-Vera and M. Nagy, “State of the art on ontology alignment,” Interna-tional Journal of Knowledge Society Research (IJKSR), vol. 6, no. 1, pp. 17–42,2015.

[102] J. Euzenat, P. Shvaiko, et al., Ontology matching, vol. 18. Springer, 2007.

[103] J. Euzenat, P. Valtchev, et al., “Similarity-based ontology alignment in owl-lite,”in ECAI, vol. 16, p. 333, 2004.

[104] P. Lambrix and H. Tan, “A tool for evaluating ontology alignment strategies,” inJournal on data semantics VIII, pp. 182–202, Springer, 2007.

[105] C. Roussey, F. Pinet, M. A. Kang, and O. Corcho, “An introduction to ontologiesand ontology engineering,” in Ontologies in Urban Development Projects, pp. 9–38, Springer, 2011.

[106] V. Mascardi, P. Rosso, and V. Cordì, “Enhancing communication inside multi-agent systems* an approach based on alignment via upper ontologies,” 2007.

[107] J. Hodges, M. Kritzler, F. Michahelles, S. Lueder, and E. Wilde, “Ontology align-ment for wearable devices and bioinformatics in professional health care,”

[108] N. F. Noy, D. L. McGuinness, et al., “Ontology development 101: A guide tocreating your first ontology,” 2001.

Documents

iSEE:A Semantic Sensors Selection System for Healthcareltu.diva-portal.org/smash/get/diva2:1033985/FULLTEXT01.pdf · iSEE:A Semantic Sensors Selection System for Healthcare Jean Paul