Abstract
Summary
The COVID19 pandemic created a surge in demand for critical care equipment against a backdrop of fast-moving geographic virus hotspots. A team from IBM Europe was put together to prove that a devolved healthcare system can be rapidly bridged by a mix of advanced and legacy technologies to provide a federated view of critical care equipment deployment and use during an emergency. This was achieved with the deployment of predictive analytics and blockchain, integrated with conventional hospital management system. The corollary investigation determined the manner in which this system can be harnessed in a postemergency recovery to provide a national supply chain efficiency backbone.
Method
During a period of 2 weeks, a team of IBM consultants set up a technology sandbox environment to represent a network of an equipment manufacturer, a central national emergency monitoring center, and several hospitals managed by their respective trust organization. Within this environment, a hospital asset management system, Maximo, was configured to manage and track critical care equipment within a hospital; a blockchain traceability platform, IBM’s Blockchain Transparency System, was configured to ingest multiple hospital data reports; and a predictive analytic dashboard, Watson Analytics, would retrieve data from the blockchain platform to supplement other data sources to provide national views and support decision-making for the supply and movement of equipment. Three key principles in the design of this environment are speed, reuse, and minimal intrusion.
Results
The hypothesis was to test whether the chosen technologies can overcome the challenges of misaligned demand and supply of critical care equipment during a national emergency. The execution of the tests led to successful simulation of three scenarios: (1) the tracking of the location and usage history of any single equipment that has been placed into the network; (2) the movement of equipment between independent hospitals is recorded and reported; (3) a real-time interrogation of the current location and status of all registered equipment.
Conclusions
The successful completion of this proof of concept has demonstrated that emerging technology can be used to overcome poor macro level coordination and planning, which are the drawbacks of a devolved healthcare system. The corollary was that this proof also demonstrated that blockchain technology can be used to prolong the useful life of conventional technology.
Keywords: COVID19 pandemic, critical care, Watson
BACKGROUND
Introduction
The United Kingdom operates a hybrid-federated healthcare system for its population. The four countries constituting the United Kingdom—England, Wales, Scotland, and Northern Ireland (NI)—each have their own publicly funded healthcare system and are accountable to separate governments and parliaments, together with smaller private sector and voluntary provision. As a result of each country having different policies and priorities, a variety of differences now exist between these systems. Additionally, within each country and region, hospital trusts have the independence to operate their hospitals—allowing for localized flexibility but detracting from national coordination. This hybrid-federated healthcare system, where healthcare policy and funding are managed centrally but healthcare execution is decentralized, is not unique to the United Kingdom. Australia, Spain, Italy, and Brazil have a similar healthcare system, and countries like Taiwan, United Arab Emirates, etc. are moving from a centralized health care to a hybrid-federated system as in the United Kingdom.
Figure 1 provides an overview of the patient–provider ecosystem:
Figure 1.
Healthcare system in the United Kingdom.
Patients are assigned to primary care units, which are the local general practitioner (GP) clinics.
The GP will refer the patients for specialized care when required, at the hospitals (except for accident and emergency where patients are seen directly).
Doctors and medical care workers are certified to work at hospitals and clinics.
Hospitals are managed by trusts with a trust capable of operating several hospitals.
The devolved nature of health care means that the hospitals/trust are governed by four different national health services (England, Wales, Scotland, and NI). Each national health service sets its own key performance metrics, standards, and also sets the levels of care to be provided within its jurisdiction. It also provides funding to hospitals and GP practices.
In turn, the national health services respectively receive federal government funds obtained from taxpayers as well as policies and guidelines to improve the quality of care.
This pre-COVID19 situation of health care in the United Kingdom had both its supporters and detractors. Nevertheless, it is a working system and shares similarities with healthcare systems in other countries globally. The arrival of the COVID19 emergency caused an unusual high surge in demand for respiratory treatment and a corresponding demand for critical care equipment, specifically ventilators. This situation was exacerbated by fluctuation in virus hotspots, leading to fluctuating demand for ventilators, which normally would be positioned as on-site equipment.
Objectives
The overriding medical objective in the COVID19 emergency is to continually provide the critical care assets, equipment, and services at the point of need in response to the dynamics of the COVID19 situation, and to provide enduring, assured, and optimized operational resilience in the immediate aftermath of the crisis.
This provided several challenges:
-
The challenge of matching the demand for critical services with the availability of assets, equipment, and specialist staff. Effective management requires
a clear, timely, and accurate picture of the dynamically changing data to indicate what equipment is available, where it is located, and where it is needed for the moment.
tools to model dynamic demand patterns and to link these with supply processes and operational workflow at both local and regional level.
-
The absence of a coherent and unified view of critical assets and equipment presents challenges for care providers and the supply chains that support them—and ultimately acts to impede clinical effectiveness:
A lack of visibility (an aggregated picture) makes it difficult to plan effectively and match the demand and supply dynamics of key assets and equipment.
Effective asset and supply chain management will be as important in the post-COVID19 NHS (National Health Service), as it is today.
-
New equipment needs to be assured and managed effectively through life:
There is a need to understand the provenance and to assure of key assets and equipment.
A solution is needed to manage and remedy failure patterns to optimize utilization and availability at local and regional levels. (N.B.: This refers to the optimal use of the commissioned critical care equipment and not to the optimization of the critical care equipment manufacturing process.)
Thus, the objective of the “IBM Critical Care Equipment Tracking” proof of concept is to demonstrate that emerging technology, in the form of predictive analytics and blockchain, can be operated in a nonintrusive manner to overcome the aforementioned operational challenge.
Scope
The proof of concept is based on the UK healthcare system but the situation is deemed similar and applicable to the aforementioned countries that have similar healthcare systems. To define the parameters of the proof of concept, the ecosystem for critical care equipment manufacturers, users, and a national coordination body was modeled and is represented in Figure 2.
Figure 2.
Participant model.
Figure 2 outlines the organizational entities in the critical care equipment supply chain. A detailed explanation of the two use cases is described later, based on which the IBM team built the scenarios necessary for us to prove the concept. Note that the manufacturing process is excluded from the scope of this effort.
Use case 1—use and maintain effectively
In this use case, the goal is to manage and track critical care equipment via the hospital management system on a microlevel, that is, within an individual hospital. Thus, the key participants include a trust to manage equipment orders, hospital to manage operating assets, a field technician responsible for investigating and fixing failures, and a manufacturer to create and maintain the critical care asset.
Use case 2—monitor and distribute efficiently
In the second use case, a macrolevel view is required to provide visibility of the supply and demand for critical care equipment, and to make decisions on distributing the equipment across England. The key participants include the national demand management (in this proof it is assumed to be a central organizational body such as the UK National Healthcare Service) with a holistic view of stock levels across hospitals, a trust with the view of stock levels in hospitals under their management, a hospital with its local stock levels, and a manufacturer with the equipment stock in its warehouses.
METHOD
Key Principles
Three key architectural principles were mandated in this proof of concept. They are
Speed of deployment. This means that a fit-for-purpose approach is prioritized over a best-of-breed approach for decision-making in this test.
Minimum intrusion. During a period of emergency, a criterion for success is measured by how little changes have to be made to existing hospital technology and operations.
Realistic. A blend of conventional technology with emerging technology has to be shown working in alignment, as opposed to a completely new system that disregards prior sunk investment.
The aforementioned principles were translated to the system context in Figure 3 and the following conditions and assumptions in the proof of concept:
Figure 3.
System context.
Speed of deployment is paramount, and new functionalities will be prioritized and staggered. The normal duration for a technology proof of concept project is between 4 and 8 weeks. The goal set for this project at the start of the project was to achieve this in less than 4 weeks. At the conclusion of the project, it was achieved in 2 weeks. The minimum functionality to achieve the “Process Flow” was prioritized, and the additional functionalities were documented in a “backlog.”
Front end—desktop html access prioritized over mobile access.
Integration—CSV (comma-separated values) file upload (for excel) in the first instance, followed by APIs (application programming interfaces).
Infrastructure—all technologies to be demonstrated on the cloud. However, a single cloud provider is used. Volumetric scaling and hardening of emerging technology are acknowledged challenges when deploying beyond proof of concept into production environments. This will be a subject to be tackled in the next phase of work. In this phase, we are taking the approach of testing with low volumes.
Security—first iteration with single-factor followed by two-factor in subsequent iteration.
Design Requirements
The target architecture for this proof of concept was developed using existing IBM components. The major components are listed in Figure 4.
Figure 4.
Technology components.
The main components are:
Watson Analytics. IBM’s Watson studio deployed as a software service in the IBM Cloud with Cognos Dashboard service. The focus of this analysis is to proof the accuracy and secure the availability of data for Watson Analytics’ use. The proof is not to test the predictive modeling engine or criteria that have been configured to produce the dashboard.
Maximo. Critical Care Asset Monitor is a multihospital cloud platform for healthcare providers to manage lifesaving equipment. The focus of this analysis is to proof the accuracy and secure the availability of data from Maximo for use by blockchain and Watson Analytics. The proof is not to test the functionality of Maximo.
Blockchain. IBM’s Blockchain Transparency system configured to trace the equipment provenance.
IBM Security. The integrity of the system’s security is assumed and not the purpose of this test. Hence, standard IBM cloud security configured as required.
In this proof of concept the blockchain protocol used is Hyperledger Fabric. Four nodes were employed, which represent the manufacturer, the central health authority, a hospital running on a Maximo hospital management system, and a non-Maximo hospital system, respectively.
An integration layer is defined in the target architecture, but for this, it was not implemented. Instead, data were ingested through XML (Extensible Markup Language) files being uploaded into the system to simulate the results of system interfaces. The design of the integration, though not part of the test, is included in Figure 5 for completeness of design.
Figure 5.
Integration and data flow.
An observation on the role of data standards was made during this project. The availability and adherence to an open data standard would play an important factor in the ease for deployment. However, the team also recognizes the practical hurdles in practice for adoption of such a standard. Therefore, in this proof of concept, we have adopted a data translation layer to adapt the flow of data between technology components.
Process Flows
In addition to the definition of the participants in the ecosystem for tracking ventilators (see Figure 2), it is the usual practice for IBM Blockchain consultants to define the process map to model the events and facilities (or locations) that are involved. This, in turn, also provides guidance to the optimization of the blockchain peers and nodes. Figure 6 demonstrates the process flow of a critical care equipment asset (a respiratory ventilator in this scenario) as it moves throughout the supply chain from the asset being created by a manufacturer through to being decommissioned.
Figure 6.
Business process map of a ventilator.
The process flow comprises the following steps:
A ventilator is created and commissioned at a manufacturer location.
The ventilator is shipped from the manufacturer to the central storage hub, where critical care equipment assets are stored until being distributed to hospital locations.
Once a strategic decision on the allocation of the ventilator is made, it is dispatched from the central storage hub to a hospital.
Upon arrival at the hospital, the ventilator is inspected by a hospital technician. If it is in good order, the ventilator is installed in a hospital ward, and a patient is put on it.
Based on the demand for ventilators across hospitals in England, the ventilator may be requested by another hospital if there is a shortage. In this step, the ventilator is shipped from the first hospital to the new hospital that has requested it.
Once the ventilator has arrived at the new hospital, it is inspected by its technician and is subsequently put in use if it is in good order.
After a certain time, the ventilator may break down or develop a fault, in which case it will need to be repaired, serviced, or recalled from the supply-chain and ultimately decommissioned. In this step, the ventilator is sent from the hospital to the central storage hub.
The ventilator is decommissioned at the central storage hub.
This process flow represents the high-level functional requirements, against which the multiple technologies were configured to enable the execution of the tests.
Execution and Test Cases
The availability of test data is always a concern for technology projects. In this case, we were using all IBM technologies and had access to demonstration data, that is, accurate but simulated (or desensitized) data used by Maximo presales personnel to demonstrate their Maximo’s functionalities. This became the base data that were used in the following test cases.
Test case 1—asset management
Track assets (e.g. equipment), their location, movement, and state/condition (Table 1).
Table 1.
Asset management use case (UI = user interface design).
| Test script # | Test script description | Entry criteria | Exit criteria | Results May 12, 2020 | ||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 1 | Ventilator asset is commissioned | First and essential step to initiate the process | Asset recorded as being commissioned and shown in the blockchain platform UI | ✓ | ✓ | ✓ |
| 2 | Ventilator is shipped from manufacturer to the central storage hub | Asset has been created on the blockchain and appears as commissioned in the blockchain UI | Event of shipment from manufacturer location and receiving advice at central storage hub were recorded and shown in the blockchain UI | ✓ | ✓ | ✓ |
| 3 | Ventilator is dispatched from central storage hub to a hospital | Asset has been created on the blockchain and appears as commissioned in the blockchain UI | Event of shipment from central storage hub and receiving advice at the hospital were recorded and shown in the blockchain UI | ✓ | ✓ | ✓ |
| 4 | Ventilator is shipped from hospital A to hospital B | Asset has been created on the blockchain and appears as commissioned in the blockchain UI | Event of shipment from location A and receiving advice at location B were recorded and shown in the blockchain UI | ✓ | ✓ | ✓ |
| 5 | Ventilator status is updated to being inspected by a technician | Asset has been created on the blockchain and appears as commissioned in the blockchain UI | “Inspecting” event recorded and shown in the blockchain UI | ✓ | ✓ | ✓ |
| 6 | Ventilator is recalled from the supply chain | Asset has been created on the blockchain and appears as commissioned in the blockchain UI | Asset marked as decommissioned in the blockchain UI | ✓ | ✓ | ✓ |
Test case 2—workflow management
Triggering the request for work asset/equipment lifecycle management activities (e.g. maintenance, reallocation, ordering, purchasing, approvals) for regular or ad hoc tasks (Table 2).
Table 2.
Workflow management use case (PR = pull request, UK = United Kingdom).
| Test script # | Test script description | Entry criteria | Exit criteria | Results May 12, 2020 | ||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 1 | Asset added to the hospital management system (Maximo) | First and essential step to initiate the process | Asset is recorded in the hospital management system (Maximo) database | ✓ | ✓ | ✓ |
| 2 | Notification of a failure of an asset | Asset exists in Maximo database | “Damaged ventilator” is displayed on the Maximo dashboard—the Work Orders section | ✓ | ✓ | ✓ |
| 3 | Raise a service request for the damaged asset | Asset exists in Maximo database and is shown as “damaged/not operating” | Inspection request added to the asset on the Maximo dashboard | ✓ | ✓ | ✓ |
| 4 | Push the forecast for the latest suggested United Kingdom demand for ventilators from Watson into Maximo | Watson prediction model (described in use case 3) produces output for demand for ventilators across the United Kingdom. User confirms and forecast is pushed into Maximo | PR pull request updates from Watson prediction model are displayed in Maximo | ✓ | ✓ | ✓ |
| 5 | Approve the latest suggested demand for ventilators | PR updates from Watson prediction model are displayed in Maximo | User approves the PRs and updates the forecasts to the relevant hospitals | ✓ | ✓ | ✓ |
Test case 3—analytic models
To predict demand and usage of assets/equipment at hospital or other locations. The purpose of the test here is to test the secure availability of the data for use in the predictive analysis, rather than test the accuracy of the criteria within the predictive modeling tool (Table 3).
Table 3.
Analytic models use case.
| Test script # | Test script description | Entry criteria | Exit criteria | Results May 13, 2020 | ||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 1 | Watson prediction model produces output for demand for ventilators across the United Kingdom | Input of the following demand data:
|
Watson Analytics displays the predicted demand figure in the “Forecast stock demand” dashboard section categorized by asset type | ✓ | ✓ | ✓ |
RESULTS AND KEY LEARNINGS
The tests described in “Execution and Test Cases” section was executed over 2 days and repeated twice to different colleagues as observers. The successful tests (results of the three cycles of test recorded in “Execution and Test Cases” section) conducted earlier demonstrated the success of meeting the objective of the proof of concept—to demonstrate that emerging technology, in the form of predictive analytics and blockchain, can be operated in a nonintrusive manner to overcome the earlier operational challenge. In the process, the authors were able to elicit three key learnings: data, interoperability, and intrusion.
Data
It is crucial in this proof to have a canonical data structure, through which we are able to exchange data between the three main distinct and separate technology components (Table 4). It is recognized that an industry data model is neither a current reality nor would it be realistic to assume that one is available. A critical decision was made to adopt the Sitrep report. Since October 2017, all NHS hospitals in the United Kingdom are required to submit a daily situation report (Sitrep) through an automated data collection system. The authors used a Sitrep report to identify data that were relevant to the use of ventilators and produced a logical data model, which was further modified to produce a physical data model used in the creation of the XML files used in these tests.
Table 4.
Data structure for interoperability (API = application programming interface, ID = identification, REST = representational state transfer, XML = Extensible Markup Language).
| Data file format | Communication channel | Data source | Data destination | Data fields | Output |
|---|---|---|---|---|---|
| XML | REST API calls | Maximo hospital management system | Blockchain transparency system |
|
A traceable record of an asset traveling from one location to another, tagged with an event ID |
The decision to use the Sitrep data is based on the fact that it would reflect the real-life situation, that is, Sitrep data are already being used for decision-making. Additionally, the quality of the data is deemed of secondary importance to the objective of the proof of concept—which is to proof that emerging technology, in the form of predictive analytics and blockchain, can be operated in a nonintrusive manner with existing conventional technology.
Interoperability
Demonstration of interoperability is crucial to meet the objective of this proof. At its basic level, data interoperability level was achieved by this proof of concept. The solution established the interconnectivity requirements needed to exchange data between disparate applications, on different technologies. The canonical data model referred in the earlier section provided the format, syntax, and organization of data to be exchanged. This is encapsulated in Table 4.
The team first looked at the data captured by Maximo hospital management system and analyzed which data points should be captured by the blockchain system—time of event, asset number, and location data.
The configured XML files allowed data obtained from hospital system (Maximo) to be incorporated into blockchain with ease and with no intrusion to the Maximo system. Upon data ingestion into the blockchain, a traceability flow for an asset was produced with all the relevant data carried over with it.
Minimal Intrusion
Investment in technology is a necessity in all industries in the current digital economy. Ironically, the hurdle to adopting emerging technology is prior investment in technology. The sunk capital cost of technology investment needs to be recouped over time through returns via benefits of the technology—constraining new investments until the prior investments are recouped.
The success of this proof demonstrated that emerging technology can be adopted with minimal intrusion to existing systems of records—allowing emerging technology and legacy technology to coexist.
CONCLUSION
Implications for a Devolved Healthcare System
The objective of this solution was to prove that, through appropriate integration of advanced technologies with legacy technologies, hurdles relating to coordination and planning caused by the devolved nature of the UK healthcare system can be reduced. That is, the solution outlined in this paper proved that the constraining elements, or the pain points, of a devolved healthcare system can be mitigated by blockchain technology.
In the process of proving this, the authors also showed that emerging technology does not have to replace legacy technology. They can work together, thereby prolonging the life of investments on conventional technologies.
Post Emergency Recovery Implications
Even in the pre-COVID19 emergency period, many organizations had been frustrated with their traditional forecasting models, which relied heavily on historical data. Many organizations had tried to assemble a supply chain control tower—a cross-functional team reviewing real-time data to make decisions quickly. This had some success in some organizations, but inter-organization data sharing collection was still proving to be a hurdle.
The critical care equipment proof outlined earlier demonstrated how a decentralized ledger overcame this hurdle. In the post-COVID19 world, the authors see this as an effective way to implement the supply chain control tower as an inter-organization planning and monitoring mechanism, which would replace forecasting methods based on historical data. If it is done correctly, a decentralized ledger control tower will be an effective approach, whether in an emergency or not. The authors also believe that the embedded nature of smart contracts in blockchain technology is an open door for the implementation of the next step of supply chain transformation—autonomous planning. The vision for autonomous planning is one in which blockchain and advanced analytics are used in harmony with legacy systems, in every step of the supply chain planning process, enabling faster and better decision-making with minimal manual intervention.
Beyond the Proof of Concept
This proof has been conducted within narrow constraints to prove that the emerging technology, particularly predictive analytics and blockchain, can work with legacy healthcare technology to assist with handling the current COVID19 emergency. Additionally, it has provided insights into how it can be harnessed in a postemergency recovery situation. As a next step, the authors envisage that potential adopter will utilize the knowledge from this proof of concept to develop pilot projects that will see measured steps toward adopting and adapting this to suit localized data requirements and other nonfunctional requirements such as security levels, volumetrics, and latency.
ACKNOWLEDGMENTS
The authors acknowledge the following: IBM; Jessica Douglas—Project Sponsor; Richard Bolton—Supply Chain Expert; Robert Musgrove—Cognitive & IoT; Kevin Elliott—Maximo Solution Manager; Davorka Vunic—Maximo Managing Consultant; Mark Restall—Cognitive Business Decision Support.
Funding statement
Internal IBM funding was the source of funding that has supported the work. It is part of the IBM response to contribute to the effort to fight the COVID19 emergency.
The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
Conflicts of interest
The authors declare no potential conflicts of interest.
Contributors
Both authors contributed to the conception, writing, and revisions to the article.