OUTPUTS

Phase 2 (January – December 2021)

This present section details the main results for the activities taking place within the Phase 2 – Initial Prototype of the PREVENT project. The reported period covers the January – December 2021 interval, and thus represents a 12 month time span out of the project’s provisioned total of 24 months. The current phase saw the continuation of the activities started during Phase 1. The PREVENT project was started from the TRL-5 level and aims to reach TRL-6 level at its completion. At the endpoint of the current phase, we report the following main achievements:

  1. The project consortium purchased 2 SEWIO RTLS kits for precise indoor localization, together with 2 unidirectional anchors and 10 personal localization tags. These allow precise monitoring of the presence and movement of persons within 3 rooms (12 anchors) and a large hallway (2 unidirectional anchors working in 1D mode).
  2. Project partners started the indoor localization experiments using the purchased equipment and published a first scientific paper on the topic.
  3. Several clinical workflows, together with a concrete clinical location were evaluated to pilot the system within a clinical location with inpatients.
  4. The advanced version of the clinical software simulator was finalized; it allows configuring, parameterizing, and executing complex simulation scenarios. It will allow researchers to improve their level of understanding regarding the way hospitals work from an interpersonal contact and risk level viewpoint, as well as to understand the way infections can spread throughout the clinical unit.
  5. The integration of the software simulator that was described in the previous paragraph within the PREVENT software server was started. This will enable its users to use the simulator within the PREVENT web application and to reuse its components for building and managing risk maps and contact networks.
  6. Several devices to monitor the actions of monitored persons were developed. These were built using electronic components that are widely available on the market, with their assembly and software configuration being carried out within the project. The Consortium also started the acquisition process for electronic components to build six additional monitoring devices, that will enable running the pilot within a clinical location.
  7. Development of the PREVENT server was continued by integrating an MQTT broker together with the development of the software modules required for system management, workflow monitoring, clinical environment simulation, risk map and contact network management.
  8. Partners have continued disseminating results by updating the project web site and publishing an additional scientific paper based on project results.
  9. The consortium started a patent search process aimed to identify the relevant patents in the project’s area of applicability to protect developed intellectual property.
  10. The project partners finalized the deliverables required for this phase.

 

Hardware Architecture

The figure below illustrates the detailed hardware architecture of the PREVENT project. The architecture conforms to the one proposed within the previous project phase. Detected events (e.g., using a dispenser, waste bin, equipment disinfection) are managed directly on the PREVENT server and synchronized with the information provided by the indoor localization system. Detected events are transmitted via Ethernet and a dedicated connection is required for real-time positioning information. Medical personnel can be notified of any regulation breach detected by the system via mobile phone. Each monitored person has an associated tag. The system is configurable, as new sensors can be added to an existing deployment at any time.

PREVENT Architecture

 

The hardware architecture has the following components:

  • Wireless (WiFi) and contactless (time of flight) sensors for detecting events.
  • Tags that are used to determine a person’s position for indoor localization or to connect them to detected events.
  • Server hardware that runs the PREVENT software server components
  • Additional PC to manage tags allocation and management (charging, firmware updating etc.)

 

Software Architecture

The detailed software architecture of the PREVENT system is detailed below. The architecture observes the main components of the precursor HAI-OPS projects. The most important components are briefly detailed within the present section.

Software Architecture

 

Sensor system – SEWIO RTLS. The SEWIO RTLS system for accurate indoor localization is based on ultra wide-band technology and is comprised of multiple hardware elements (tags and anchors), together with the SEWIO software server. The system is licensed as one and runs on a mini-PC type computer. The server collects data from deployed equipment, runs localization algorithms and sends the data towards an MQTT broker. From here, data is read by the PREVENT server.

 

Sensor system – In-house sensor controller. The equipment developed during the project aims to detect events that are important for infection prevention (e.g. operating a faucet, a disinfectant dispenser etc.). They include several hardware components together with a software controller through which events are transmitted to the MQTT broker and then, to the PREVENT software server.

 

Sensor system – Gateway. The gateway component is represented by a server that runs the SEWIO  software and an MQTT broker. A mini-PC is used as part of the project. The MQTT broker centralizes messages from all connected equipment and transmits them to the software server.

 

Hospital Information System. It represents a computer software system that is compatible with the PREVENT platform, from which the latter can read data such as patient and organization information, workflow and so on. While this integration is not an objective of the PREVENT project, it is one that needs to be taken into consideration as the solution nears commercialization.

 

Epidemiology client – UI Simulator. Represents the access interface for the simulation component within PREVENT. It allows defining location plans (room layouts, furniture, door and window locations etc.), the behavior of simulated persons (e.g. medical personnel with a pseudo-random routine) and executing simulations in order to estimate infection risks. The same component will be reused to visualize risk maps and contact networks within the final prototype.

 

Epidemiology client – Show centralized alerts / Epidemiology risk analysis. The client administration components were initially implemented within the HAI-OPS project as a web application that can be accessed by all users registered within the system. In accordance, system users are assigned one of the three predefined roles: administrator, epidemiologist or medical personnel.

 

Administration Client – Administration UI. The administration component provides the required functionalities to manage the organization and clinical personnel. Admin users have access to all system functionalities, including the organization structure, system users, alert history for all persons, defined workflows, risk maps, the contact network, and any simulations.

 

Server – Data acquisition. The data acquisition component allows the software server to communicate with the mini PC’s MQTT broker. Its main interface is iDataAcquisition, which provides the required connection points. Received data is stored within the persistent Data Store, from which they are read and used by the rest of the system’s components.

 

The adapter component will provide the iDataAdapter connector to which external systems can connect to transmit data. Received data will be stored within the same Data Store component, from which we expect it will be read and used within the Data Analysis components.

 

Server – Business rules engine. The Business Rule Engine Adapter is a façade for the actual implementation of the rule engine used within the system. PREVENT will employ a commercial-off-the-shelf implementation for this component. To abstract the particularities of selecting this component, the adapter will provide a common connection point using the iRulesAdapter interface. This will enable integrating the component with any suitable implementation of a rule engine if a suitable adapter exists.

 

Server – Simulator. The simulator represents a new component within PREVENT, one that aims to simulate different configurations of the clinical environment, medical activities, and personnel behavior. The simulator component will be integrated with the PREVENT server components to test the system’s capacity for detecting infection risk.

 

Server – Client Services. These components implement system user and connected device administration; they also provide certain data analysis services. According to project requirements, system users fall into one of three predefined roles; security is applied on a role-based access methodology.

 

Server – Data Store. This component represents the system’s data persistence layer. It is responsible for persisting all data (e.g., organization, user, device, location, alerts).

 

Phase 1 (June – December 2020)

In this section we present the main results of the activities that took place within the first implementation phase of the PREVENT project. The reported period covered the June – December 2020 interval, and represented the first 7 month of implementation out of the 24 provisioned. The first phase contined the activities of the precursor HAI-OPS project, a Eurostars project implemented in the 2015 – 2018 timespan. The PREVENT project starts at TRL-5 and is expected to advance to TRL-6. The main ways in which we expect the project to move forward are:

  • Inclusion of an accurate system for indoor localization of medical personnel, patients and visitors that will enable the creation of risk maps and accurate contact networks.
  • Development of a new set of connected devices that can be made available at more advantageous prices than those within the HAI-OPS project that will facilitate monitoring the workflows taking place within the clinical unit.
  • Replacing the workflow engine within the HAI-OPS implementation with a business rules engine that is expected to be easier to configure.
  • Creation of advanced visualizations and reports based on data gathered from the deployed devices.

At the time Phase 1 was completed, project partners have started the activities required to fulfill the main objectives enumerated above. Briefly, the current status of the project can be summarized by the following:

 

  1. Partners have completed the deliverables for Phase 1. As such, system requirements and the system architecture documents were completed and are available.
  2. Several commercial solutions for accurate indoor localization were evaluated; all of them go above and beyond the accuracy available through WiFi and Bluetooth solutions. The acquisition process for the first such demo kit was started.
  3. A number of clinical workflows suited to pilot the developed system within an inpatient hospital facility were analyzed and evaluated.
  4. The partners modeled a clinical workflow for the ecography consultation, which implied understanding the steps taken by medical personnel and patients alike, identification of necessary equipment and how all steps can be modeled in software.
  5. The software development process for the PREVENT software modules was started; several modules can be reused starting from their HAI-OPS implementation.
  6. The development of a software simulator component was started. Its role is to facilitate configuring, parameterizing and executing simulations of the clinical space and workflows. Through this components, project researchers aim to improve our level of understanding regarding the relation between hospital workflows and the way they can be represented using risk maps and accurate contact networks.
  7. The project partners started the dissemination process. The first step was to create the project web site and publish the first scientific paper based on project results.

WP1 – System requirements and architecture

Objectives:
(1) Identification of relevant technical, usability and legal challenges, both in Romania and in the European Union;
(2) Detailing the functional and non-functional requirements of the system in a structured way;
(3) Identification of relevant technologies and existing hardware solutions that allow the fulfillment of the project requirements;
(4) System design and definition of its hardware and software architecture.

WP2 – System development, testing and integration

Objectives:
(1) Development, integration and testing of hardware equipment that allows locating people and events at room level;
(2) Development, integration and testing of the components of the project software system;
(3) Integration of hardware and software components using an extensible protocol;
(4) Technical validation of the system.

WP3 – Prototype evaluation

Objectives:
(1) Creation of evaluation scenarios and key performance indicators to assess the degree of fulfillment of the project requirements; (2) Verification of the level of fulfillment of the requirements defined at the start of the project from a scientific, medical, legal and ethical point of view.

WP4 – Project coordination

Objectives:
(1) Establishing an efficient structure for project administration;
(2) Keeping the project within the set targets regarding the objectives, the time allocated to the activities and the budget;
(3) Management of the project consortium from a legislative, administrative and financial point of view;
(4) Risk management on the project;
(5) Management of existing intellectual property and that created by the implementation of the project;
(6) Coordinating dissemination activities and preparing the development and exploitation of project results.