Computational protocol: Ambient-aware continuous care through semantic context dissemination

Similar protocols

Protocol publication

[…] To evaluate the performance and benefits of the SCB, a prototype of the oNCS Application Component, extended with the Localization and Home Automation Application Components, was implemented and tested in the Patient Room of the Future (PRoF) []. PRoF is a high-fidelity mock-up of a near-future patient room integrating innovations from soft- and hardware developers as well as furniture. The aim of PRoF is to make a patient feel more at home by exploring ways to put the patient and his needs first. PRoF consists of a typical patient room and hallway found in a hospital setting, as well as a room mimicking a homecare setting. For the prototype, both rooms were equipped with a TMote Sky [] sensor board, which contains a light, temperature and humidity sensor. Also, each patient and staff member carried an RFID tag to track their location. Finally, each patient wore a bracelet that monitors the patient’s body temperature. The developed prototype, consisting of the various context providers, the SCB, the oNCS, and the localization and Home Automation Application Components, was installed in PRoF and integrated with the available nurse call and light control system, RF tags and sensors. Smartphones running the mobile nurse call application, which enable the nurses receive and answer calls, were also provided. Figure visualizes the deployment of the prototype and accompanying sensors in PRoF. As PRoF contains only two rooms and the number of users was also limited, only one instance of the SCB was deployed.Figure 6This prototype allowed users to experience a fully immersed, contextual experience of the system in a lifelike context. As we wanted the participants to have a complete experience of the system, small groups were invited, i.e., two or three users per workshop, so that they would be occupied at all times and the researchers could follow them one-on-one. As such, seven workshops were organized for 15 participants. During a 2.5 hour role-playing workshop, the participants were asked to play out seven scenes. For each scene, a test user received a persona card and a context card, informing the test user of the role he or she would have to take up and what he or she would have to do. Afterward, the functionality of the system was elaborately discussed.However, as PRoF contains only two rooms, it was difficult to thoroughly evaluate the performance of the system based on these user tests. To mediate this, simulations were performed based on realistic data gathered from observations and interviews performed at Ghent University Hospital []. The simulated department contains 20 rooms, 30 patients and 10 staff members, who answer calls. It was again assumed that each room is equipped with a TMote Sky, the temperature of each patient is monitored with a bracelet and the location of all the staff members and patients is tracked. The simulation of the observations of the RF tags was based on realistic data gathered about the walking behavior of caregivers and patients in several departments of Ghent University Hospital. The simulation of the observations of the other sensors was based on stakeholder input. Table gives an overview of the amount of data generated by each sensor for the simulations. As the goal of the simulations was to assess the performance and scalability of the SCB, only one instance was deployed.The prototype is able to realize the example detailed in the “Introduction” Section. This scenario consists of the following steps.First, the oNCS, Localization Component and Home Automation Application Components register filter rules with the SCB, to receive context information they are interested in, independent of the current context. These filter rules are visualized in green in Figure .Figure 7During the night, a nurse enters the room of a patient, who is sleeping. As the RFID tag of the nurse is picked up by the loop installed in the room, an event is generated and published on the SCB. This event is shown in the first blue square of Figure . The RFIDRegistration concept is defined in the ontology as an observation made by a Sensor of type RFIDLoop or RFIDReader, as follows: RFIDRegistration == (Observation and (isObservationOf some (RFIDLoop or RFIDReader))) Consequently, this event matches with the filter rule registered by the Localization Application Component. This component maps the RFID on the appropriate nurse and updates the location of this person. This location information is pushed back to the SCB, as illustrated in the second blue square of Figure . As already explained in the “Subscribing to context” Subsection of the “Flexible and semantic publish/subscribe mechanism” Section, this location information matches with the filter rule of the Home Automation Application Component. Similarly, it also matches with the filter rule of the oNCS Application Component. The latter only updates the location of the nurse. No further reasoning is triggered in this component. However, the former detects that a nurse has entered the room during the night shift. The Home Automation Application Component also knows that the light is currently turned off. To enable the nurse to perform her duties, the component decides to switch on the light to a very low level, namely 1. Consequently, the light sensor in the room detects the changed light intensity in the room and an event is sent to the SCB, as shown in the third blue square of Figure . As explained in the “Subscribing to context” Subsection, this light intensity information is picked up by the Home Automation Application Component, which concludes that the light level was adjusted to the right level.The next day, the EHR of the patient is updated to indicate that a patient with ID P231 has a concussion, as illustrated in Figure . Consequently, the knowledge bases of the oNCS and Home Automation application components is updated with this information as they are regularly synched with the database containing the EHR data. As explained in the “Generating new filter rules” Subsection of the “Flexible and semantic publish/subscribe mechanism” Section, the oNCS Application Component registers a new filter rule with the SCB as it detected that the patient with ID P231 is sensitive to light.In the evening, a visitor enters the room of patient with ID P231, who is currently resting. This causes the light to be automatically turned on to a low level. The actions taken to realize this are similar to the ones visualized in Figure . However, in Figure the Home Automation Application Component dims the light because it is night. In this case, the light is dimmed because the patient has a concussion. However, as visualized in Figure , it remains possible for people to overrule the system and brighten the light in the room. The light sensor again picks up this change in light intensity in the room. An event similar to the event in the last blue square of Figure is published on the SCB. This event is picked up by the Home Automation Application Component. However, this component detects that it already tried to dim the light and that a person has manually adapted the light level. The Home Automation Application Component can thus not intervene. However, because of the newly registered filter rule, this event is also forwarded to the oNCS Application Component. This component reasons on the event and alerts a nurse that the light level has been turned on too high in the room of a patient with light sensitivity.Figure 8Figure 9Figure 10The evaluations were performed using the continuous care core ontologies needed to model the scenario as described in the “Continuous care ontology” Subsection. The core ontologies consist of 142 classes, 42 object properties, 21 data properties and 556 asserted axioms. The Protégé ontology editor [, ] was used to develop the ontologies in OWL-DL []. The context information published on the SCB and the filter rules registered by the application components are also expressed in OWL-DL. The prototype was built in Java, based on the Pellet OWL 2 reasoner [] and the OWL Application Programming Interface (OWL-API) []. The cache was implemented using a combination of the Least-Frequently Used (LFU) and Least Recently Used (LRU) replacement algorithms, called the Least Recently/Frequently Used (LRFU) policy []. All the tests were performed under exactly the same conditions on the same isolated machine with following specifications: Advanced Micro Devices (AMD) Athlon 64 X 2 Dual Core Processor, 3000 megahertz (MHz) Central Processing Unit (CPU) and 2 Gigabyte (GB) of Random-Access Memory (RAM). […]

Pipeline specifications

Software tools Protégé, OWL API
Application Ontology generation
Organisms Homo sapiens