OUTPUTS

Phase 3 (January – May 2022)

The reported period is January – May 2022, and represents the last 5 months of project implementation (months M20 – M24). Within the current phase, the Consortium continued activities that were started within Phase 2. The PREVENT project was started from an estimated technological maturity level of TRL-5 and advanced up to its current phase of TRL-6. At the moment of project completion, we report the following results obtained within the current implementation phase:

1. On the hardware side, additional monitoring prototype devices were built in order to allow monitoring the actions of hospital personnel and patients. In addition, we updated the functionalities of the Gateway System. In its current implementation, its job is to read the messages produced by the hardware equipment on the network and push them to the MQTT server.
2. The functionalities and protocol behind the hardware-software bridge were finalized by identifying and establishing the relevant MQTT topics, the way that monitoring equipments developed within the project are registered with the system and communicate data, as well as how the data registered within the RTLS system created by SEWIO and integrated with the project are sent to the software server via the MQTT broker.
3. With regards to the platform’s software development, the subsystem for Device Management was replaced with the Business Rules Management at an architecture level. This change was carried out because the management of business rules includes the relevant details regarding the hardware devices involved. Also, from the point of view of precise indoor localization, we employ the RTLS platform’s functionalities for marking and monitoring a given area (e.g. the area around a sink). The equipment developed within the project can be identified through their unique identifier and the topic where they send their data. In addition, we introduced a graphical editor to create and edit monitored business rules. This interfaces with the business rules engine and allows creating compound rules that are executed within the PREVENT server.
4. The consortium continued the development of the clinical environment simulation component, as well as those for creating and managing risk maps and the contact network. The environment simulation component was enriched with the advanced epidemiological analysis component, which allows analyzing the impact that different measures can have on the spread of an infection outbreak in the hospital environment.
5. Regarding the testing and validation of the final prototype, the consortium tested the integration and functioning of all system components in a laboratory environment. We tested how the SEWIO RLTS precise indoor localization system worked in the 1-D[1] mode, which allows establishing the presence of persons on corridors or rooms that are lengthy but of small width. This can be achieved using the Vista DirectFive anchors, of which we have ordered 2 as part of the project.[1] SEWIO RTLS, 1-D working mode – https://docs.sewio.net/docs/1d-deployment-rules-38535880.html
6. As part of the current project phase the consortium also started the activities for piloting the system in a clinical environment. Several visits were undertaken to the Clinical Emergency Hospital in Bucharest in order to understand under which conditions could the pilot be started. The consortium identified several sections of the hospital where the project pilot could be carried out, in accordance with the changes that were carried out within the hospital configuration as a response to the COVID-19 pandemic. A piloting plan was created that includes the required equipments to monitor the established areas, usage instructions, procedure to hand-off the SEWIO localization tags by clinical staff, patients and visitors alike as well as the architecture of the system pilot. The consortium created a proposal to pilot the system within an area comprised by a patient ward and its adjacent corridor within the Clinical Emergency Hospital in Bucharest. Piloting the system is possible safely and by observing the right to privacy for both medical personnel as well as patients. As such, the consortium started the process of enacting the required legal framework that will enable piloting the project. This includes agreement from the hospital’s ethics committee, operating instructions and procesures for medical staff as well as setting up the informed consent process for all monitored patients.
7. Regarding the dissemination activities carried out by the project consortium, PREVENT was included in Romania’s Pavilion at the Expo Dubai 2020[1] international exhibition (Expo Dubai 2020 ran between October 2021 – March 2022). The project presentation included a presentation movie as well as specially prepared dissemination material, with the project stand manned by a representative of the Politehnica University of Bucharest. In addition, the project website was kept updated with the latest achievements and news.[1] Expo Dubai 2020 – https://www.expo2020dubai.com/

THE ARCHITECTURE OF THE PREVENT PLATFORM

The PREVENT cyber-physical platform is comprised of several hardware and software components that communicate using wired and wireless technologies. The platform’s hardware side consists of SEWIO’s RTLS system for precise indoor localization, several wireless sensor devices that were developed as part of the project by the UTI partner as well as a mini-PC system that acts as a gateway and mediates the communication between the platform’s hardware and software components. The platform’s software components are integrated with the PREVENT software server and include the required components to manage organizations and users, business rules that describe the monitored workflows, manage risk maps and the contact network as well as the simulator component, which allows simulating a wide range of scenarios and situations related with the spread of hospital acquired infections.

1.1 THE HARDWARE ARCHITECTURE

The system’s hardware architecture is illustrated within the figure below. It mostly adheres to the architecture proposed within the initial prototype phase. Events detected using the RTLS (Real Time Location System) indoor localization system, together with those detected by the devices developed within the project are transmitted to an MQTT broker, from where they are read by the PREVENT software server. In order to identify the persons who carried out actions detectable through the developed devices, we correlate the data received from the devices with the indoor localization data received through the RTLS system. Within the final prototype, user categories were identified using unique tag id’s, as each tag was assigned either to a member of staff, a patient or a visitor. Within the final prototype, notifications used to notify staff regarding the appearance of infection risk are sent via an in-application alert. The hardware architecture includes the following components:

• Wireless sensors (Bluetooth Low Energy) that employ contactless detection (Time of Flight) to detect events (such as using one of the dispensers in the figure below, disinfection of medical equipment or using the waste bin);
• Tags for determining the precise indoor location of persons within the clinical environment in order to attribute the person associated with a detected event using localization data;
• The server – a computer unit with adequate processing and storage capabilities that enables consuming, processing and storing the data produced within the hardware systems;
• Computers for results visualization and analysis, so that epidemiologists can make decisions based on the outputs of the platform.

1.2 SOFTWARE ARCHITECTURE

The detailed software architecture of the final prototype of the PREVENT platform is illustrated in the figure below.

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 the MQTT broker deployed on the gateway system. From here, data is read by the PREVENT server.

Sensor system – In-house sensor. 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.

Gateway System. The gateway component is represented by a server that runs the SEWIO software and an MQTT broker. MQTT is currently a widespread standard within the Internet of Things world.  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 using several software topics, depending on the source device.

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 information and so on. While this integration was not an objective of the PREVENT project, it is one that needs to be taken into consideration as our solution nears commercialization (technological maturity level of TRL-8 or more advanced).

Client Application – UI Simulator. Represents the access interface for the simulation component within PREVENT. It allows defining location plans (room layouts, furniture, doors, and windows locations etc.), the behavior of simulated persons (e.g., medical personnel with a pseudo-random routine) and executing simulations to estimate infection risks.

Client Application – Show Centralized Alerts / Outbreak Risk Analysis. In accordance with the system requirements initially identified within the “L1.1 – System Requirements” deliverable and maintained during project development, system users can have one of three roles: administrator, epidemiologist, or staff. The system enforces a role-based access policy and displays to each user the data set and operations for which they have rights, namely:

• Staff – alerting interface, where they can check their own alerts history.
• Epidemiologist – in addition to functionalities available to staff, the epidemiologist can access the alerting history for the entire staff.
• Administrator – access to all platform functionalities.

Client Application – Management UI. The administration component provides the required functionalities to manage the organization, clinical personnel as well as the defined business rules, alerting history for all staff, risk maps, the contact network as well as all simulations.

Server – Data acquisition. The data acquisition component allows the software server to communicate with the gateway system’s MQTT broker. Its main interface is iDataAcquisition, which provides the required connection points. Data are received using several software channels (SEWIO or DID messages, client registration, localization event, dispenser usage event etc.) and are stored within the persistent Data Store, from which they are read and used by the rest of the system’s components.

Many clinical units have already deployed a hospital information system. They contain a multitude of information that can be used to prevent infections and outbreaks, such as patient sensitivity or allergies, the layout of hospital wards and beds, information regarding immune-compromised patients and so on.

The iDataAdapter component was designed to provide a hook to which external systems can connect to send data. These will be stored within the platform, from which they should be processed. The development of this component was not under the purview of the PREVENT project but remains a key point that must be addressed when preparing an advanced version of the system that is close to market (TRL-8).

Server – Business rules engine. The PREVENT system uses an open-source implementation of a business rules engine. This implementation allows expressing business rules in the form of JSON text files. These are easy to create and verify both manually as well as programmatically. The component provides all functionalities that were required to implement the final prototype.

As defined within the system requirements, monitored clinical workflows can be managed by a user connected to the system in an administrator role. Once the platform nears a commercial-grade implementation, we aim to carry out an analysis of our selection of rule engine in order to make sure it meets the functional requirements and the scalability needed for a wide-scale implementation.

Server – Simulator. The simulator is one of PREVENT’s innovative software components. Its role is to simulate how an infection can spread within the clinical environment. The simulator includes a configuration component which allows configuring the clinical location by adding and editing its layout including rooms, doors, furniture, disinfection points as well as the location of wards and hospital beds. The component also allows simulating the behavior of clinical personnel by defining pseudo-random behavior flows.

The simulator allows testing the system’s capacity to detect risky situations for the appearance of singular infections our outbreaks depending on location layout, staff, and staff behavior as well as to discover ways and means to curb the spread of infection. In addition, the same component can be used to visualize risk maps and contact networks.

Server – Client Services. These components implement the management of system users, business rules for monitoring workflows and provides data analysis services. In accordance with project requirements, users log into their account that is governed using rule-based access rights. More so, the system uniquely identifies users within the clinical location via their tag. As such, their actions are recorded within the system, with alerts being sent in real-time via in-application notifications. Likewise, the system can identify connected devices through their unique identifier. This is required to enable monitoring rule execution and deployed devices.

System user information, role information as well as deployed device information is persisted within the platform’s data store. The Business Rules Management component allows creating, editing or deleting the business rules that are employed for determining the risk of infection transmission. The Data Analysis component is part of the simulator, and integrates the functionalities related to management and visualization of simulations, risk maps and the contact network.

Server – Data Store. This component represents the system’s data persistence layer. It is responsible for persisting all data, including organization, registered users, device data, defined business rules, workflow instances, alerts and so on.

 

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.

 

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.

 

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.