Semantic Remote Patient Monitoring System

Abstract

We propose an automated and personalized remote patient monitoring (RPM) system, which is applied to care homes and is dependent on the manipulation of semantics describing situations during patient monitoring in ontological models. Decision making in RPM is based on reasoning performed upon ontologies, which secures the delivery of appropriate e-health services in care homes. Our working experiment shows an example of preventive e-healthcare, but it can be extended to any situation that requires either urgent action from healthcare professionals or a simple recommendation during RPM. We use Semantic Web technology and OWL/SWRL-enabled ontologies to illustrate the proposal and feasibility of implementing this RPM system as a software solution in pervasive healthcare. It will be of interest to healthcare professionals, who can directly shape and populate the proposed ontological model, and software engineers, who would consider using OWL/SWRL when creating e-health services in general.

Introduction

In the last 10 years, telemedicine and e-health have played a very important role in changing the way we deliver and consume healthcare services. We have been aiming to increase the efficiency of our healthcare systems, address the prevention of diseases that are affecting societies around the globe, and support governments and healthcare bodies that deal with our aging population and high healthcare costs. Telemedicine did deliver its early promises to revolutionize healthcare through communication technologies, intelligent software systems that support e-health, and changes in our societies in terms of adopting new technologies in our everyday lives. We are now able to turn our traditional general practitioner's surgeries, clinical interventions, patient monitoring, and public health protection into remote e-health services, delivered at any time, in any place, and with the involvement of empowered patients interested in management and self-management of their health.

Consequently, home care services, as the answer to demands of our modern lives, have improved dramatically, and telemedicine in particular has played a very important role in creating automated software systems that support remote patient monitoring (RPM).^1

–5 Thus, whether being a routine check-up, a proactive response to physiological anomalies, managing curative or palliative healthcare, or providing basic preventive health instructions, RPM has an important role in delivering modern healthcare. However, software solutions that automate RPM have been, by and large, technology driven.^6

–9 Some of them might have patient involvement and more patent-oriented aspects in terms of providing feedback and recommendations and awaiting their response, some might be personalized to provide patient-specific services and information, and some might be generic (i.e., they can fit any environment for RPM). However, healthcare technologies in RPM where an individual's physiological, behavioral, and general personal profiles do not have any role in the RPM decision-making process at best may be considered as passive monitoring systems.

This article proposes a software solution that automates a personalized RPM system and secures the delivery of e-health services based on the manipulation of semantics defined in RPM, through Semantic Web technologies. The purpose of this article is twofold:

1. We would like to demonstrate how this RPM system can serve healthcare practitioners by creating e-health environments that support preventive and curative healthcare at the same time and personalize e-healthcare services.

2. We would like to create an automated RPM system that puts forward, apart from requirements from (1), a patient's profile, including parameters such as preferences, physiology, and behavior, and consequently develop a software solution that can interpret the semantics of RPM and describe every situation in RPM, for the purpose of delivering e-health services.

Our software solution from (2) has to exhibit a certain level of intelligence, which would mean that we will have to pay attention to both models that define and manipulate the semantics of RPM systems and software technologies that deploy the proposed model and create e-health environments where RPM can operate.

This article will attract two different types of audience because it is very difficult to create effective RPM systems without constant collaboration between them. It will first be useful for an audience of healthcare practitioners who (a) are in the position to use RPM systems for a variety of reasons and purposes, as in (1) above, and (b) can contribute toward a full-scale generation of the domain knowledge [i.e., semantics of RPM as stated in (2) above]. Second to be in involved is an audience of software engineers who work on the creation of e-health services as software solutions and who are interested in our novel approach to define and manipulate the semantics of RPM solely as a software application powered by modern semantic technologies and OWL/SWRL¹⁰-enabled computational spaces.

This article is a continuation of our research on the self-care home (SeCH) from Figure 1, which accommodates RPM and in turn delivers e-health services as a software solution based on the assistive self-care system (ASeCS) architectural model as shown in Figure 2.^11

–14 It is important to note that e-health services are always based on decision making within a particular RPM system, which are triggered by different situations it may find within SeCH. Our RPM system monitors people in various environments; therefore it should be able to detect a particular situation as a result of changes in the environment and react to it. Consequently, the automation of RPM means appropriate decision making when delivering e-health services.

Fig. 1.

Self-care home environment to feed the assistive self-care system (ASeCS) supporting the remote patient monitoring system. LAN, local area network; WAN, wide area network.

Fig. 2.

The architecture of the self-care system.

In Materials and Methods we introduce the scenario of an RPM system in the SeCH and explain its main functionalities of delivering e-health services. In The Proposal we describe the way we created the semantics of and expectations from the RPM and store these in an ontological model, SeCHOnto. In Decision Making in the RPM System we illustrate our reasoning with SeCHOnto concepts in order to make decisions on which action has to be taken by the RPM system. The running example shows an experiment of delivering preventive e-healthcare, by recommending an action for residents to prevent deterioration of their health. We could not find any related work that automates RPM based on OWL/SWRL-enabled computational spaces. In Related Works we overview the publications that either concern RPM or may have impact on our research in the future. In Results we draw attention to the outcome of the proposal and the running example, and in Conclusions we highlight our contribution to future works.

Materials and Methods

THE SCENARIO

Margaret, John, Peter, Ann, and Paul are residents of SeCH homes that accommodate people in constant care who have health conditions that require medical attention or senior citizens who require constant support. They have agreed to be monitored through RPM, but they have stated their preferences in terms of keeping the RPM system less intrusive and more personalized to their needs.

Margaret's morning routine starts every day with having a shower, followed by breakfast. She then takes her medicine and either watches TV, walks around the local park, or undertakes any other activity. Sensors and tags embedded into the SeCH, as shown in Figure 1, feed the RPM system with data of her precise location (“Is Margaret still in her bed?”), time when she took her medicine (“Did she take the medication at 9 a.m.”), information on whether she has been dressed properly (“Is she wearing a coat while she is outside her home”), etc. Vital signs such as body temperature, blood pressure, or heartbeat are measured through sensorized garments and streamlined to the software application that supports the RPM system. Decision making in the RPM system involves

• issuing alarms to healthcare professionals for urgent attention because Margaret's vital signs show abnormal values.

• issuing alarms to healthcare professionals for urgent attention because Margaret has an occurrence of hyperglycemia. Therefore a nurse or a doctor on duty has to make a visit and administer medication.

• recommending adjustments to Margaret's current blood pressure medication if her blood pressure readings do not stabilize during a required period of time.

• recommending a simple advice to Margaret to “get back to the care home quickly” because she has a fever, and it is risky to stay too long outside during wintertime.

• automatically switching on the heater in Margaret's room after detecting the location's temperature to be relatively cold compared with Margaret's body temperature, and she would rather have a very warm room than wear more clothes.

• automatically displaying a street map on Margaret's mobile communication device when she happens to be far away from her care home.

The scenario and bullet points above show the spectrum of functionalities that should exist in our RPM system. When the RPM detects a change in an SeCH environment, it should be able to make a decision on which functionality should be performed in that particular situation. The following three RPM functions in the bullets above systemize the e-health services delivered by the RPM:

1. Issuing an alarm for the medical staff on duty because urgent attention is needed.

2. Recommending measures that can prevent deterioration of resident's health.

3. Activating devices within the SeCH automatically without the resident's involvement that can prevent deterioration of the resident's health.

Therefore, it is expected that the RPM system will be capable of indicating

i. who should be acted upon in the SeCH: who are the residents who need urgent attention, might be given recommending measures for protecting their health, or have devices within the SeCH activated.

ii. which automated e-health service or services is or are expected in a particular situation (i.e., should the RPM system issue urgent attention alarms, give recommendations, or automatically activate devices that surround residents?).

iii. which preferences in terms of the delivery of e-health service through the RPM system are important for residents.

The Proposal

The purpose of our research is to demonstrate the feasibility of creating a software application, generated from ASeCS architecture given in Figure 2, that automates the RPM system and secures the delivery of e-health services, as described in (1)–(3) from the Scenario. The RPM system makes provision for curative healthcare as in (1) and (3) and preventive healthcare as in (2) and (3) above. Therefore the efficacy and adoption of the RPM system by their users (residents and healthcare practitioners) will depend on our way of creating a computational solution from the ASeCS architecture that automates the RPM and our ability to define and manipulate the semantics of the RPM. We need a clear explanation of the meaning of

A. the purpose, characteristics, and functionalities of any object involved in RPM, such as medical instruments, communication devices, heaters, furniture, and clothes

B. the roles, activities, and interests of any person involved in RPM systems, such as residents, caregivers, nurses, and doctors

C. the relationship or relationships between objects and people involved in RPM and their interaction, which creates various situations in SeCH

because they are all prerequisites for the decision making in the RPM system.

We propose a software application for supporting the RPM system based on a computational model or models that accommodate the prerequisites (A)–(C) above. Therefore our software application depends on an ontological model, SeCHOnto, from the ontological layer in Figure 2. If we wish to secure decision making in RPM, then we must perform reasoning upon SeCHOnto concepts, which ultimately delivers e-health services. In other words, concepts from SeCHOnto will enable decision making in the RPM system by running reasoning rules, which will in turn result in (1) issuing an alarm, (2) recommending measures, and (3) activating devices as in the Scenario.

SeCHOnto is in the core layer of ASeCS and represents our domain of interest generated from various situations within the SeCH, such as “Margaret is feverish today, but she has decided to walk in the park after the breakfast, in spite of low winter temperatures.” This particular situation—“Margaret is outside,” “outside temperature is low,” and “Margaret is feverish”—is recorded within the Context Layer of ASeCS, which stores context-generated data: location and temperature from sensors. It is important to note that the exact collection of contextual data and its interpretation within repositories of the Context Layer of the ASeCS are outside the scope of this article and is subject of a different research domain. It is feasible, however, to transform contextual data into an ontological format,^15

–20 which can then fit our ASeCS core ontological layer and derive the reasoning mechanism we need for decision making. In the next section we describe the semantics of the RPM system stored in SeCHOnto.

Sechonto

Figure 3 shows an excerpt from the SeCHOnto. When defining the semantics of the RPM system we should have Person, Location, Object, and Setting as root classes of its ontological model. These describe people involved in the RPM, objects essential for the functioning of RPM, and locations where people and objects happen to be. The Setting class corresponds to situations in RPM where different combinations of people/objects/locations cohabitate. Consequently, its subclass LPO is the mirror of such situations. HealthcareDomain is one of the Setting subclasses that permits us to store the exact semantics of the SeCH and the RPM system (HealthCondition/RequiredAction/VitalSignsMeasurement). Finally, we have to take into account that the LPO subclass describes static conditions within various situations (“Margaret is outside the home with a mobile communicator device in her pocket”), but PersonActivity subclass will address the exact activity a person undertakes in a particular moment (“Margaret is taking her daily insulin injection”), and PersonPreference class will contain semantics that characterize the specific profile of every person involved in RPM and makes it a less intrusive monitoring environment. We can take into account various preferences such as “Margaret does not wish to be monitored when guests are in her house,” “Margaret has agreed to carry a communication device whenever she leaves home,” or “Margaret would rather have her heater automatically turned on, than wearing more clothes, when the temperature in her room is lower than her temperature.”

Fig. 3.

An excerpt from the ontological model of the self-care home. LOP, superclass of all classes related to any two of Location, Object, and Person.

However, the classes from Figure 3 are not sufficient to carry the semantics needed for decision making in the RPM system [see prerequisites (A)–(C) from the previous section]. Figure 4 shows how we may extend the existing hierarchies of SeCHOnto into horizontal subclasses, in order to describe the RPM in a particular situation. Therefore our swim lanes in Figure 4 show where horizontal extensions of SeCHOnto hierarchies occur. Most of them are self-explanatory: EnabledUser is a resident in the SeCH, and Coat is an example of an Object of type Clothes. We define Feverish as a HealthCondition and MakingRecommendation as a type of RequiredAction in the RPM. When looking at subclasses of the LPO class, we have decided to show only two combinations: PersonObject and PersonLocation. Both subclasses are sufficient to explain that we are, for example, modeling situations when we need to know which object is worn by a resident and that the location where the resident is detected is away from his or her home.

Fig. 4.

Excerpt of the ontological model of the self-care home for a particular situation.

Decision Making in the RPM System

Satisfying Prerequisites for Decision Making

We have already emphasized that decision making in RPM systems is always dependent on specific situation when changes in the SeCH environment occur. Therefore the functionality of the RPM system should always guarantee answers to various questions we impose in RPM, which are triggered by changes in SeCH environment and which ultimately secure the delivery of appropriate e-health services.

We have already indicated in (i)–(iii) from the Scenario which questions should be asked and answered as a part of the decision-making process in RPM. However, a more detailed example that describes a change of situation in SeCH and poses a question essential for decision making is given in Table 1. It is expected that the RPM system will “react” to the fact that there are a few residents who are feverish and outside their homes by making the decision to “recommend” these residents to go back to their care home.

The semantics from the question in Table 1 have to be transferred into SeCHOnto [i.e., SeCHOnto concepts should accommodate as much semantics from the question as possible, as indicated in the decision-making prerequisites (A) and (B)]. In Table 2 we illustrate the mapping between

Table 1.

Specific Question for a Particular Situation

Who should be acted upon (remote patient monitoring system need the names of residents) in cases when the system detects that there are a few feverish persons who decided to leave their homes after the breakfast (i.e., they are now in “outside locations” [such as an open area in a local park]), but all of them are wearing their coats. This is a case where giving recommendation might be needed, because it is not advisable for feverish people to stay outside for long even if they had thought that a short stroll across the park would be ”safe” because they had put their coat on!

Table 2.

Mapping of the Situation-Specific Question with Classes of Ontological Model of the Self-Care Home

Who should be acted upon in cases when the system detects that there are a few feverish persons who decided to leave their homes after the breakfast (i.e., they are now in “outside locations” such as an open area in a local park, but all of them are wearing their coats). These are the case where giving recommendation might be needed, because it is not advisable for feverish people to stay outside for long even if they think that a short stroll across the park will be ”safe” because they put their coats on!	Who→EnabledUser
	in cases→Setting
	feverish→Feverish
	is in→PersonLocation
	outside location→OutsideLocation
	open area→OpenArea
	wearing→WearingObject
	coat→Coat
	giving recommendation→MakingRecommendation

• the words that appear in the question from Table 1 and

• the classes that exist in SeCHOnto from Figure 4.

In other words, Table 2 shows how vocabulary from the question is substituted with subclasses of SeCHOnto. The mapping also represents the justification for extending the initial SeCHOnto classes from Figure 3 into horizontal hierarchies of its subclasses in Figure 4. Therefore, Figure 4 shows a version of the SeCHOnto that satisfies prerequisites (A) and (B) for decision making.

In order to satisfy prerequisite (C) and secure reasoning upon SeCHOnto, we must describe relationships between concepts from Figure 4. This has been done by imposing constraints upon SeCHOnto classes from Figure 4. The constraints are OWL object properties that describe relationships between people and objects involved in RPM. They are illustrated in Figure 5 and described below.

Fig. 5.

Object property constraint imposed for a particular situation.

Object property “isWornBy” relates PersonObject and EnabledUser, which means that a particular object (“coat”) allocated to a person can only be “worn” and not carried. Therefore “isWornBy” allows the same relationship to exist between any subclasses of EnabledUser and PersonObject (as long as the object is worn). However, PersonObject is related to Object though “isAbout”; therefore Coat is just one of the possible choices of Clothes residents may wear (“isAbout” applies to any subclasses of Object and PersonObject). We did not show in Figure 5 object properties that describe certain Objects (such as mobile phones and keys) that can be “carried” by the Person to whom they are allocated. For defining such object properties, classes in Figure 4 should be extended further to store the semantic that “mobile communication devices and keys are carried with and not worn by the person.” Finally, Person and Objects are related to each other through the “isAllocatedTo” object property, to secure that we know how objects are allocated to a person (i.e., worn, carried, or preferred).

Reasoning in the RPM

We perform reasoning upon SeCHOnto OWL concepts, which satisfy prerequisites (A)–(C) by running SWRL rules upon them. Each question we ask, when the situation in the SeCH changes, will require a separate SWRL rule that gives the answer. Table 3 illustrates the SWRL rule that answers the question from Table 1. The rule states that in a situation when an enabled user who is suffering from fever, who is wearing his or her coat, who is away from the care home, and who is in an open area, her or she will be issued a recommendation (“to return home”).

Table 3.

SWRL Rule for a Specific Situation

EnabledUser(?eu) ^ isMeasurementFor(?f, ?eu) ^ Feverish(?f) ^ Coat(?c) ^ isAllocatedTo(?c, ?eu) ^ WearingObject(?wo) ^ isAbout(?wo, ?c) ^ isWornBy(?wo, ?eu) ^ PersonAway(?pa) ^ OpenArea(?oa) ^ hasPosition(?pa, ?oa) ^ isAboutWhereaboutOf(?pa, ?eu) ->MakingRecommendation(?eu)

There are 12 atoms in the body and just 1 atom in the head of the SWRL rule shown in Table 3. All the parameters used are instance variables, taking values of individuals belonging to SeCHOnto classes. For example, “eu” in EnabledUser(?eu) can be any of the SeCH individuals of the EnabledUser class, namely, Ann, Margaret, Peter, John, or Paul. The atoms in the body of the rule, at the left side of the arrow, define the situation in RPM, whereas the atom in the head, at the right side of the arrow, indicates what the required action for the given situation is. The reasoning mechanism evaluates all the atoms in the body of the rule first to make a decision. If this evaluates to “true,” which is when all of the atoms are “true,” then the action (the head) will take place. In this case, “eu” will also become an individual of the class MakingRecommendation, which is precisely the answer to the specific question in Table 2.

Figure 6 shows that the outcome of running the SWRL rule from MakingRecommendation 4 is the list of SeCH residents who are subject of MakingRecommendation. More precisely, in this particular situation, John and Margaret will be issued a recommendation by the RPM system to go back to their care home.

Fig. 6.

Result of running SWRL rule for a particular situation.

Related Works

We could not find any related works that used an OWL/SWRL-enabled environment in order to support decision making in a RPM system similar to ours. However, we have found publications that are somewhat related to or may be influenced by ASeCS.

Our automated RPM within the SeCH is an e-health service designed to assist in everyday living and deliver decision making according to the needs of SeCH residents. In this respect we give a software solution from ASeCS architecture similar to other RPM systems.^21,22 However, in our solution, the provider of e-health service is heavily supported by decision making, which is happening within the RPM system (i.e., outside health centers). In extreme situations a healthcare professional may be alerted amid decision making being transferred to the health centers. This means that all relevant sensor-generated data and data that describe the semantics of the SeCH in RPM are being defined, stored, interpreted, and “reasoned upon” within the SeCH (i.e., RPM system) and not transferred to any remote health center for decision making when urgent action is needed. Consequently, our reasoning (OWL/SWRL-enabled environments developed within the automated RPM system) is more likely to be based on the client sides of the implemented ASeCS architecture and utilize the latest technological solutions that enable the implementation of reasoning through OWL-API supported by the Java-programmed front end of ASeCS.

Our automated RPM should be able to accommodate any existing e-health service that is available as a Web service, by allowing the front end of ASeCS applications to run Web services the same way as running “reasoning” though OWL-API. Furthermore, if we were to expand our computations in RPM to the interpretation of data stored in the context layer, interpretation of real-time sensor-generated data that are often stored in numerous databases, then access to and computing of such sources are feasible through ASeCS. This is because the semantics of such databases can be transferred into the ASeCS core layer, and inference mechanisms can be adapted to a new set of ontological classes and a new set of specific questions that should be answered.

The readers interested in the power of SWRL and OWL in e-healthcare should refer to other publications.^23,24 Readers interested in wearable intelligent biomedical devices, sensorized garments, and other types of sensors that could be embedded into the SeCH and contribute to data repositories of the context layer should refer to other publications.^25

–30

Results

In this article we propose a software solution that automates RPM, making it personalized for a particular patient and situations that occur during RPM. It makes decisions on delivering appropriate e-health services: alarming healthcare professionals that urgent attention is needed, giving recommendations for preventive healthcare, and managing devices in RPM according to each patient's preferences. We are able to achieve these using the ontological model SeCHOnto, by enriching its hierarchies of OWL classes, individuals, and OWL constraints and thus preparing it for reasoning through SWRL, which in turn decides on the best possible action. Our running example illustrates only a situation when we need to give a recommendation to prevent the deterioration of a resident's health. However, we could easily replace our question from Table 1 with any other type of question that could result in “issuing alarm” or “activating devices.” The process of decision making remains the same: we have to satisfy prerequisite for decision making and run adequate SWRL rules. Most of our ontological classes, individuals, and constraints from Figures 4 and 5 are reusable in most of the situations we model in RPM. This is guaranteed by

A. the very generic ontological model from Figure 3 and

B. the set of steps defined in the decision making process, which can be followed through Tables 1 and 2 and Figures 3 –5 (satisfying prerequisite for reasoning).

Our three major functionalities of the automated RPM system, given in points (1)–(3) from the Scenario, are consequences of our own categorization of e-health services. However, if for any reason we wish to change this division of actions in RPM, we can easily address this through the same SeCHOnto and appropriate constraints upon its modeling elements. This is possible because the model from Figure 3 is not built by having points (1)–(3) in mind. It was built with concepts that will enable us understanding the semantics of each situation in RPM (people/objects/relationships) and manipulating the situation through OWL and SWRL. Therefore, as soon as we describe a situation in RPM through OWL and prepare the OWL model for reasoning, we can run any set of reasoning rules that will result in appropriate decision making. Most SeCHOnto classes, their subhierarchies, and individuals can be generated in advance, and SWRL rules can also be either prepared in advance or created “as we go” in RPM.

Our running example also does not show explicitly the personalized component of the RPM. Ironically, this is just what a true personalized service is: in essence, it should be present but not evident to secure nonintrusion and acceptance of RPM by residents. Therefore, all agreed components of RPM (from devices used to e-health services needed) have to be agreed with residents in advance and (i) stored into SeCHOnto under the class named PersonPreference, (ii) used in the process of preparing SeCHOnto for reasoning as object properties, and (iii) incorporated into the SWRL rule if the situation in RPM requires. In principle, our third RPM functionality from the Scenario—“Activating devices”—is based on each patient's preferences that were agreed in advanced with healthcare professionals and that fit the RPM environment.

In this article we advocate responses to situations in RPM arising in a timely manner. Each situation differs from another, regardless of how minute the difference might be. The RPM system response to a particular situation, at a particular moment, must take into account all elements contributing to the situation. Therefore our steps that manipulate the semantics of SeCHOnto extend it and enrich it with constraints in order to prepare it for the end of reasoning with running SWRL rules, which not only verifies if the prerequisites for the situation are met, but also defines the required action or actions for the situation. This can be repeated as many times as needed and as many times as a new situation occurs within RPM.

Finally, it is important to note that our automated RPM is strongly dependent on healthcare practitioners as domain experts, who provide the meaning stored in the RPM. The content of Table 1 is supplied by them and can be added to the software solution that automates RPM on an ad hoc basis. Words from a healthcare practitioner's expertise are mapped and stored semantically inside the ontological model. We follow a strict and unique mechanism from a problem statement (Table 1) to a solution (Fig. 6) through structured computations, by manipulating semantics, which is precisely what the software engineering realm is all about.

Conclusions

Our research highlights that there are software solutions that automate RPM through the use of modern technologies, such as the Semantic Web. Advantages of having software applications based on SWRL/OWL computations are now being recognized, but the real benefits are in using OWL/SWRL in domains similar to RPM, where we need to address each patient's behavior and make decisions according to constantly changing “situations.” Semantic Web technology offers opportunities for interpreting and manipulating the meaning of environments we model and ultimately convert into computational space. Therefore in automated RPM we do not have to use any specific algorithm in order to make decisions; we mirror the changes in RPM through OWL concepts and constraints (which also constantly change) and use ontologies as “cradles” where we can define current situation and manipulate it through SWRL. Our ontology is not a big repository that grew as we used it. Many of its classes are filled with individuals after the reasoning, and their content is deleted as soon as we make a particular decision in RPM. We particularly favor the fact that, in our solution, a simple request from a healthcare professional, such as the one given in Table 1, can be automatically transferred into the ontology (i.e., RPM then secures decision making without any further user intervention).

We summarize the contribution of our work and future improvements in the paragraphs below:

1. Functionality. Our automated RPM system addresses various aspects of e-health combined into one software application, which “understands” how to secure provisions of appropriate e-health services through ontological reasoning. This means that at any moment, the RPM system will be able to issue either “a recommendation” to address preventive healthcare or “alarm” to address curative healthcare or simply “activate devices” to secure better functioning of the RPM system. These are three equally important functionalities of the RPM, and therefore we do not solely concentrate on curative healthcare and ignore health prevention, or the other way around. Furthermore, activation of devices during RPM is influenced by each patient's preferences and consequently may contribute to the patient's full adoption of the RPM in his or her everyday lives (“Margaret will be able to switch her RPM when having guests in the care home!”). Even if we assume that the RPM system secures the delivery of the best possible e-health services, we are still dependent on the patient's adoption of RPM and her or his willingness to collaborate during monitoring and use devices as agreed. To summarize, our RPM system is able to “react” on an ad hoc bases, when the situation within the SeCH changes, and make decisions on appropriate delivery of e-health services. In future works we will address the possible overlapping of curative and preventive e-health services and deal with their priorities in terms of deciding which one of them can override another and in which order they can be delivered.

2. Domains. Our RPM system is based on ontological models and reasoning upon their concepts. This means that we can extend the RPM to environments completely outside the SeCH and gear our solution toward any pervasive healthcare environment. This is possible because of the nature of our ontological model and the way we prepare it for reasoning through its prerequisites. In other words, the automation of RPM in our article can be reused in any pervasive healthcare environments, where we need to make decisions that depend on objects, people, their locations, and relationships among them. The only change we need to accommodate is the way we extend the SeCHOnto and create constraints upon it. In future works we will test our automated solution in RPM in domains where an empowered patient takes charge of his or her own health and decisions have to be made on the most suitable action in domains such as i-doctor, healthcare social networking, and healthcare educational environments.

3. Reasoning. Our automated RPM exhibits intelligence through the ontological model and reasoning upon its concepts. Steps we describe in the Decision Making in the RPM System and Reasoning in the RPM sections are quite unique (i.e., we explain how sentences written in English, which describe a particular situation in RPM, can easily be transformed into ontological concepts and their constraints as prerequisites for reasoning). Therefore each situation creates its own model and reasoning, which can be addressed immediately as soon as the situation occurs. SeCHOnto is a dynamic repository that can be extended on an ad hoc basis and reasoning rules chosen according to the question we ask in RPM. In future works we will assess the performance of the software application that automates RPM. Individuals from SeCHOnto are easily retrieved after running reasoning rules; therefore more work should be done in terms of efficiency of these rules and their access from various mobile and handheld devices on which RPM systems run.

Footnotes

Acknowledgments

The authors thank their colleague Mr. Colin Everiss for his proofreading and valuable remarks and suggestions when we greatly needed them.

Disclosure Statement

No competing financial interests exist.

References

Figueredo

MVM

, Dias

. Mobile telemedicine system for home care and patient monitoring. Proceedings of the 26th Annual International Conference of the IEEE EMBS, San Francisco, CA., 2004; 3387–3390.

de Toledo

, Jiménez

, del Pozo

, Roca

, Alonso

, Hernandez

. Telemedicine experience for chronic care in COPD. IEEE Trans Inf Technol Biomed, 2006; 10:567–573.

Agarwal

, Lau

. Remote health monitoring using mobile phones and Web services. Telemed J E Health, 2010; 16:603–607.

Qinghua

, Guoquan

, Zhuan

, Jing

, Ni

, Hongyu

, Ningning

. Research on home health care telemedicine service system concerned with the improvement of medical resources utilization rate and medical conditions. 12th Int Conf Adv Commun Technol, 2010; 1555–1559.

D'Addio

, Cimmino

, Manna

, Arpaia

. A telemedicine home care based activity monitor device. Proceedings of IEEE International Workshop on Medical Measurements and Applications (MeMeA), 2011; 579–582.

PERSONA Project. Perceptive spaces promoting independent aging. European Commission ICT Research in FP7. 2010. http://cordis.europa.eu/fetch?CALLER=PROJ_ICT&ACTION=D&CAT=PROJ&RCN=80532. 2011 September 18.

Amigo Project. European consortium partially funded by European Commission. 2007–2013. http://7.hitech-projects.com/euprojects/amigo/. 2011 September 18.

MonAMI Project. Mainstreaming on ambient inteligence. Funded by the EU 6th Framework Programme IST (Information Society Technologies) 2011. http://7.monami.info/. 2011 September 18.

SOPRANO Project. Service-oriented Programmable Smart Environments for Older Europeans. An integrated project in the European Commission's 6th Framework Programme. 2010. http://7.soprano-ip.org/echome.asp?lang=1. 2011 September 18.

10.

Horrocks

, Patel-Schneider

, Boley

, Tabet

, Grosof

, Dean

. SWRL: A Semantic Web rule language combining OWL and RuleML. 2004. http://7.w3.org/Submission/SWRL/. 2011 October 10.

11.

Shojanoori

, Nemitsas

, Krishnamurthy

. Generation of ontologies from relational databases. Presented at 11th Int Conf Integrated Design Process Technol, 2008.

12.

Shojanoori

, Juric

, Lohi

. Balanced distribution of computation in smart spaces. Presented at 17th UK Automated Reasoning Workshop, 2010.

13.

Shojanoori

, Juric

, Tourani

. Experience of building assisted self care systems within smart home environment. Presented at 13th Int Conf Integrated Design Process Technol, 2010.

14.

Shojanoori

, Juric

, Mahi

. Towards balanced distribution of computations through automated reasoning. Presented at 13th Int Conf Integrated Design Process Technol, 2010.

15.

Astrova

, Stantic

. Reverse engineering of relational database to ontologies: An approach based on an analysis of HTML forms. Proceedings of the Workshop on Knowledge Discovery and Ontologies at ECML/PKDD, 2004; 73–78.

16.

Cullot

, Ghawi

, Yetongnon

. DB2OWL: A tool for automatic database-to-ontology mapping. Proc 15th Italian Symp Adv Database Systems (SEBD 2007), 2007; 491–494.

17.

, Qu

. Discovering simple mappings between relational databases schemas and ontologies. The Semantic Web. New York: Springer, 2007; 225–238.

18.

Laclavik

. RDB2Onto: Relational database data to ontology individuals mapping. Tools for acquisition, organisation and presenting of information and knowledge. Bratislava: Vydavatelstvo STU, 2006; 86–89.

19.

Nyulas

, O'Connor

, Tu

. Datamaster—A plug-in for importing schemas and data from relational databases into Protégé Presented at The Ninth International Protégé Conference. Stanford, CA, 2006.

20.

, Zhang

, Dong

. Mapping between relational database schema and OWL ontology for deep annotation. Proceedings of IEEE/WIC/ACM International Conference on Web Intelligence. Hong Kong, China., 2006; 548–552.

21.

Polze

, Tröger

, Hentsche

, Heinze

. A scalable, self-adaptive architecture for remote patient monitoring. 13th IEEE Int Symp Object/Component/Service-Oriented Real-Time Distributed Comput Workshops, 2010; 204–210.

22.

Niyato

, Hossain

, Camorlinga

. Remote patient monitoring service using heterogeneous wireless access networks: Architecture and optimization. IEEE J Selected Areas Commun, 2009; 27:412–423.

23.

Koay

, Kataria

, Juric

. Semantic management of nonfunctional requirements in an e-health system. Telemed J E Health, 2010; 16:461–471.

24.

Ganguly

, Kataria

, Juric

, Ertas

, Tanik

. Sharing information and data across heterogeneous e-health systems. Telemed J E Health, 2009; 15:454–464.

25.

Rossi

, Lymberis

. New generation of smart wearable health systems and applications. IEEE Trans Inf Technol Biomed, 2005; 9:293–294.

26.

Williams

, Roussaki

, Strimpakou

, Yang

, MacKinnon

, Dewar

, Milyaev

, Pils

, Anagnosto

. Context-awareness and personalisation in the daidalos pervasive environment. ICPS 05. Proc Int Conf Pervasive Serv, 2005; 98–107.

27.

, Pung

, Zhang

. Toward an OSGi-based infrastructure for context-aware applications. IEEE Pervasive Comput, 2004; 3,4:66–74.

28.

Chaari

, Ejigu

, Laforest

, Scuturici

. A comprehensive approach to model and use context for adapting applications in pervasive environments. J Systems Software, 2007; 80:1973–1992.

29.

Weibenberg

, Gartmann

, Voisard

. An ontology-based approach to personalized situation-aware mobile service supply. GeoInformatica, 2006; 10:55–90.

30.

Ruttenberg

, Rees

, Samwald

, Marshall

. Life sciences on the Semantic Web: The neurocommons and beyond. Briefings Bioinform, 2009; 10:193–204.