Lessons learned

There are complex and disparate ecosystems across the trust, making integrations challenging.

Additionally, much of the deployed technology is at the bleeding edge, meaning integrations for it have not yet been created. There have been delays at both MKUH and NRC with integrating the new nurse call system with existing infrastructure.  

Cyber security concerns and challenges with getting systems talking were the primary causes of the delays.

MKUH Bluetooth Low Energy (BLE) access points interfered with medical devices and restricted RTLS rollout. It was found that BLE and older Wi-Fi (in the 2.4ghz range) operate on the same radio spectrum and as such can interfere with one another’s signals, with an impact on Wi-Fi reliant medical devices. 

To resolve this Wi-Fi on 5ghz and Bluetooth 4.0+ were used, as they either use separate frequencies, or have factors built in to mitigate the issue. Find out more about the Bluetooth Low Energy Interference Awareness Scheme and Improved Channel Selection Algorithm for Connection Robustness.

Smart hospitals require a large increase in the number of connected devices. Many buildings don’t have enough power, data or space for additional cabling and required considerable works to adapt this in. 

This is further complicated by challenges accessing clinical spaces and environmental factors such as asbestos and lead.

Network switches were installed in rooms without adequate cooling, for example, staff changing rooms, due to space constraints. The installation of cooling in these rooms required removal of staff lockers causing disruption and inconvenience which impacts staff engagement and buy in.

Instances of contractors not following correct procedure or not following procedures consistently. The trust uses a number of separate contractors and not all correctly followed processes. In one installation the IoT sensors were not correctly secured. This was discovered at a later date and all sensors had to be removed and reinstalled, causing time delays and duplicated effort.

Some trust processes are not agile, and it can be extremely difficult to schedule access for estates, contractor and clinical teams, leading to delays.

There is a lack of robust evidence and standardisation of evidence for some of these technologies, which is needed to effectively measure and manage benefits.

Case studies on deployment of these technologies can be presented too optimistically and the benefits may not be achievable. A lack of standardisation in benefits measurement makes it difficult to plan and estimate benefits without an inhouse study.

It is vital to be able to objectively measure benefits. This cannot be achieved without an effective baseline and much of this information does not exist.  For example, incidents of patient aggression can go unreported, so it is difficult to measure changes in this metric.
 

Co-production and technology adoption

Busy staff often do not have the time, faith or experience to engage with new IoT technology, and the impact of change on them is hard to overstate. Staff can find these changes stressful and need to be supported through regular and open engagement.

There is a need to get concepts off the drawing board and into a live environment to prove their effectiveness. Staff and patients are the best people to identify what staff and patients need, and it is vital to include them and streamline this process.

Staff don’t have experience or enough time to engage in evaluating technology or the impact of change. If time isn’t made available there is a risk that they won’t see the benefits of innovation, and will be put off by their experience of past implementations which are now no longer in use.

Some IoT technology can create anxiety for staff around being observed and monitored.

Staff engagement in the design process is essential and transparency of what the technology is being used for, and why, is key. 

Broad engagement is essential to ensure inequalities are addressed and digitally disenfranchised groups are not further isolated by the implementation of technology. 

Digital and estates resource and skills

Additional resource and project capability is required to run proof of concept trials, it is not possible to deliver these or support the aspirations of a smart hospital without an impact on BAU capability. 

Where technologies have been implemented by external consultants rather than internal staff this can lead to a lack of knowledge of the technologies internally.

Front line staff should be included in the testing and assessment of IoT technologies, as they are often able to spot issues that may not be identified in the planning or procurement stages and to ensure that staff are not just the passive recipients of technology.

Additional resource and project capability is required to run proof of concept trials, it is not possible to deliver these or support the aspirations of a smart hospital without these resources. Digital services in healthcare are under immense pressure with existing work and 'just keeping the lights on' is a full-time job. Undertaking priority digital projects such as EPR rollout, can leave little time or resource for other lower priority digital implementations.

Growth in digital demand and requirement for IT and cyber security support, necessitated by Covid-19 and increased cyber threats has also led to increased resource pressure.

Planning and resource allocation must take these factors into account to minimise impact of failure or cancellation of trials and implementations.  

Cross team working  

IoT technologies often cross legacy organisational structures and require organisational and operational lines to be redrawn in their management, often between estates and digital functions. This requires either transfer of ownership and responsibility from estates to digital, or the creation of digital roles within estates teams. 

Estates and digital need close alignment. A lot of traditional estates technologies (nurse call systems, CCTV, Security, access control, BMS) heavily use technology and data and require joined up decisions, shared ownership and knowledge sharing.

These technologies must be procured with all stakeholders involved, such as digital and IT stakeholders, who are required to ensure that the technical capabilities address user needs and that the support required to maintain these capabilities is in place. 

Working with contractors

Extremely low profit margins mean that contractors can be under pressure. It is key to capture and track commitments made early on to ensure they are not forgotten or engineered out later in the process.

It is important to build and maintain industry relationships and structures so that the right partners and expertise are engaged, and the trust receives the best advice or value for money. 

Understand the terms of contracts signed and what these allow, as subcontractors may not be the best partners for the trust and may not have the expertise required.

Visibility and control are also limited once the contract is set so it is key that the trust has a robust and detailed set of requirements at the outset of the contract.

Requirements for this technology can be difficult to define considering contracts could be agreed 5 years in advance of buildings opening, during which time the technology will evolve.

Bear in mind that many 'off the shelf' technologies are developed to meet the needs of different countries' healthcare systems rather than tailored to the NHS or trust. It is important to ensure that these technologies can meet local needs to reduce the risk of shoehorning a technical solution to try to fit a different problem or solve a problem that does not exist.

In some cases, trusts may be better placed investing in leading experts to design IoT technical specifications.

There aren’t yet many examples of Smart Hospitals in the UK, and industry expertise is not yet established. As a result, contractors may not be well informed or experienced enough to deliver a modern Smart Hospital.   

Funding

It can be challenging to secure funding for innovation trials, so a strong case taking into account the full costs and benefits should be made. 

Where funding is available it can often skew to either capital or revenue. This can mean that when technology can be procured the funding for adequate ongoing resource does not exist to keep it supported and operational through its lifetime. 

Consider funding and finance in a broader context and understand that there may be challenges in other areas of programmes which lead to reduced budgets and the need for value engineering of digital innovation projects to achieve the same with less.

Lifecycle costs need to be fully understood and mapped out at the business case stage to avoid challenges and lack of funding later. For example:

• the cost of battery changes for IoT devices over their whole lifetime needs to be accounted for  
• the true costs of cloud. It is important to understand egress and portability of cloud-based data at the start and embed in contracts to limit 'lock-in' to a single supplier. 

System overlap

Understand if solutions are interoperable at the outset to avoid ‘lock-in’ and not limit future options. Many of these technologies are proprietary and may have overlaps. This can lead to multiple conflicting sources of information from disparate solutions, limiting the value and causing an administrative burden.