Digital Twins in Healthcare: What They Are and Where They Actually Work

A hospital bed-tracking dashboard is not a digital twin. Neither is a CAD file of a pacemaker. Neither is a 3D-printed model of a patient's heart sitting on a surgeon's desk. All three look like what vendors market as "digital twins in healthcare." None of them qualify, because none of them update.

Healthcare marketing uses the term loosely. It is worth being precise about what actually qualifies. A digital twin is a model that stays connected to the real thing. New sensor readings, new scans, new operational data keep flowing in, and the model changes with them. That live connection is the entire point. It is also why healthcare has been slower than manufacturing to adopt the technology. Healthcare runs on static records and point-in-time scans. Manufacturing was built on live sensor feeds from the start.

This guide covers three things. What a healthcare digital twin actually is. Where the technology already runs in production. What the FDA now expects from device makers who use computational models. It also covers where the boldest claims, a full digital twin of one patient, are still research, not something you can buy.

What counts as a digital twin, and what does not

A digital twin has three parts. A physical asset: a bed, a heart, an infusion pump. A digital model of that asset. And the piece that actually makes it a twin, not just a model: a live data connection that keeps updating the model as the physical asset changes state.

Take away that live connection and you have something else. A one-time 3D reconstruction from a CT scan is useful for surgical rehearsal. But it is a static simulation unless the model keeps ingesting new imaging or physiological data. A real-time bed-occupancy dashboard that just displays sensor readings is a monitoring tool, not a twin, because it holds no model of the underlying process. An electronic health record is a historical store of what happened to a patient. None of these three are twins on their own. A twin might use all three as inputs.

According to Grand View Research, the global healthcare digital twins market is projected to reach $3.55 billion by 2030. That is a compound annual growth rate of 25.9% from 2025. The growth is real. But it sits in a narrower set of use cases than the marketing language suggests. Three categories account for nearly all production deployments today. Operational twins of hospital environments. Patient-specific twins for surgical planning. Computational twins used in medical device development.

Why healthcare digital twins lag manufacturing by a decade

Digital twins started in manufacturing and aerospace. NASA and companies like GE and Siemens used them to model jet engines and industrial equipment, years before "digital twin" became a healthcare buzzword. Manufacturing had three advantages healthcare still lacks.

First, manufacturing equipment is instrumented by design. A jet engine ships with sensors built in. A hospital was not built that way. Retrofitting real-time sensing into an existing building, its beds, its equipment, its staff workflows, is a harder integration job than reading data off a machine designed to report on itself.

Second, manufacturing data carries none of healthcare's regulatory weight. A twin of a turbine does not need HIPAA-grade access controls, informed consent, or a validated audit trail. A twin that touches patient data needs all three. Each one adds engineering time before the first useful output.

Third, and most important: a jet engine's physics are far better understood than human physiology. Engineers can model how metal fatigues under stress with high confidence. Modeling how one patient's heart will respond to a specific surgery is a harder problem. There is more biological variability, and less certainty. That gap is why the most advanced clinical digital twins today stay narrow: one organ, one procedure. None try to model a whole patient.

None of this means healthcare digital twins are a bad idea. It means the categories that work today are the ones where the physics is tractable and the data already flows: hospital operations and single organs. Not a full model of a person.

The twin that is already running: hospital operations

The most mature healthcare digital twin has run since 2016, without ever being marketed under that name. The Judy Reitz Capacity Command Center at Johns Hopkins Hospital was built with GE Healthcare Partners. It tracks the occupancy of every bed, in every department, in real time. It uses predictive modeling to flag when the next ICU bed or operating room will open.

This is an operational digital twin in every sense that matters. It has a physical system: the hospital's beds, units, and patient flow. It has a live model of that system's current state. And it has continuous data feeding the model as patients are admitted, transferred, and discharged.

The results show up in a hard number. Since it opened, the center has produced a 46% improvement in Johns Hopkins' ability to accept transfer patients with complex medical conditions from other hospitals. That gain came from knowing bed availability in real time, instead of by phone call and spreadsheet.

Why does this category work when patient-level twins are still early? Bed occupancy, staffing levels, and patient flow are a problem manufacturing already solved. They are physical assets with a limited number of states. They connect to sensors that already exist: admission and discharge systems, nurse call data, scheduling software. None of that requires a model of human biology. Operational twins are, in effect, IoT-connected systems wearing a healthcare label. The architecture looks the same whether the tracked assets are hospital beds or factory equipment.

The FDA now has a formal rulebook for computational models

Medical device makers have used computational models for years. They test how a device behaves before building a physical prototype. What changed on November 16, 2023: the FDA gave that practice a formal regulatory path.

The FDA's Center for Devices and Radiological Health published final guidance on this exact question. The document is titled "Assessing the Credibility of Computational Modeling and Simulation in Medical Device Submissions." It sets out a risk-informed framework. The framework tells a manufacturer how much evidence they need before the agency will accept a computational model. That model, in effect a device-specific digital twin, can then stand as part of a regulatory submission, instead of or alongside physical testing.

Two details matter here. The guidance applies to physics-based, mechanistic models, the kind used to simulate how a stent deforms or a pacemaker's electrical signal spreads. It does not apply to statistical or machine-learning models. Those fall under separate AI-specific FDA pathways. And the framework is risk-based: a model backing a low-risk claim needs less evidence than one backing a claim that touches patient safety directly.

For device makers, this is a real shift. The credibility evidence a submission needs, verification, validation, and applicability checks, has to be planned into the model from day one. Retrofitting that evidence onto a model built without the FDA framework in mind costs more. The agency's own guidance says so directly.

Surgical planning: real today, whole-patient models are still research

The clearest patient-specific digital twin already in clinical use is cardiac surgical planning. Most of that work runs through Dassault Systemes' Living Heart Project, launched in 2014. It brought together heart researchers, device makers, regulators, and working cardiologists.

At Boston Children's Hospital, Dr. David Hoganson leads that work. He directs the hospital's Computational 3D Visualization Program. His team builds virtual twins of individual patients' hearts from imaging data. Surgeons use the models to rehearse complex heart procedures before the real operation. They rotate the model. They test a proposed repair's effect on blood flow and valve pressure. They adjust the surgical plan before making the first incision. The hospital has used this approach for years, on hundreds of patients.

That is a real, working patient-specific twin. It stays narrow in scope: one organ, one procedure. It is built from a specific patient's imaging data. And it directly changes clinical decisions. It also makes a useful contrast to where the field is still early.

In September 2025, Siemens Healthineers and Mayo Clinic announced an expanded collaboration. The goal: AI-enhanced digital twins for cardiovascular care that simulate patient-specific responses and flag likely complications, using imaging and health record data. The partnership also covers redesigned surgical care pathways, plus similar modeling work for prostate cancer and complex neurological disease. It is worth watching, and worth being honest about. It is a recently announced collaboration building toward a capability. It is not yet a deployed clinical tool with published outcomes, the way the Living Heart Project's cardiac models are. That is the real gap: an organ model that has already guided hundreds of real surgeries, versus a twin two research institutions just started building together. One is proven. The other is still promising.

How to evaluate a digital twin project for your organization

Say you run a hospital, make a device, or run a health tech company. If you are weighing whether a digital twin makes sense, start by sorting the idea into one of three categories. Each one requires a different engineering approach.

An operational twin (bed tracking, equipment monitoring, staff and patient flow) is the most workable starting point for most organizations. Its architecture is close to an industrial IoT monitoring system: sensor ingestion, a state model, a dashboard, alerting. Scope it by asking three questions. Which assets get instrumented first? What data already exists in your admission and scheduling systems? What decision does the model need to support, bed assignment, staffing, or transfer acceptance?

A device or biomechanical twin (modeling how a device or organ behaves) needs deep expertise in the relevant physics. If the goal is a regulatory submission, it also needs familiarity with the FDA's credibility framework from day one. This is not a general software build. It is closer to a research partnership than an off-the-shelf purchase.

A patient-specific predictive twin (a model of one patient's overall physiology, updated continuously) is the category to be most skeptical of right now. The clinical examples that work, like cardiac surgical planning, stay narrow and procedure-specific. A vendor selling a general "digital twin of your patient," one that predicts across conditions, is selling ahead of the science.

The organizations getting real value from healthcare digital twins today are not chasing the boldest version of the concept. They picked a category matched to one operational or clinical problem. They built the live data connection first. They let the model's scope grow from there.

Where RaftLabs fits

RaftLabs builds digital twin systems. We connect IoT sensor data, operational data, and asset models into a real-time picture a team can act on. That builds on our wider healthcare software development work across the healthcare industry, all of it HIPAA-compliant and tied into live clinical systems.

Our digital twin work sits in the operational category above. Real-time monitoring. Predictive alerts. Integration with existing hospital or facility systems. It does not extend to patient-specific biomechanical modeling. That is a different discipline, and it usually belongs with a research or academic medical center partner.

Trying to figure out whether an operational digital twin is the right next step, for your hospital, clinic network, or device line? Start with a scoping session, not a sales pitch. What assets would you track, what data already exists, and what decision does the model need to improve? Those three questions are where a realistic project starts.