Demonstration of IoT-based devices for non-critical support in hospitals

Introduction

This project investigated various ways in which low-cost condition monitoring systems, typically used in industry, can be easily repurposed for non-critical IoT-based support in hospital environments.

The project was executed primarily by a team from the Distributed Information and Automation Laboratory (DIAL) at the Institute for Manufacturing, University of Cambridge, with strategic inputs from Addenbrooke’s Hospital, Cambridge.

The DIAL team consisted of researchers tasked with investigations and further development of the solution, and postgraduate students responsible for conducting on-site interviews with various stakeholders in Addenbrooke’s hospital.

Project aims

This project addressed one of the challenging issues in health information technologies, which involves using low-cost off-the-shelf technologies in digital caring environments widely used for healthcare support, evaluating patient safety, and hospital performance. Additionally, modern pandemics like SARS-CoV-2 have placed significant pressure on hospital facilities, making the need for for such solutions more acute.

This project’s main goal revolved around the question “can we adapt and employ existing methodologies and technical solutions in order to enable the rapid development of IoT-based solutions for helping healthcare professionals in non-life-critical situations?” This project's aim was to deliver add-on solutions, which, although they did not affect the regular working of a hospital, were intended to enhance overall productivity and performance.

What was done?

This project undertook the following three main activities:

• Identifying the most suitable IoT-based digital solutions on the market to support healthcare professionals in non-life-critical situations.

• Developing a low-cost IoT prototype that monitored the use of healthcare equipment.

• Contributing to the development of a research proposal to national funding bodies such as Innovate UK, to enable more hospitals to adopt and benefit from existing manufacturers’ innovative IoT solutions and the systems already on the market.

Results

This project managed to identify intersecting points between the domains of manufacturing and medical services in hospitals.

The requirements of various stakeholders in a hospital environment were identified through multiple in-person interviews. This solution map made it possible to explore, identify and develop specific IoT-based solutions for non-critical hospital support, in particular by repurposing low-cost digital solutions already applied to address digital solution requirements in manufacturing SMEs.

As a result, one demonstrator was also rigged-up to address one such issue identified using the information about overlapping hospital and manufacturing domains.

Deliverables and other tangible outputs

The tangible deliverables of this project are divided into two parts.

1. Digital solution identification and prioritisation

This first part of the project identified and collected the requirements of hospital tasks suitable for implementation using existing digital solutions built for manufacturing. Several interviews were conducted by an MPhil Industrial Systems, Manufacture, and Management (ISMM) student whose project looked at IoT challenges and opportunities in hospital support processes.

The interviewees consisted of several clinical engineers, clinicians, nurses, and other healthcare professionals. The interviews were conducted in-person and followed the format of the requirements-gathering workshops of the ‘Digital Manufacturing on a Shoestring’ project.

The interviews consisted of 30-minute recordings for each interviewee; the interviewees were: two clinical engineers, three nurses, two estates managers/engineers, and one chief information officer from the hospital.

The theme of these interviews spanned across topics such as equipment maintenance, logistics and facility management.

Table 1 below lists some of the common hospital tasks and their specific requirements as identified from the interviews with the hospital stakeholders.

A sample excerpt from an interview with a clinical engineer is as follows:

“There’s been some talk about putting sensors into machines to detect when they are powered up and in use and record this information somewhere… So we can actually monitor whether or not that piece of equipment is running or sat on a shelf doing nothing in a ward… Something that would tell us this would be fantastic.”

Identifying such solution requirements led us to come up with the following chart of possible requirements at a hospital and possible demonstrators from the manufacturing domain, which can be easily repurposed for hospital operations. A list of these identified solutions is given in figure 1. The red selection box in figure 1 shows the demonstrator we repurposed and built for this project.

2. Low cost IoT demonstrator development

This part of the project aimed to develop one or more IoT demonstrators to support non life-critical activities. To this end we used the low cost digital solution development guidelines from the ‘Digital Manufacturing on a Shoestring’ project, where the challenges and opportunities associated with integrating low-cost technologies into industrial environments were studied together with the style of software/hardware architectures best suited for incorporating such solutions into industrial environments.

Based on one of the identified requirements in hospital operation, concerning utilisation of equipment, we chose a demonstrator development task for this short-term project. Figure 2 outlines this requirement. The task involves determining equipment utilisation in hospitals.

The type of hospital equipment involved could include medical monitoring devices, powered diagnostic devices, and other electrical/electronic installations in the hospital. The aim of this demonstrator is to determine:

• If a piece of equipment is being used or not?

• If it is being used, then for how long, at what intervals?

• Who is the equipment allotted to or what is the location of the equipment?

This demonstrator also follows the following design approaches:

• A clip-on system, which in no way affects the existing workflows in a hospital or alters/tampers with equipment.

• The complete system should integrate seamlessly with existing infrastructure at the hospital.

• The system or process, at no point in time, will be used for, or interfere with patient diagnostics. Rather, it may be considered as a setup for machine diagnostics.

In our demonstrator we employ two sensor types – current sensor and RFID readers – to address the issues of equipment utilisation and its location. The development of this demonstrator follows a unique approach, which we refer to as the ‘shoestring approach’, which uses three levels of aggregation for describing a complete solution. From the bottom up, it consists of the following three layers.

1. Technologies

These focus on the exact individual technologies/readily available products that can be used for developing a completely new solution using a combination of other technologies.

For example, some of the technologies might be InfluxDB (a technology for storing time-series data), MySQL (a technology for storing relational data), MQTT (a technology for publish-subscribe communication architecture), WiFi (a technology for wireless communication between two devices).

2. Building blocks

These comprise of at least one or more technologies along with their interfacing drivers (hardware/software). Building blocks are a collection/group of technologies, which come together to achieve a singular functionality or task. These groups are more focused on achieving a unique singular functionality when different technologies are brought together.

For example, figure 3 shows a power building block. The core function of this building block is to read the changes in power consumption of a device it is monitoring.

However, internally, it consists of technologies such as a non-contact sensor for reading current, a hardware filter and amplifier circuitry to reshape the signal generated from this sensor, a microprocessor to make sense of the data read by the sensor and packing the data so that it is easy to understand for a non-technical person, and finally a WiFi, which ensures that data from the sensor can be forwarded to other building blocks or systems from this building block.

It may be noted that there is no fixed arrangement for what goes inside a building block. It should be rather seen as a collection of technologies, focused on achieving a single task. Similarly, figure 4 shows an RFID building block. Its sole purpose is to read RFID tags/cards and forward the read data to another building block.

3. Services

These aim to achieve a core and complex task, which might be split up into multiple sub-tasks. Services are a collection of building blocks, which look into achieving a broader task definition for a technology development task.

Services can be data collection, data storage and management, user interface, system state. Figure 5 shows the overall view of our demonstrator, both in terms of the services (top) and the building blocks (bottom).

Health and wellbeing

Manufacturing

Derisking IoT adoption

Financing IoT development