Connecting the dots: data integration for a hospital digital twin

EHR, RTLS, building systems and rostering — which sources matter, how they connect, and how to protect patient privacy along the way.

Guide 6 min read · By the HospitalOn team
Data centre server racks with red status lights

A hospital digital twin is only as good as the data that feeds it. The 3D model may be what people notice first, but it is the steady stream of live information underneath — admissions, bed states, equipment locations, room temperatures, staff on shift — that turns a picture into a working tool. This guide explains which data sources matter most, how they typically connect, and how to integrate them without disrupting clinical systems or compromising privacy.

Why integration is the foundation

Hospitals do not lack data. They lack connected data. Information about a single patient journey may live in half a dozen systems that were never designed to talk to each other: the patient administration system knows a patient has been admitted, the bed management tool knows which bed is clean, the porter system knows a transfer has been requested, and the theatre system knows a list is overrunning. Each holds part of the story.

A digital twin brings these fragments together on a shared spatial model of the hospital. That is what allows it to show how a delay in one department will affect another — and to simulate what happens next. If you are new to the concept, start with our guide What is a hospital digital twin?

The core data sources

Electronic health record and patient administration

Admission, discharge and transfer events are the heartbeat of patient flow. They are usually available through HL7 v2 messages, which most hospitals already exchange between systems, and increasingly through FHIR APIs. For operational modelling, the twin rarely needs detailed clinical content. Event types, timestamps, locations, specialty and expected discharge dates are often enough.

Real-time location systems

RTLS tags — using technologies such as Bluetooth Low Energy, infrared or ultra-wideband — show where equipment, and sometimes staff, are in the building. In a twin, this data answers practical questions: where is the nearest available infusion pump, and which wards are hoarding wheelchairs?

Building management and IoT sensors

Building management systems control heating, ventilation, air conditioning and lighting. Combined with IoT sensors for temperature, humidity, air quality and occupancy, they let the twin model environmental conditions and energy use room by room. This is the basis for reducing waste while protecting clinical areas with strict requirements, such as theatres and isolation rooms.

Workforce and rostering

Beds do not care for patients; people do. Rostering and staffing data allows the twin to compare predicted demand with available nurses, doctors, porters and cleaners — and to flag gaps before they become crises.

Theatre and scheduling systems

Theatre lists, booked procedures and expected durations connect planned activity to downstream bed demand. This link is central to our use case on optimising operating theatre utilisation with simulation.

Spatial data

Finally, the twin needs a map. CAD floor plans, BIM models or a rapid site survey provide the geometry of wards, rooms, corridors and lifts that every other data stream is anchored to.

Integration patterns that work

The safest approach treats the twin as a consumer of data, not a replacement for existing systems. In practice, that means:

  • Read-only by default. The twin listens to existing feeds rather than writing back into clinical systems. This limits risk and simplifies approval.
  • Reuse existing interfaces. Most hospitals already route HL7 messages through an integration engine. Subscribing to those feeds is usually faster than building new point-to-point connections.
  • Event streaming over batch. Operational decisions happen in minutes, so near-real-time event feeds are far more valuable than overnight extracts.
  • Standard APIs where possible. FHIR resources and open building protocols reduce custom work and make the twin easier to maintain.

Data quality and latency

Integration projects often discover that the data is less tidy than expected. Bed states may be updated late, discharge times recorded in bulk at the end of a shift, or location codes inconsistent between systems. A good implementation includes an early data quality review and works with teams to improve recording practices where it matters most. The twin itself can help: when people see their updates reflected instantly on a shared picture, recording discipline tends to improve.

Latency matters too. A prediction about an emergency department surge is only useful if it arrives in time to act — which is why our use case on predicting emergency department surges depends on near-real-time admission and attendance data.

Rule of thumb: connect the minimum data needed for the first decision you want to improve. You can always add sources later; you cannot easily win back trust lost to a slow, over-scoped integration.

Privacy by design

Patient privacy is non-negotiable, and it should shape the architecture from the first day. Operational twins model flows, capacity and resources — not identities. Practical safeguards include:

  • Data minimisation: ingest only the fields required for operational modelling.
  • Pseudonymisation or de-identification wherever individual patient identity is not needed.
  • Encryption in transit and at rest, with role-based access controls and audit logs.
  • Deployment options — cloud, private cloud or on-premise — that match your governance requirements.
  • Alignment with frameworks such as HIPAA, GDPR and ISO 27001.

Involving information governance teams early turns them from gatekeepers into partners and speeds up approval considerably.

A phased integration roadmap

  1. Foundation: spatial model plus admission, discharge and transfer events for one area.
  2. Flow: add bed states, transfers and theatre schedules to model patient movement across departments.
  3. Resources: bring in RTLS and workforce data to match demand with equipment and staff.
  4. Environment: connect building management and IoT sensors for energy and comfort optimisation.

Each phase delivers value on its own, which makes the investment easier to justify — see our guide on building the business case for a hospital digital twin.

Conclusion

Integration is where hospital digital twins succeed or stall. Start with a clear decision, connect only the data it needs, protect privacy from the outset and expand step by step. Do that well, and the twin becomes something rare in healthcare IT: a single, trusted picture of how the hospital is really running.

Want to map your data sources with our team? Get in touch or browse more resources.

Keep reading

GUIDE · 6 MINWhat is a hospital digital twin? A practical guide → GUIDE · 6 MINHow to build the business case for a hospital digital twin →

Your data, finally connected.

See how HospitalOn plugs into the systems you already run.

Book a demo