Digital Twins in Healthcare: Data Needs and Where It Lives
A digital twin in healthcare is a computational model of a specific patient, organ, population or care process that is kept up to date with data from its real-world counterpart and used to predict what will happen under different decisions. To work, it needs longitudinal clinical records, imaging, omics, device and outcome data, and that data should stay where it is governed: inside the hospitals, biobanks and national programs that hold it, with models brought to the data rather than the data copied to the model.
Why digital twins matter now
The term has moved from engineering into health policy quickly. The US National Academies of Sciences, Engineering, and Medicine published a consensus report on digital twins that stresses one defining feature: a two-way connection, where data from the physical system updates the virtual model and the model’s outputs inform decisions about the physical system. A static risk score is not a twin. A model that is recalibrated as a patient’s new lab results arrive, and then used to compare treatment options, starts to be one.
Europe is investing in shared foundations. The EDITH coordination action, funded under Horizon Europe, has been building a roadmap toward a European Virtual Human Twin, an ecosystem of interoperable models and data resources. Regulators are also more comfortable with computational evidence. The FDA’s guidance on assessing the credibility of computational modeling and simulation in medical device submissions, together with the ASME V&V 40 standard, gives developers a framework for showing that a model is fit for a specific context of use.
At the same time, the European Health Data Space (EHDS) Regulation and national data laws are tightening the rules on where health data may be processed and by whom. Digital twins are data hungry by design, so the question of where their data lives is now a strategic one, not a technical footnote.
What data a healthcare digital twin needs
The data requirements depend on what is being twinned, but most health twins draw on the same families of data.
Longitudinal clinical records
Diagnoses, medications, procedures, vital signs and lab results over time give the model its baseline and its trajectory. Without longitudinal depth, a twin cannot learn how a person changes, only what they look like on one day.
Imaging and physiological signals
Organ twins, such as cardiac models used to simulate electrical activity or blood flow, are usually built from patient-specific imaging. Continuous signals from ECGs, intensive care monitors and wearables provide the updates that keep the twin current.
Omics and biomarkers
Genomic, proteomic and metabolomic data explain why two patients with the same diagnosis respond differently. They also make twins far more identifying, since a genome is unique to an individual.
Outcomes and interventions
To predict the effect of a decision, a twin must be trained on what happened after similar decisions in the past. That means linked outcome data, often from registries, claims or follow-up studies.
Almost none of this arrives in a common format. Records come from different electronic health record systems, coding systems and time zones. That is why data harmonization into standards such as the OMOP Common Data Model (CDM) and HL7 FHIR is a prerequisite rather than a nice-to-have.
Where digital twin data should live: the Sovereign AI view
The default instinct is to pool everything into one large repository and train there. For digital twins, that instinct runs into three problems. The data is among the most sensitive a health system holds. It is spread across many custodians who are legally responsible for it. And twins need continuous updates, which means a central copy is always slightly out of date and constantly being refreshed through new transfers.
Sovereign AI offers a different answer. A health system, ministry or biobank keeps control of both its data and the models trained on it, and computation runs inside infrastructure it governs. In a federated Trusted Research Environment (TRE), approved code is sent to each data custodian, runs against locally harmonized data, and returns only reviewed results or model parameters. Because data never leaves the source, custodians keep control, yet a model can still learn from many sources at once.
This fits the two-way nature of a twin well. Because the model sits next to live data rather than a snapshot, it can be updated as new records arrive, and its outputs can be checked before anything leaves the custodian’s boundary. Our comparison of federated analytics and federated learning explains the two main techniques used to build models this way.
A framework for placing digital twin workloads
Not every twin needs the same architecture. The table below maps common twin types to their data needs and the placement that usually makes sense.
| Twin type | Typical data | Main risk | Recommended placement |
|---|---|---|---|
| Organ twin (for example cardiac or liver) | Patient imaging, physiological signals, labs | Highly identifiable imaging and signals | Built and run inside the treating institution or a federated TRE node |
| Patient twin | Longitudinal records, omics, medications, outcomes | Re-identification from combined data types | Federated training across custodians, inference at the point of care |
| Population twin | Registry, claims and cohort data across regions | Cross-border transfer and residency rules | Federated analysis across national or regional nodes |
| Process or hospital twin | Bed occupancy, staffing, scheduling, flow data | Lower clinical sensitivity but commercial and operational confidentiality | Hospital-controlled environment, aggregate sharing only |
| In silico trial cohort | Trial data, real-world data, mechanistic models | Validation and bias in the virtual population | Federated TRE with documented provenance and credibility evidence |
A useful rule: the more individual and identifying the twin, the closer its computation should sit to the source. Population and process twins can often work with aggregate outputs. Patient and organ twins almost always require access to record-level data, which is exactly the data that should not be copied.
What this looks like in practice
National genomics and biobank programs already hold the combination of data that patient twins need: genomes, longitudinal health records, imaging and outcomes, all under strict governance. Programs such as Genomics England and the Canadian Partnership for Tomorrow’s Health (CanPath) use federated TRE infrastructure so that approved researchers analyze sensitive data without extracting it. The same architecture that supports cohort discovery and genomic association studies today is the natural home for the models that will become patient and population twins, because the data, the governance and the output controls are already in place.
For pharma, the near-term use is in silico cohorts: virtual patient populations used to explore trial designs or to supplement control arms. These models are only as credible as the real-world data behind them, and sponsors increasingly need that data from several countries at once. Federated access lets a sponsor train or calibrate such models across jurisdictions while each dataset stays under its local rules.
Common pitfalls and objections
Calling a dashboard a twin
Many products labeled digital twins are visualizations or one-off predictive models. Without a feedback loop and ongoing updates, they carry the marketing risk of the label without its benefits. Be precise about what the model does.
Validating once and never again
A twin that updates continuously can drift. Credibility frameworks such as ASME V&V 40 are applied to a context of use, so a change in population, data source or purpose calls for fresh evidence. Build monitoring into the design.
Assuming synthetic data solves privacy
Twins can generate synthetic patients, and synthetic data has real uses. But a model trained closely on individuals can reproduce their characteristics. Synthetic outputs still need disclosure review before release, as our synthetic health data guide explains.
“Federation is too slow for real-time twins”
Training across sites takes coordination, but inference for an individual patient happens locally, next to that patient’s data. Federation governs how the model learns, not how quickly it answers at the bedside.
Treating model parameters as harmless
The weights of a model trained on patient-level data are themselves a derived output. Overfitted models can leak information about the individuals they were trained on through membership inference or reconstruction attacks. Treat twin parameters leaving a custodian with the same care as any other export: check them, log them, and apply privacy techniques such as differential privacy where the risk justifies the accuracy cost.
Ignoring bias in the source data
A twin inherits the gaps of its training data. If one region or population is missing, the twin will be least accurate for the people it has seen least. Federated access to more diverse cohorts is one of the few practical ways to close that gap without centralizing data.
What to do next
Start by defining the twin’s context of use in one sentence: which decision it supports, for whom, and how often it must update. Then inventory the data that decision needs and where each piece is held. Map the legal basis and residency constraints for each source. Harmonize to shared standards before modeling begins, and decide early how outputs will be reviewed before they leave any custodian. If the data is spread across institutions or borders, design for federation from day one rather than retrofitting it after a central copy has already created risk.
Frequently asked questions
What is a digital twin in healthcare?
A digital twin in healthcare is a computational model of a specific patient, organ, population or process that is updated with data from its real-world counterpart and used to predict outcomes under different decisions. The two-way link between the model and the real system is what separates a twin from a static predictive model.
What data does a patient digital twin need?
Most patient twins need longitudinal clinical records, imaging or physiological signals, omics and biomarker data, and linked outcomes and interventions. The data must be harmonized into common standards such as OMOP or FHIR before it can be modeled consistently.
Should digital twin data be centralized?
Usually not. Twin data is highly identifying, held by many custodians, and needs frequent updates. A federated approach keeps data at each source and sends models to it, which reduces transfer risk and keeps the model close to current data.
How does Sovereign AI relate to digital twins?
Sovereign AI means a health system or nation keeps control of its data and the models trained on it. For digital twins, that means twins are trained and run inside infrastructure the data custodian governs, rather than on external platforms that hold copies of the data.
Are digital twins accepted by regulators?
Regulators increasingly accept computational evidence when its credibility is demonstrated. The FDA’s guidance on computational modeling in device submissions and the ASME V&V 40 standard give developers a structured way to show a model is fit for a defined context of use.
What is the difference between a digital twin and synthetic data?
A digital twin models a specific real entity and stays linked to it over time. Synthetic data is artificial data generated to resemble a real dataset. A twin can produce synthetic data, but synthetic outputs still need disclosure review because they can reflect real individuals.