Distributed Continuous Home Care Provisioning through Personalized Monitoring & Treatment Planning

In healthcare, the aging of the population is resulting in a gradual shift from residential care to home care, requiring reliable follow-up of elderly people by a whole network of care providers. The environment of these patients is increasingly being equipped with different monitoring devices, which allow to obtain insight into the current condition of patient & environment. However, current monitoring platforms that support care providers are centralized and not personalized, reducing performance, scalability, autonomy and privacy. Because the available data is only exposed through custom APIs, profile knowledge cannot be efficiently exchanged, which is required to provide optimal care. Therefore, this paper presents a distributed data-driven platform, built on Semantic Web technologies, that enables the integration of all profile knowledge in order to deliver personalized continuous home care. It provides a distributed smart monitoring service, which allows to locally monitor only the relevant sensors according to the patient’s profile, and infer personalized decisions when analyzing events. Moreover, it provides a medical treatment planning service, which composes treatment plans tailored to each patient, including personalized quality of service parameters allowing a doctor to select the optimal plan. To illustrate how the platform delivers these services, the paper also presents a demonstrator using a realistic home care scenario.


INTRODUCTION
Nowadays, the aging of the population is resulting in a shift from acute to chronic care, as people live longer with one or more chronic diseases [11]. This significant change in healthcare requires care delivery to become more transmural and to be facilitated at home and in service flats. In this way, residential care can be reserved for patients with more severe care needs.
To facilitate this gradual shift to home care, it is crucial to monitor and follow up the elderly people at home in a reliable and accurate way. Today, this follow-up is typically provided by a whole network of care providers. This involves formal providers, such as hospitals, general practitioners (GPs), nursing organizations and caregivers, as well as informal providers, such as family and volunteers. Moreover, elderly people and their homes are increasingly being equipped with Personal Alarm Systems (PAS) and monitoring devices. The latter include wearable devices, medical sensors, environmental sensors, localization sensors, etc. Together, they allow performing data-driven smart monitoring, in order to obtain insight into the person's lifestyle, environment and current condition [9].
Looking at the monitoring process of current platforms, a first issue is that the event data of all patients is generally processed together on a central server. On top, the monitoring is naive rather than smart, as typically all events from all sensors are analyzed. This centralized and generic approach reduces the performance, scalability, local autonomy, and data privacy of the system. In addition, current data-driven continuous home care services used by the care providers are too generic and not personalized. This is because the data collected about a person is typically divided across these providers, where it is exposed through custom APIs used by custom services. This means that the available profile knowledge cannot be efficiently exchanged and exploited, which is required to provide the optimal continuous care to each person. Hence, if the analysis of certain sensor events indicates that some intervention is needed, the nursing organization now manually solves this in a generic way, by sending a nurse to the corresponding patient. Integrating profile information into this pipeline would allow to intelligently select the best-suited person from the care provider network to notify and send to the patient. This person might depend on the urgency and severity of the event, scheduled visits of people in the care provider network, whether a medical care provider is required or not, etc. All these factors are largely patient-specific. Moreover, when a certain event requires a medical intervention in order to treat a certain disease, the optimal treatment plan for that specific patient should be created, instead of generic plans created by existing tools.
To solve these challenges, this paper presents a distributed platform that can provide personalized data-driven continuous home care in an intelligent and efficient way. To do so, it allows for easy integration of all existing profile information. Therefore, the platform uses a semantic approach: all available heterogeneous data sources are semantically annotated to make their meaning and context clear, and personalized services are created that process and reason on this data [3]. Hence, the platform is fully built on Semantic Web technologies, using ontologies and semantic reasoners. First, it provides a distributed smart monitoring service. By taking into account the available profile information of a person, the system only monitors the sensors that are important according to the person's profile, resulting in a personalized monitoring process. By distributing the monitoring tasks across the network, the sensor data can already be processed on local low-end devices in a person's home, allowing for improved system performance, scalability, local autonomy and privacy. By taking into account the profile information in the analysis of sensor events, personalized decisions can automatically be inferred. Second, the platform provides a personalized treatment planning service. Based on a person's profile knowledge, this service is able to automatically compose effective treatment plans tailored to that person, containing accurate personalized quality of service parameters to help a medical caregiver with selecting the most appropriate plan for that specific person.
To demonstrate this solution, a web application is implemented that allows users to experience how the platform delivers its different services. This is done through a realistic use case scenario of an elderly person living in a smart service flat.

PLATFORM ARCHITECTURE
The distributed data-driven architecture of the personalized continuous home care platform is presented in Figure 1. This architecture is built on Semantic Web technologies and contains two main parts: a smart monitoring pipeline, and a medical treatment planner.
To semantically annotate the data in the system, the RDF Mapping Language (RML) is used [6], which allows integrating heterogeneous data sources by using customized mapping rules that generate RDF data from them. The resulting RDF data sources are exposed through the Knowledge Base.
The distributed architecture is split into a local part and a backend part. The local part contains components that can run a low-end device in the patient's environment, e.g., on a home gateway in a smart service flat, and that only perform tasks specific to that patient. The components of the back-end part are responsible for tasks related to all different patients, and should therefore run on a central server, e.g., in a nursing organization or hospital.

Smart Monitoring Pipeline
The data-driven smart monitoring pipeline is responsible for automatically processing the events generated by the sensors in a person's environment, with a focus on personalization. Below, the role of the different pipeline components is discussed.
2.1.1 RML Streamer. RML Streamer is a component that performs parallel RDF generation from RML mapping files [7]. It is responsible for semantically annotating the observations generated by the sensors in the patient's environment. In this way, the semantic monitoring service can intelligently integrate the sensor event data with all background and context information in the knowledge base.

C-SPARQL & DIVIDE.
C-SPARQL is an RDF Stream Processing (RSP) engine that allows to evaluate continuous queries over RDF data streams [2,10]. Its task is to locally filter relevant sensor observations for further processing.
To know which sensors and observations should be monitored by C-SPARQL, DIVIDE is used. DIVIDE can automatically derive and configure RSP queries in an adaptive and context-aware way [5]. To do so for a specific person, it performs semantic reasoning on the medical domain knowledge and all contextual information related to that person, including the person's medical profile. In this way, the evaluated queries depend on the person's diagnoses, treatments, etc. Their evaluation only involves filtering and does not require any more reasoning. DIVIDE is adaptive in the sense that it will update the queries when the corresponding profile is updated.

Streaming MASSIF.
Streaming MASSIF is a cascading reasoning framework that enables to perform scalable expressive reasoning over high velocity data streams [4]. It performs further semantic reasoning on events filtered by the local C-SPARQL engines, in order to infer their severity and urgency. It implements a service that can generate notifications of these events to a person in the patient's care provider network. The selection of the person from the network depends on the inferred event parameters and profile information such as the already scheduled visits of these people.

Medical Treatment Planner
The medical treatment planner is responsible for proposing and managing personalized treatment plans for diseases and diagnoses of a patient. It is used by a doctor, for example when an event processed by the smart monitoring pipeline indicates that a medical intervention is required. The engine used for this is called AMADEUS.
AMADEUS is an adaptive, goal-driven workflow composition and conflict-detection engine [1]. To compose possible workflows to achieve a certain goal, it uses a Weighted State Transition logic. As such, it is state-aware, taking into account a semantic description of the current context. It uses an agent-oriented decentralized Web architecture, where the agent automates the interaction between data sources, applications and the workflow engine.
In the context of healthcare, a semantic workflow can represent a treatment plan to a disease. To compose different treatment plans for a certain diagnosis in a patient's profile, AMADEUS performs semantic reasoning using the semantic descriptions of the medical patient profile, and medical domain knowledge about functionality, input, output and quality of service parameters of the different available options in the treatment of that disease. As such, it proposes different treatment plans, and provides composed quality of service parameters for each plan that help a doctor to select one. These parameters include cost, probability of success, comfort, relapse risk, etc. Moreover, AMADEUS performs automatic conflict detection between existing and new treatment plans, to assist a doctor in not generating any conflicts he/she is unaware of.

DEMONSTRATOR
To illustrate how the presented platform allows to deliver personalized data-driven continuous home care in an efficient way, a demonstrator has been created. This demonstrator includes a prototype implementation of the platform architecture described in Section 2. It also contains a web application that allows users to interact with the platform in the context of a designed use case scenario. This application also shows how medical care providers would be able to follow up and interact with the smart monitoring and treatment planner services in a real set-up.
To showcase the demonstrator to visitors and let them interact with it, a screen with the web application is used. The local architecture components are deployed on an Intel NUC device, while the server components are deployed on a public virtual server. The different sensors in the scenario are simulated on a laptop.

Ontology
To perform the smart monitoring and treatment planning in the demonstrator prototype, an extended version of the ACCIO continuous care ontology is used [8]. Figure 2 shows an overview of some important concepts and relations that allow to define patients, medical domain knowledge, events, etc.

Use Case Scenario
The demonstrator scenario tells the story of a patient Rosa, who is an elderly woman of 70 years old that lives in a smart service flat. This flat is equipped with environmental sensors, BLE beacon sensors and door sensors. Moreover, Rosa has a wearable with a BLE tag and different body sensors. Integrated into her wearable,  she has a PAS. Rosa has been diagnosed with early stage dementia. She is followed up by a nurse who visits Rosa daily, by a GP, by her daughter who works close to Rosa's flat, and a neighbor. Moreover, she is a known patient in the nearby hospital.

3.2.1
Step 0 -Initial state. The start of the scenario, shown in Figure 3(a), represents the initial state, where the smart monitoring pipeline is not active yet. It shows a real-time visual overview of Rosa's environment: a map with the location of Rosa and all parties in her care provider network, Rosa's profile, and a real-time visualization of all raw data generated by the sensors in Rosa's service flat and wearable.

3.2.2
Step 1 -Activating the smart monitoring pipeline. In step 1 of the scenario, the smart monitoring pipeline is activated. This triggers DIVIDE to derive and configure personalized queries on C-SPARQL that filter the relevant sensors according to Rosa's profile. When this process is completed, the charts in the bottom pane only display the data of the sensors monitored by the queries. Because Rosa has dementia, two queries are derived. The first query filters sensor observations implying that Rosa is longer than 30 minutes in her bathroom, without performing any movement, which might indicate an accident has happened. The second query filters observations indicating that Rosa has left her house, which could possibly lead to a disorientation if she is alone. Hence, only the movement sensor, main door sensor and relevant BLE sensors are monitored.

3.2.3
Step 2 -Colon cancer diagnosis. In the next step of the scenario, a hospital doctor diagnosis Rosa with colon cancer. When he updates Rosa's profile with this diagnosis, DIVIDE is again triggered to update the queries on C-SPARQL. The new colon cancer diagnosis leads to one new query, which filters observations made by Rosa's body temperature sensor that are higher than 38 • C. The reason for this query is that during cancer treatment, it is important that the patient stays healthy apart from the cancer. If the patient has another infection, this is too dangerous and forms a contraindication for several treatments such as chemoradiotherapy. Hence, medical domain knowledge states that cancer patients should be monitored for fever, as this might indicate an underlying infection.

3.2.4
Step 3 -Constructing a colon cancer treatment plan. To treat Rosa's colon cancer, the hospital doctor can open a visual interface for the AMADEUS treatment planner. In this example, AMADEUS provides two options to treat the colon cancer: neoadjuvant chemoradiotherapy followed by a surgery, or only a surgery. Because the first option has a higher survival rate and lower relapse risk, the doctor would choose the first plan. After selecting a plan, AMADEUS performs a second reasoning run to calculate a detailed workflow by adding timestamps to the different steps in the plan. After confirmation of the plan, the chosen treatment plan is added to Rosa's current treatment plan. This is all shown in Figure 3(b).

3.2.5
Step 4 -Influenza infection leading to fever alerts. In the next step of the scenario, Rosa gets infected with the influenza virus, causing her body temperature to start rising. At a certain point in time, it exceeds the fever threshold of 38 • C. This event, semantically annotated by RML Streamer, is filtered by C-SPARQL and sent to Streaming MASSIF. Because the fever is still low, it has a low severity and urgency, causing Streaming MASSIF to select Rosa's daughter to check her, during a regular visit that she has already scheduled in the near future. However, within the next hour, Rosa's body temperature rises further to above 39 • C. This quick and large increase leads to a high fever classification of the event, with a high severity and urgency. Hence, Rosa's nurse is now selected to come as quickly as possible. Through the web application, the rise in body temperature, as well as the events & selections by Streaming MASSIF, are visualized to the user for follow-up.

3.2.6
Step 5 -Influenza treatment plan conflict. After a nurse visit and GP examination, Rosa's profile is updated with the influenza diagnosis. The GP can now use AMADEUS to construct a treatment plan. For this case, the treatment plans consist of taking a type of medication or waiting until the influenza is cured. Since Rosa is already sick enough, a certain type of medication would probably be chosen. This needs to be taken for 10 consecutive days, i.e., the influenza virus is expected to be cured after 10 days. After confirming the detailed plan, AMADEUS verifies whether the newly added treatment plan yields any conflicts with the currently existing plan. In this scenario, a conflict is detected. This conflict is a contraindication for Rosa's next scheduled chemoradiotherapy session, which takes place within the next 10 days. The conflict exists because the influenza treatment plan will not cure the influenza virus before this session takes place, which means Rosa will not be healthy for it and the session should be postponed. As such, this conflict is also visualized to the GP in the web application. This conflict detection is particularly interesting because Rosa's GP did not construct the original colon cancer treatment plan. Hence, AMADEUS can also help improving the coordination of the overall patient treatment plan across Rosa's different care providers.

Demonstrator UI
A video of the demonstrator can be found online at https://vimeo. com/380716692. This video shows a screencast of the web application throughout the full scenario, and highlights how the visitor can interact with the demonstrator through the application's UI elements. The visitor can activate the smart monitoring pipeline, add diagnoses to Rosa's profile, "infect" her with influenza, and assume the role of a doctor by using the treatment planner tool.

Evaluation
To showcase the efficiency of the platform, Figure 4 shows the average processing times of the different platform components in the different scenario steps, splitting up the individually triggered components (DIVIDE & AMADEUS) from the sensor event pipeline. For this evaluation, the local architecture components are run on an Intel NUC, model D54250WYKH, which has a 1300 MHz dual-core Intel Core i5-4250U CPU and 8 GB DDR3-1600 RAM. The server components are run on a virtual Ubuntu 18.04 server with a Intel Xeon E5620 2.40GHz CPU, and 12GB DDR3 1066 MHz RAM.

DISCUSSION & CONCLUSION
The data-driven continuous home care platform presented in this paper delivers personalized monitoring and treatment planning services. Adopting the semantic approach allows the efficient exchange of profile knowledge, which enables personalized decision making and improves the coordination across care providers. Together with the distribution of services across the network, this improves scalability, local autonomy, and allows for flexible privacy management, while being efficient as shown in the evaluation.

ACKNOWLEDGMENTS
This research is partly funded by FWO SBO grant 150038 (DiSSeCt).