Design for a Digital Twin in Clinical Patient Care

TL;DR

The paper tackles the challenge of creating clinically usable Digital Twins (DTs) that integrate multi-modal patient data along the care journey. It proposes a general RDF-backed design using a bipartite knowledge graph and a data backbone with a Digital Cohort and evolving patient state, coupled with fusion models to aggregate conflicting signals. The DT is characterized by five features—Modular, Informed, Predictive, Evolving, and Explainable/Interpretable—to support scalable, transparent decision support while preserving patient privacy through local model training. The work outlines a practical pathway toward validation, regulatory compliance, and clinician trust, and discusses opportunities across multiple clinical domains, aiming to translate DTs from concept to clinical practice.

Abstract

Digital Twins hold great potential to personalize clinical patient care, provided the concept is translated to meet specific requirements dictated by established clinical workflows. We present a generalizable Digital Twin design combining knowledge graphs and ensemble learning to reflect the entire patient's clinical journey and assist clinicians in their decision-making. Such Digital Twins can be predictive, modular, evolving, informed, interpretable and explainable with applications ranging from oncology to epidemiology.

Figures (4)

• Figure 1: Visualisation of the general design of a DT for clinical patient care generating an interface between the real world (orange; including the patient and the clinician) and the digital world (blue; including the Digital Cohort - Data Cohort and the DT - patient-specific information and algorithmic structure). Multi-modal data gets transferred from the real patient to the DT, which presents its decision support to the clinician for a medical decision.
• Figure 2: Schematic overview of our proposed software solution for patient-centered DTs in Medicine. It consists of 3 different containers, which are labeled A-C. Those represent the different interacting building blocks, where A is the existing clinical data systems feeding into B, the DT itself, explicitly the data backbone (B$_1$). The Resource Description Framework (B$_2$) stores all available information about models and their links with attributes, which the back-end builder (B$_3$) uses to construct a knowledge graph upon which the operational mode (B$_4$) is going to perform predictions. The user interacts over C the front-end, where block C$_1$ represents the inputs and C$_2$ the corresponding outputs from executing the function run (within B$_4$). More detailed information about the design is given in the text.
• Figure 3: Local structure of the knowledge graph. Outputs from two different models (green and red) are passed on to the fusion model of an internal attribute (circle). Which then gets forwarded to downstream models. The signature propagation from upstream to downstream models is illustrated by colored signatures on the provenance chain. Labels indicate subroutines from the network algorithm described in Figure \ref{['fig:MainLoop']}.
• Figure 4: Flowchart illustration of the main network propagation and aggregation scheme in the operational mode. Behaviour differs between base models (left) and fusion models (right). The fusion models only propagate if their respective attribute is set externally or the provenance chain $\mathscr{P}$ does not already contain its own signature. Loops can run locally and independently of each other.