The proposed framework employs a four-step process model, systematically divided into five distinct phases. Each phase utilizes the four-step process, as illustrated in Fig. 2.
1) Domain Knowledge Acquisition: Conceptual Digital Twins (CDTs) are created through a thorough inspection and process mapping of takt time analysis, critical care unit guidelines, and forms used to document the treatment process.
2) Key Resources Knowledge Acquisition: Physical Digital Twins (PDTs) are developed by analysing workflows and business processes (e.g., BPMN, schemas, and protocols) using data from EMR systems, diagnostic devices, and observation forms.
3) Integration of PDT and CDT: The PDT and CDT models are combined into a unified framework that reflects all relationships and mappings between the components.
4) Design Evaluation and Execution: The design is validated against artifacts in the target platform (Microsoft Azure in this case) to ensure robust implementation and execution environments.
Throughout this process, the overall design aligns with the foundational criteria and requirements specific to the healthcare domain. For instance, domain knowledge is acquired through rigorous inspection of workflows, CCU forms, protocols, guidelines, and consultations with healthcare professionals. The design undergoes comprehensive validation through testing and baseline verification to ensure consistency. Additionally, the design incorporates criteria for compliance with healthcare standards (e.g., security and communication protocols like HL7). Finally, the knowledge generated from the DT models can be shared across other organizations.
1) Domain Knowledge Acquisition
Identifying process maps is a key part of creating the Conceptual Digital Twins Layer (CDTL). During the design phase, we scanned observation forms (n = 116) to classify them according to the related processes carried out by nurses and doctors. These paper-based observation forms were empty, containing no patient-related data, and were used to identify data points and the structure of the diagnosis and treatment processes. Due to the unstructured nature of tasks performed by doctors, we created process maps (n = 1) using forms to record daily entries (n = 21). In contrast, the structured nature of tasks performed by nurses led to create process maps (n = 6) using forms to document 1) daily entries (n = 22) 2) peri-operative tasks (n = 1) 3) medical diseases (n = 1) 4) procedure lines (n = 1) 5) admissions (n = 1) 6) death and dying processes (n = 1). The study was limited in time and scope, focusing on user roles (n = 2), with process maps created for doctors (n = 1) and nurses (n = 6). Table 10 shows classification of observation forms used in diagnosis and treatment tasks by doctors and nurses based on process groups. As shown in Fig. 3 the classification was then mapped into process maps to identify the rules, roles, processes, and standards of each workflow. Breaking down each task into a flowchart helped to communicate domain knowledge about tasks and activities in the Critical Care Unit to technical experts. During this phase, the study identified forms, tasks, actions, patients, staff, and units as Conceptual Digital Twins (CDT).
Table 10
Classification of observation forms used in diagnosis and treatment tasks by doctors and nurses into process groups.
|
Role
|
Process Map
|
Tasks
|
|
Doctor
|
Daily Entries
|
1) WZW101 09/17 Clinical Notes 2) NGV903 03/19 Consent Form 1 - Patient Agreement to Investigate or Treatment 3) NGV1220 04/23 Critical Care Unit Prescription and Administration Record 4) NGV1284 10/17 Critical Care Patient and Family Communication Record 5) NGV1550A 09/23 Treatment Escalation Plan (TEP) To be completed for all patients 6) NGV1914 01/18 Critical Care Unit Daily Review 7) NGV2031 11/20 Do not Attempt Cardiopulmonary Resuscitation 8) NGV2035 04/18 Critical Care Microbiology Report 9) NGV2064 07/22 Critical Care Unit Admission 10) NGV2343 06/21 Major Haemorrhage Protocol Blood Administration Record Dial 2222 11) Medical Admission Data
12) Critical Care Microbiology Results Record 13) Invasive Procedure Safety Checklist: Tracheostomy 14) Invasive Procedure Safety Checklist: CVC/Dialysis Catheter/PICC Insertion 15) Invasive Procedure Safety Checklist: Arterial Line 16) Procedure Checklist: Pruning 17) Mental Capacity Assessment 18) Patient Demographics 19) Parental Nutrition Prescription 20) Medical Discharge Data
|
|
Nurse
|
Daily Entries
|
1) FNGV1626 13/18 Malnutrition Universal Screening Tool (Must) and Core Care Plan (Adult) 2) WZP198 10/17 Fluid Balance Charts (Adults) 3) WZP538 01/19 Observation Chart for NEWS (National Early Warning Score) 4) NGV785 11/22 Critical Care Unit 5) NGV836 12/21 Adult Prescription and Administration Record 6) NGV1220 04/23 Critical Care Unit Prescription and Administration Record 7) NGV1284 10/17 Critical Care Patient and Family Communication Record 8) NGV1497 12/17 Patient Orientation Checklist - Nursing Staff to Complete 9) NGV1516 10/15 This is my Hospital Passport For people with learning disabilities coming to hospital 10) NGV1580 05/18 Adult Inpatient Admission Information Essential Assessments Activities of Daily Living Initial ADL Assessment 11) NGV1742 03/17 Critical Care Pressure Ulcer Prevention Assessment and Core Care Plan (Adult) 12) NGV1835 06/19 Nurse Handover/Transfer Safety Checklist for Receiving Ward 13) NGV1881 03/16 Duty of Candour Member of Staff carrying out Duty of Candour 14) NGV1914 01/18 Critical Care Unit Daily Review 15) NGV2431 08/21 Summary of Wound Care 16) NGV2441 04/22 Critical Care Nursing Transfer Form 17) NGV2444 03/23 Critical Care Eye Care Plan 18) NGV2485 01/22 Bowel Monitoring Care Plan 19) NGV2690 10/23 Critical Care Transfer Safety Checklist for Receiving Ward 20) Critical Care Water low Risk Assessment Score 21) NGV541 01/14 Trust Falls Assessment and Core Care Plan (Adult) 22) NGV1358 10/17 Trust Initial Pressure Ulcer Assessment (Adult)
|
|
Peri-Operative
|
1) WZQ552 03/21 Peri-operative Care Pathway 2) PC711 12/08 Trust core care plan colostomy/ileostomy 3) NGV1380 12/10 Trust Core Neurovascular Limb Assessment (Adult)
4) PC1384 01/18 Assessment to be carried out before elective surgery and/or endoscopy to identify patients with or at increased risk of OCJ or vCJD 5) NGV2431 08/21 Summary of Wound Care 6) F-105 Maintenance Check List Faecal Collection System
|
|
Medical Diseases
|
1) NGV285 03/03 Fit Chart 2) NGV312 02/16 Adult neurological observation chart incorporating pupillary response and limb movements 3) NGV889 11/04 EU Peak Flow Chart – Inpatient 4) NGV1424 03/23 Adult Insulin Prescription and Diabetes 5) NGV1598 05/18 Diabetes sugar monitoring chart for patients not on insulin 6) Glasgow Modified Alcohol Withdrawal Scale (GMAWS)
|
|
Procedure Lines
|
1) NGV1176 07/19 Trust Peripheral Venous Cannula (PVC) Care Plan (Adult) 2) NGV1586 03/18 Wound Care Plan 3) NGV1660 03/14 Trust Core Care Plan and Risk Assessment for Patients with Nasogastric Feeding Tube (Adult) 4) NGV1590a 07/17 Trust Core Care Plan Care of the Patient with an Indwelling Urinary Catheter (Adult) 5) NGV090 08/22 Adult Acute Pain Service Patient Controlled Analgesia 6) NGV1239 05/18 Trust Critical Care Arterial Cannula (AC) Care Plan 7) NGV1644 02/16 Trust Core Care Plan: Tracheostomy (Adult) 8) NGV1771 09/20 Adult Transfusion Prescription and Administration Record 9) NGV1798 10/20 Diabetic Ketoacidosis (DKA) Management for Adults 10) NGV1854 05/18 Intravenous Heparin Chart 11) Critical Care Therapies Treatment Record 12) Critical Care Continuous Renal Replacement Therapy Prescription Form & Chart for Citrate 13) MRI Patient Screening Questionnaire and Consent Form
|
|
Admissions
|
1) NGV1523 07/18 Trust Bedrail Assessment and Core Care Plan (Adult) 2) NGV1545 08/18 Trust Pain Assessment Tool and Core Care Plan for Patients with Learning Disabilities (Adults) and Patients who have Dementia or Cognitive Impairment 3) WZQ552 03/21 Peri-operative Care Pathway 4) NGV1349 08/17 Food Record Chart Nutrition and Diabetic Services 5) NGV2109 07/20 Critical Care Nursing Assessments and Care Plans 6) Critical Care Patient Property Form 7) Parental Nutrition: Initial Review Form 8) Trust Core Patient Activities of Daily Living - Initial Assessment 9) Trust Bedrail Assessment and Core Care Plan (Adult)
|
|
Death and dying
|
1) NGV093 01/21 Mortuary Card 2) NGV1274 05/20 Notification of death of a patient - checklist Retain on front of notes 3) NGV1715 06/17 Clinical Notes Achieving Individual Priorities of Care for the Dying Person and their family Doctor Review 4) NGV1717 06/19 Individualised care at the end of life - Care round record sheet (To be used in place of enhanced are round document) 5) NGV1718 03/18 Clinical Notes Individualised Care for the Dying Person and their family (Continued) 6) NGV1720 08/17 Individualised Plan of Care for the Dying Person and their Family Multidisciplinary Communication Sheet 7) NGV2245 04/20 Death Verification Report 8) Tissue Donation Referral Form – Email 9) H. M. Coroner - Referral Form 10) End of life care checklist
|
Table 10. Classification of observation forms used in diagnosis and treatment tasks by doctors and nurses into process groups.
2) Key Resources Knowledge Acquisition
We observed non-patient medical data, diagnostic devices, and observation forms used in diagnosis and treatment processes to analyse the business and workflow of the critical care unit in order to build the Physical Digital Twins Layer (PDTL). During this phase, alternatives such as web, mobile, and desktop apps were considered to interface physical twins with digital twins, but the study employed a hybrid approach which utilized barcode readers as IoT devices, paper sheets for taking manual entries, and a web-based interface to record the start and end times of tasks by the staff. The main reason for this approach was to provide alternative means for clinicians to interface with the digital twins without changing existing workflows. This phase, the study identified the computer, barcode reader, sessions, and unit as Physical Digital Twins (PDT) within the digital twins framework.
3) Integration of PDT and CDT
During this phase, we identified the session digital twins to store information about the recorded event. The Session CDT was designed to store property values such as Patient ID, Staff ID, Form ID, Start and End Timestamps, and an Is Session Valid Boolean flag. If the Is Session Valid flag is true, then the values in the property fields will be matched with existing twins in the CDTL. For example, if a new staff member initiates an action on a task for an admitted patient, the Session PDT is used to create new Staff CDT, Patient CDT, Task CDT, and Action CDT. The Task CDT and Action CDT are used to record the start and end timestamps. Every time they interact with the patient, a new Action CDT will be created under their particular Task CDT, recording their start and end timestamps. In the above example, if the staff member completes the action, they will set the Is Action Completed Boolean flag to true and update the end timestamp property fields. If the staff member completes a task, the Task CDT will have the Is Task Completed flag set to true, and the end timestamp property fields will be updated. When a staff member creates another action on the same Task CDT, a new Task CDT will be created, and ongoing actions will be displayed under the new Task CDT.
4) Design, Evaluation and Execution
Design
Digital Twins Definition Language (DTDL)
The Digital Twins Definition Language (DTDL) is used to describe the physical twin. Each physical twin is encapsulated in a DTDL model, which is a JSON file that describes the properties and relationships. These DTDL models are then used to create digital twin instances in both PDTL and CDTL. Properties are used to store the states and changes of a particular digital twin by using basic property types or complex property types. The study only used basic property types, as these do not store complex values such as patient treatment details.
Each DTDL model can then be used to establish relationships with other models. Due to limitations in the Azure Digital Twins platform, we used DTDL v2 to describe these instances and utilized the Azure SDK to perform create, read, update, and delete operations for digital twin instances and their relationships.
Physical Digital Twins Layer (PDTL)
We designed the Physical Digital Twins Layer (PDTL) and respective cohorts as Physical Digital Twin (PDT) in the framework based on means identified for gathering data. Due to time and scope limitations, only barcode readers were used in the study, referred to as IoT devices. The Unit PDT denoted by CCG Entity Code. We did not use the abbreviations which distinguishes other wards such as the Critical Care Unit (CCU) or Coronary Care Unit (CCU) for staff. Similar examples include Forrest Centre (FC) - Fracture Clinic (FC), Oncology Centre (OC) - Orthopaedics Children (OC), or single names such as Chiropody, Haematology, Pathology, etc. Additionally, the name length is limited to 1 KB and each name had to be unique. For that reason, the unit was named based on NHS guidelines as 78H rather than CCU or Critical Care Unit.
Based on scalability, each Unit PDT is subdivided into Desktop PTDs which are host computers used to gather data. Desktop PDTs were identified by Desktop-{name of the host computer}, which were used to determine the data origin location. In this case, study used a unique identifier for the PC or the name of the IoT client application.
The COM PDTs were added to PDTL to indicate which IoT devices are attached to each port. Rather than including this information as a property value inside the IoT device, it was added separately to identify whether the ports are enabled or disabled and to determine which COM ports are occupied by each wireless barcode reader. The IoT Device PDTs were named as CCU{device number}. This IoT Device PDT stored key data about the IoT device. Each IoT device is then attached to one of the COM ports, as illustrated in Fig. 4.
Session PDTs are temporary 30-second virtual sessions used to hold information from barcode readers. During the testing phase, we initially added timestamps with millisecond accuracy as S-{timestamp in milliseconds}. However, this approach was not sustainable in the real world, where events might occur in microseconds or nanoseconds apart. To create unique names for each digital twin, we decided to suffix a GUID as S-{GUID}. This solution addressed the uniqueness problem and avoided duplication issues even the data is ingested in nanoseconds apart. The main limitation of the barcode readers is their inability to process data within the device itself. Each telemetry event from the IoT Hub Client app contained a JSON object with the following structure.
The IoT Hub client app sends the event to the ADT Ingestion in IoT Hub Event Grid Trigger Function App (uod-nhs-rns-rns01-78h-iot-hub-egt-fa/adt-ingestion) to create new sessions and update or replace values for existing valid sessions. The Session PDTs are used to store identifiers for patients, forms, or staff. These Session PDTs help to virtually store and queue relevant information and will be set expired if the properties within them are incomplete or expired. Each Session PDT stored and validated properties such as patient identifier, staff identifier, form identifier, start time, and end time. Once the Session PDT is valid, the property data is mapped to their conceptual twins, the Session PDT set expired, and a snapshot of this instance is stored in the SQL database for validation.
Conceptual Digital Twins Layer (CDTL)
The Conceptual Digital Twins Layer (CDTL) defines Conceptual Digital Twin (CDT) which is micro-ergonomic data such as rules, roles, processes, and standards twins of the Critical Care Unit (CCU). The data originates from the PDTL, and each snapshot is stored upon completion in a SQL database. The CDTL is interfaced with stakeholders, enabling interaction and generating reports through a web-based graphical user interface. As shown in Fig. 5, the CDTL includes CDTs such as patient, form, task, activity, staff, and unit.
Next, demand is created by patients when they are admitted to the unit for diagnosis and treatment. The staff, on the other hand, are equipped with process maps to follow for each patient based on specific criteria. The staff use different types of observation forms to record these diagnosis and treatment procedures for the patient. Subsequently, we were able to generate the framework for the CDTL by creating CDTs for these conceptual elements and mapping them based on the level of interaction using relationships.
In this study, we did not store any patient-specific information or values from personal records. To denote the Patient CDT in the framework an increment value was suffixed to the Patient PDT ID as P-{increment number}, ensuring that each twin ID is unique in the CDTL. This patient ID value is derived from the Session PDT's Patient ID property.
Then, the Form CDT was added to the CDTL to understand the frequency of each observation form type. The Form CDT helps define the type of treatment or diagnosis the Patient CDT is undergoing and assess the bed acuity level. The Form CDT is named with incremental values, such as F-{increment value}, which is an integer. Instead of using the full name of a form, such as "NGV1717 06/19 Individualised Care at the End of Life - Care Round Record Sheet (To be Used in Place of Enhanced Care Round Document)" we shortened it to the form ID F-50. This approach helped reduce errors and cleaned up the knowledge graph representation of the conceptual digital twins. These forms do not contain any patient-related data and are purely used to identify which form is used by the staff.
The Task CDT is an instance of the Form CDT. In the real-world setting, each observation form is used by several staff members over a particular period. For example, the NGV1914 01/18 Critical Care Unit Daily Review observation form is used by clinicians and nurses to record observations such as heart rate or blood pressure and treatments such as medications prescribed for a patient. This form is allocated every 24 hours and is replaced with a new form at the end of the day. In the CDTL, this is considered a Task CDT. If a patient stays for 3 days, it means there are 3 Task CDTs. Each Task CDT is then attached to a Patient CDT and Form CDT recording the start and end times. This setup helps calculate bed acuity levels, costs per patient, the number of times a form has been used, and the average task completion time. The CDTL only allows one Task CDT for one Form CDT at any given instance, which helps identify work duplication and track ongoing tasks. The Task CDT was mapped using the Session PDT’s Patient ID, Form ID, and start/end timestamp properties. Each Task CDT included an "Is Task Completed" property which was used by staff to check if the task is completed or not. This resembled the process of changing observation forms in the physical setting. If there are no ongoing tasks, a new Task CDT will be created in CDTL.
Further, the Action CDT is used to record individual sessions within a Task CDT. For example, the NGV1914 01/18 Critical Care Unit Daily Review form involves multiple interactions with doctors and nurses over its 24-hour period. These individual interactions are mapped to specific Action CDTs. Each Action CDT includes properties such as Is Action Completed, Start Timestamp, End Timestamp, Staff ID, and Task ID. When a staff member begins a treatment procedure, they first record the timestamp at the start of the procedure. They then record the second timestamp at the end of the procedure, which notifies the CDTL that the Action CDT has been completed. The CDTL enforces a rule that only one ongoing action is allowed for a specific task at a time by a staff member. Initially, a new Action CDT is created with both the start and end timestamps set to the same value. Once the action is completed, the end timestamp is updated, and the Is Action Completed property is set to true. This approach helps map individual staff interactions with a given task, calculate the time a staff member spends on an action, assess whether a particular staff member is busy, track the timeline of interactions with a patient, and evaluate the costs and efficiency of the treatment process for each patient at a more granular level. The Action CDT does not contain any patient-related data and is purely used to record timestamps.
Next, the Staff CDT was used to identify staff members in the CDTL. The Staff CDT does not hold any personal data such as names, ages, or other personal details. Due to scope and time limitations, the study did not store user roles either. Each Staff CDT was named using the format S-{increment value}. The Staff CDT will be created if it does not already exist, and it will then be mapped to the relevant Action CDT based on the Task Id property of the Session PDT.
Finally, the Unit CDT was used to map each staff member to their workstation. Currently, the CDTL mapping is used to map staff who work in the Critical Care Unit, specifically unit 78H. However, with scalability in mind future staff from cross-departmental interactions—such as scanning X-rays or blood checking—will be mapped based on available data to build a real-time, sophisticated knowledge graph representation of the hospital.
Execution
Software Infrastructure
As shown in Fig. 6, the IoT hub client application provided the interface to manage IoT devices. It established connectivity to the Azure cloud by dynamically generating symmetric keys for each IoT device using an HTTP endpoint. This endpoint was protected by Microsoft Defender for Cloud to identify malicious activities and Microsoft Entra to secure accessibility to endpoints and scopes. The app then retrieved symmetric keys to establish connectivity to the IoT hub Device Provisioning Service (DPS) dynamically based on the availability of devices.
The cloud based digital twins interfaced with the humans using IoT devices and through a web interface. The dynamic nature of allocating cloud resources required flexibility, we used Azure Service Managers to allocate and generate security keys to establish connectivity between the aforementioned services in real-time. By using Function Apps and Event Grids, we captured the event data of IoT Hub and Digital Twins in SQL databases. The web interface provided users with accessibility to interact with these Digital Twins. A set of temporary emails were created using Entra to grant users access to the system.
When staff scanned values using a barcode reader, the IoT Hub client created a telemetry event containing a JSON payload with information about the PC, IoT device, value, and timestamp. Each telemetry event was then filtered by the IoT hub Event Grid to trigger functions that to store this event data or ingested it into the PDTL based on their characteristics. Then a series of function apps were designed to capture these digital twins update events, on PDTL Event Grid triggers to modify the CDTL accordingly.
The web-based dashboard provided an authenticated user interface for interacting with the Conceptual Twins, allowing users to generate reports such as identifying bed acuity, ongoing tasks and activities, costs by each form, costs by each patient, time taken by each form and staff member, and time spent on each patient. The study was limited in scope and did not build services such as notifying staff of ongoing activities or missing activities based on process maps. However, these potential expansions such as Time Triggers were identified and mentioned in the architecture for the future development.
Hardware Infrastructure
Due to computer privacy and security reasons, study did not use any computers connected to the existing NHS network or its private infrastructure. Instead, they used a custom-built PC to deploy the IoT hub client application and connect the IoT devices. This approach provided a greater control over their infrastructure and saved time by avoiding the need to obtain approval from the NHS to run a custom program on one of their.
In the study, we used barcode readers (n = 3), specifically Tera 51000 Laser 1D (n = 2) and Tera D5100 2D (n = 1) wireless barcode scanners. Initially, the plan was to provide a scanner for each patient, but the constraints limited the number due to the coverage limitations of the barcode readers. The main wall dividing the east ward and west ward posed a significant barrier to establish connectivity between patients in farther sections with the IoT hub client application. Additionally, the glass walls separating each bed caused signal disruptions between the IoT client application and the IoT devices.
Figure 5 shows the data points collected during the production phase, which helped create the coverage map displayed above. The map is not according to any scale but used in production to identify availability. Due to these challenges, the use of IoT devices was restricted to beds 6, 7, 8, and E, with bed D being vacant during the data collection period. Consequently, the study had to place a hybrid method that combined both offline and online approaches to collect data, utilizing paper forms and computers.
Evaluation
The consent forms were collected from the participants doctors (n = 15) and nurses (n = 5) at the Critical Care Unit of Northampton General Hospital NHS Trust. These consent forms were generic, not specific to reference what type of information gathered or type of task they performed during the study. Each patient and staff were identified by using custom numbers during the data collection, which was only used by the staff to track the tasks performed for each patient. Any staff and patient specific data were not collected during the study.
Offline
The offline method was deployed to overcome network issues caused by barriers between patients and the IoT hub client application. This method, staff member could use either IoT devices or simply write on the paper the start and end times. Later on, the data points written on the form were added to the digital twins framework using the online method.
Online
First, temporary emails were provided to each staff member to access the system through the web interface. Each barcode was assigned to a patient to allow staff to gather start and end times efficiently. This system helped track patients when they were moved to other beds based on the severity of their condition. The online method was primarily limited to those who already had access to computers. The online interface featured three user roles: managers, administrators, and staff. The Fig. 8 given below shows the web-based dashboard designed for staff.
Moreover, based on the data collected in the digital twins, unit managers could generate reports such as average time and costs related to each patient, bed acuity levels at a given time, and the costs generated by forms. Administrators could manage staff member access, create new users, oversee overall resource usage, allocate IoT devices to patients, and manage resources. The staff interface allows users to create, read, and update digital twins, allocate resources, monitor bed acuity levels, track ongoing tasks and actions for respective staff members, mark tasks or actions as complete, and create new actions based on forms.
Dataset
The dataset was extracted using the Digital Twins Query Language from Digital Twins Instances. Each event did not contain any data related to patients or staff, but rather workflows at the CCU. This data included the start and end timestamps of actions, observation form types, and the digital twins' names for staff and patients. We cleaned the data in the digital twins instances into generalized records, showing the number of minutes spent on each task, categorized by process groups. The dataset is not publicly accessible and is attached as a supplementary file for review purposes.