B4: Personalised digital twins

A digital twin combines three components. A structural model specifies the architecture — what is connected to what, anatomically or physiologically. A state representation holds the current values of the relevant parameters. A dynamics model specifies how state evolves over time and in response to interventions.

For a cardiovascular twin, the structural model might be a finite-element mesh of the patient's heart with geometry segmented from cardiac MRI; the state representation includes chamber volumes, wall thicknesses, electrical activation timing, and tissue stiffness parameters; the dynamics model is a coupled electromechanical simulator solving the equations of cardiac excitation and contraction. The Living Heart Project (Dassault Systèmes) is a mature example of this class.

Parameterisation — fitting the model to a specific individual — pulls from multiple data sources: imaging provides anatomical structure, wearable and implanted sensors provide continuous functional measurements, lab values provide biochemical state, and genomics provides response-affecting variants. The fitting itself is an inverse problem: find the parameter values that make the model reproduce the patient's observed behaviour.

This inverse problem is computationally hard and statistically subtle. Bayesian inference is the principled approach — it produces not just point estimates but full posterior distributions over parameters, capturing how uncertain each parameter is. But Bayesian inference over a complex simulator is expensive (each evaluation requires running the full simulation). Surrogate models (fast approximations of the simulator, often neural networks trained on simulation outputs) accelerate this. Simulation-based inference and amortised inference techniques are emerging to make per-patient parameterisation fast enough for clinical use. The parameterisation problem is, in many cases, harder than building the model in the first place.

This is one of the most technically challenging integration problems in the digital twin field, and it gates the path from today's narrow twins to the whole-patient twins AIHS would ideally use.

Organ-level twins typically have well-defined inputs and outputs at the boundaries where they interface with other body systems. A heart twin takes venous return as input and produces arterial output; a kidney twin takes arterial blood composition as input and produces filtered blood plus urine as output. Coupling two twins means making one's outputs serve as the other's inputs, consistently and in both directions.

Three things make this hard:

Boundary condition reconciliation. The heart twin's output blood flow becomes the renal twin's input; the renal twin's effect on blood volume and composition feeds back to the cardiovascular twin's load. These couplings form feedback loops that must reach consistent steady states, and the numerical methods for solving coupled multi-physics systems are delicate — small inconsistencies at boundaries can amplify into nonphysical oscillations.

Timescale mismatch. Cardiac electrical events occur in milliseconds; renal filtration adjusts over minutes to hours; tissue remodelling occurs over weeks. Coupling models that operate on timescales separated by six or more orders of magnitude requires sophisticated multi-rate integration schemes.

Parameter explosion and identifiability. Each coupling introduces additional parameters and additional ways for the combined system to become statistically unidentifiable — multiple parameter combinations producing indistinguishable observable behaviour, so the data cannot pin down the true values.

Phase II progress will likely produce two-organ and three-organ integrated twins for common disease categories (cardiorenal, hepato-cardiac). Whole-patient integration with all organs at twin-quality fidelity is a Phase III-IV target and may never fully arrive. The realistic clinical use case is multi-organ twins scoped to specific disease contexts rather than universal whole-patient simulation.

Validation is arguably the hardest part of the digital twin enterprise, because the whole point of a twin is to predict things that have not yet happened. Three validation regimes are used, none sufficient alone.

Retrospective validation. The twin is parameterised from data available at decision point T0, asked to predict the outcome at a later time T1, and its prediction is compared to the actual T1 outcome. This validates predictive accuracy but only tests the trajectories the patient actually followed — it does not test the counterfactual "what if we had intervened differently."

Prospective interventional validation. The twin predicts the patient's response to an intervention that is then actually performed, and the prediction is compared to the observed outcome. This validates interventional accuracy — the property AIHS actually needs — but is ethically and practically constrained: you can only validate against interventions that were going to be performed anyway.

Twin-twin / held-out validation. A portion of the patient's data parameterises the twin, and the twin's predictions on the held-out remainder are compared to the held-out data. This is the standard machine-learning validation pattern adapted to twins, useful for catching gross parameterisation errors but weak on interventional accuracy.

None of these is sufficient on its own. AIHS-grade twin use will require all three, plus ongoing monitoring of twin accuracy across deployment (continuously comparing twin predictions to observed outcomes and flagging drift). The deepest validation problem is that the interventional accuracy AIHS most needs is exactly the property hardest to validate, because validating it requires performing the interventions whose outcomes you wanted the twin to predict in advance.

The regulatory framework for validating intervention-recommending digital twins is still being developed; this is part of why C6 safety architecture investment matters so much, and why B4's clinical deployment is gated not just by modelling capability but by the maturity of validation methodology. The dependency on B3 is also fundamental: a twin you can usefully intervene on requires a model that supports counterfactual reasoning, which is precisely what B3 is about.