How healthcare facilities actually adopt digital twins

If you manage a healthcare campus, you’ve probably heard the pitch. Digital twins will transform your operations. They’ll predict failures before they happen. They’ll give you a real-time command center for your entire portfolio.

Some of that is true. But the pitch usually skips over the part that actually matters: what it takes to get there.

We’ve covered the broader concept of digital twins in previous articles, including why they fail, how to keep them accurate over time, and a maturity model for getting started. I won’t rehash all of that here.

In this article, I want to discuss some of the nuances of digital twins in a healthcare context, explain why the boring stuff (namely asset inventory and naming conventions) are critical first steps, explain how to build a business case for your facility, and give you some tangible ways to get started.

Why healthcare facilities are different

Hospital campuses have characteristics that make digital twins both harder to implement, and more valuable once they’re working.

The regulatory environment is the obvious one. Joint Commission surveys require you to demonstrate that you know where your life-safety systems are, that they’re maintained, and that your documentation is current.

Most facilities teams I talk to spend weeks preparing for these surveys, pulling records from multiple systems and spreadsheets. A well-structured digital twin collapses that prep time significantly, because the documentation lives with the asset rather than in a filing cabinet somewhere.

Then there’s the complexity of the systems themselves. A hospital campus might have dozens of air handling units serving different zones with different requirements. You’ve got medical gas systems, emergency power, infection control considerations that affect HVAC decisions. The number of assets that need tracking (and the interdependencies between them) are much higher than a typical commercial building.

The stakes are also different. When a chiller goes down in an office building, people get uncomfortable. When it goes down in a hospital, you’re potentially moving patients. That changes the calculus on how much you’re willing to invest in predictive capabilities and redundancy planning.

And then there’s the workforce reality. Experienced facilities staff are retiring. And they’re taking decades of institutional knowledge with them. The person who knew a particular valve was replaced in 2014 and tends to stick in cold weather? That kind of information disappears when they leave.

A digital twin can’t replace a person’s judgment, but it can capture and preserve the documented history of every asset so the next person isn’t starting from scratch.

Start with what you have: the CMMS

Most digital twin pitches skip over the part that actually matters: what it takes to get there.

The healthcare organizations I’ve seen get tangible value from their digital twins didn’t typically start with a platform purchase or campus-wide laser scan. Instead they started with their data. Specifically, they started with the asset inventory and naming conventions inside their CMMS.

You almost certainly already have a CMMS. Some are well-maintained. But many are not.

Asset inventories are incomplete. Naming conventions are inconsistent, sometimes across buildings, sometimes within the same building. Room numbering doesn’t match what’s on the architectural drawings, which doesn’t match what’s in the BAS, which doesn’t match what the clinical staff actually call the spaces.

Before you buy a platform, before you scan anything, you need to get your asset inventory into shape and establish naming conventions that will hold across systems. That means: deciding on a nomenclature standard for your assets and spaces. Reconciling your CMMS inventory against what’s physically installed. And defining which attributes you need to track for each asset class. You don’t need to track everything about everything, but you do need to track the right things about the assets that matter most.

Not glamorous work. And it can sometimes take months. But every organization I’ve seen that skipped it and went straight to a platform purchase had to circle back to do it anyway, with the added frustration of having spent money on a tool they couldn’t populate with reliable data.

Pick a use case, not a platform

The second mistake I see is organizations shopping for a digital twin platform before they’ve defined what they want the twin to do. That’s backwards.

A platform is just a tool. And like any tool, they’re most useful when you know what you’re planning to do with them. If you can’t articulate the first three things you want the digital twin to help you accomplish, I don’t think you’re ready to evaluate software.

Some use cases I see delivering the most value in healthcare facilities right now include:

• Fault detection and automated work orders. The integration between your BAS and your CMMS. When a sensor detects an anomaly (a VAV box running outside its set-point range for too long, a supply air temperature drifting, etc.) the system generates a work order automatically. You start catching problems before they become failures, and before they affect patient comfort or regulatory compliance.
• Compliance documentation. Joint Commission readiness is a constant effort. A digital twin that links compliance documents, inspection records, and maintenance history directly to the assets and systems they cover turns survey prep from a multi-week scramble into a reporting exercise.
• Emergency operational planning. If a critical system goes down, how quickly can your team identify what’s affected, and what the backup plan is? In a hospital, this question has direct patient safety implications. A digital twin that maps system dependencies (which AHUs serve which zones, which generators back up which panels, etc.) gives your team the ability to plan and rehearse responses to failure scenarios rather than figuring it out in real time during a crisis.
• Cross-site visibility. This matters more for health systems managing multiple campuses. When you have different buildings running different BAS platforms from different vendors, getting a unified view of performance across the portfolio is painful. A digital twin can serve as the integration layer that normalizes data from different systems into a single dashboard, so your leadership team can compare performance and allocate resources across sites without manually reconciling vendor-specific exports.

Pick one. Start there. Expand once you’ve proven the value and worked out the data and process issues that inevitably surface.

The scanning question

Reality capture comes up in almost every conversation about digital twins, and for good reason. LiDAR scanning, Matterport walkthroughs, and laser surveys can produce accurate spatial data for your facilities. That data is genuinely useful.

But while a point cloud or 3D walkthrough shows you the physical space accurately, it does not tell you which AHU serves which duct run. It doesn’t tell you when equipment was installed or what the maintenance history is. The spatial data is one layer of the twin, and it’s a valuable layer. But it’s not the whole thing.

I’ve found scanning is best used strategically. Rather than trying to scan everything at once, scan the mechanical rooms and the areas where you need accurate spatial data for a specific project or use case. If you’re doing Legionella remediation work, scan the cold-water distribution system. If you’re planning a renovation, scan the floors that are in scope. Build the spatial layer incrementally, tied to real needs, rather than committing to a full-campus scan that takes months and produces terabytes of data you don’t have a plan for.

We covered the tiered approach to reality capture in more detail in our reality capture article, and the same principles apply here. Match the investment to the certainty of the project and the specificity of the use case.

The integration reality

In an ideal world, your digital twin would read from (and write to) every system in your building. Your BAS, your CMMS, your fire alarm panel, your medical gas monitoring, all feeding data into the twin and accepting commands back.

In practice, it doesn’t work that way. Most BAS vendors offer read access, sometimes grudgingly. Full write-back capability, where the twin can push changes or commands back into the BAS, is a lot less common (and comes with real risk considerations in a healthcare environment.)

A practical approach is to treat the digital twin as a centralized read and visibility layer. Pull data from your various systems so your team has one place to go for information. For the systems that support write-back and where you’ve validated the safety implications, you enable that capability selectively. For everything else, the twin shows you what’s happening and your operators take action in the native system.

To do this you need to define authoritative sources. Your CMMS owns maintenance history and work orders. Your BAS owns set-points and real-time sensor data. The as-built drawings own spatial relationships and system routing.

The twin pulls from all of them. But there should never be a question about which system has the final say on a given piece of information.

When you’re evaluating vendors, ask specifically about integration capabilities. Can the platform read from your BAS? Which protocols does it support? Can it write back, and if so, with what safeguards? A vendor that only works in a walled garden, where your data goes in but can’t come out, is a problem you’ll deal with for years (and is one reason we built Voyager.)

Making the business case

If you’re a facility director or VP trying to get budget for this, you need numbers. The ROI arguments I’ve seen work tend to be specific and operational.

• How many hours does your team spend preparing for Joint Commission surveys?
• How much do you spend on emergency repairs that could have been caught earlier through monitoring?
• How many times have you paid to re-scan or re-survey a space because the existing documentation was unreliable?

Capital project efficiency is often the easiest financial case. If every renovation project starts with an existing-conditions survey because nobody trusts the drawings, and those surveys cost $30,000 to $80,000 each, and you do five renovation projects a year, the math on maintaining accurate as-builts starts to look pretty reasonable.

Operational savings are real, but harder to quantify upfront. Fault detection that catches a failing component before it takes down a system is valuable, but the value shows up as an avoided cost rather than a line item you can point to. This is why pilot projects matter. If you can demonstrate savings on a contained use case, you have something concrete to bring to leadership.

Industry groups, including NIBS, are working on standardized ROI frameworks for digital twin use cases. As those mature, the business case will get easier to make. In the meantime, the best approach is to document everything during your pilot: time spent, costs avoided, response time improvements, anything quantifiable.

A realistic starting point

Some suggestions on how to get started:

• Auditing your CMMS. How complete is your asset inventory? How consistent is your naming? Where are the biggest gaps? This doesn’t require new technology, just someone spending time with the database (and a fair amount of patience 🙂.)
• Pick one system or asset class and clean it up. Elevators, generators, and air handling units are common starting points because they’re high-value, well-defined, and have clear compliance requirements. Get the nomenclature right, fill in the missing attributes, make sure the data matches what’s physically installed.
• Define a pilot use case tied to that asset class. Automated fault detection for AHUs, or consolidating compliance docs for your emergency generators, something narrow enough to show results in a few months. Use the pilot to evaluate platforms, because now you know what you need the software to do. That makes vendor conversations much more productive than walking in cold and asking for a demo.
• Document everything. What the pilot cost, what it saved, what the next use case would look like. This is how programs grow, and it’s how the organizations that are furthest along got there.

Mayo, Northwell, Ohio State… none of them woke up one day with an enterprise digital twin. They built it piece by piece, starting with the data, proving value on one use case, and expanding as they earned trust internally.

You can do the same thing. The starting point is less exciting than the destination, but that’s sort of the whole point.