A Deep Dive into How AI & Simulation Technology Can Optimise Hospital Patient Flow

Introduction

Many organisations’ AI transformation strategies are centred around adopting LLMs and the software solutions built on top of them. Rightfully so. These models excel at consuming unstructured data, generating content, and automating digital workflows.

However, many of the challenges organisations face require a different type of AI. For example, LLMs are not designed to optimise complex operational systems or predict how those systems will behave over time. That’s why we embedded Computational Twin technology into Faculty Frontier. It’s a simulation capability that solves a different class of problem: modelling the real-world dynamics of entities flowing through a system.

When our teams tackle problems involving these types of systems (commonly found in healthcare, life sciences, supply chain, logistics etc.), we use this capability to help organisations forecast how the systems will behave in the future and simulate the impact of different operational trade-offs. It gives our users a superpower: the ability to see into the future and weigh trade-offs before making consequential real world decisions, all within a safe digital environment.

In a recent post, Faculty’s CTO Andy Brookes explored how Decision Intelligence is transforming patient flow at the frontlines, achieving a 22% reduction in overall patient length of stay. Here, we go under the hood and dive into the technical details of how we built and deployed the solution.

The Patient Flow Use Case

The Challenge

As discussed in the TeleTracking case study, which follows the transformation at University of Louisville Health, traditional approaches to patient flow coordination struggle to keep pace with growing patient volumes and operational demands.

Hospital operations teams make decisions throughout the day to improve flow, from where to allocate resources to which patients to prioritise. But in a large, complex system, it’s difficult to predict how these decisions will affect the rest of the hospital. For example, a decision that improves flow in one unit could create a bottleneck in the Emergency Department a few hours later.

To address this challenge, we needed to give users a way to understand the downstream consequences of different decisions across the entire hospital system and weigh those trade-offs before acting. This is where Faculty Frontier’s computational twin technology comes in.

The Solution

Decision IQ is a leading healthcare operations product built with our partner TeleTracking Technologies. It is powered by Frontier's Computational Twin technology, a framework for building a computational representation of a real-world system that can be used to optimise decision making. In the hospital use case, the Computational Twin is used to: (1) simulate a forward looking hospital state, forecasting aggregate statistics via the movement of individual patients, and (2) recommend which patients to prioritise for discharge to improve patient throughput.

Forecasts are built using a set of simple, interpretable statistical models that each represent a specific process in patient flow. Arrivals models capture the inflow of patients into the system, length-of-stay models estimate how long patients remain in each stage of their journey, and outcomes models determine which stage a patient goes to next. These models are light weight and use deliberate feature choices such as day of week, time of day, admission type which are interpretable and most predictive of operational dynamics. 

The power comes from their composition. Because the models are linked in a causal graph that mirrors how patients actually move through the hospital, the twin reproduces emergent, system-level behaviour such as waiting lists that grow non-linearly under high load. Each simulation runs multiple trajectories, producing time-series forecasts with confidence intervals for the KPIs that hospital operators actually manage: patients waiting for beds, bed balance by operational area, and discharge flow. This is dynamic systems modelling, and it's a deliberate philosophy: accuracy at the system level depends more on capturing the causal structure and feedback loops between processes than on the sophistication of any component model.

Alongside the system-level forecasts, the Computational Twin drives patient-level discharge prioritisation through its decision function. The decision function combines two signals for every patient nearing discharge. Demand is computed directly from the twin's live state: how many patients are currently waiting for the type of bed this patient occupies. Effort is predicted by a transformer model that estimates the operational complexity of discharging the patient, reading the discharge notes staff already record as part of their normal workflow, which capture real blockers like pending medication or unbooked transport. The CT’s architectural flexibility doesn’t prohibit the integration of more complex models. It just encourages developers to be more deliberate about their choices.

Within the decision function, a hierarchical decision tree buckets patients by combining the demand and effort estimates to assign a prioritisation score. The intuition is simple: a patient who is easy to discharge and occupying a high-demand bed is the highest-value action a hospital can take right now.

The Superpower: Simulate, Decide, Act.

Levers are how users test trade-offs. Hospitals constantly face strategic questions with no obvious answer: should we focus on relieving ED boarding or freeing ICU capacity? Levers let operational teams re-weight the Computational Twin's priorities by focusing demand on a specific intake area like the ED, or a specific destination like the ICU. They can then simulate forward to see the downstream consequences before committing. Reducing ED pressure might slow transfers elsewhere. The twin makes that trade-off visible in advance, rather than discovering it after the fact.

The lever a patient flow leader selects directly shapes the prioritisation scores distributed across the hospital. When a leader chooses to focus on prioritising discharges from medical wards, the scores that nurses and coordinators see on their wards already reflect that strategic call. The decision made at the top of the system flows automatically to the frontline. No more negotiations, no more phone calls. Everyone is on the same page, acting towards the same goals with data-driven insights into why.

Scaling & Data Layer

Scaling was designed in from the start, and the data layer is the reason it works. The Computational Twin exposes a standardised, opinionated data interface: a well-defined event schema with consistent temporal structure that already conforms to the conceptual model of patient flow (bed requested, bed assigned, discharge milestone logged, patient discharged). All the heterogeneity in how individual hospitals record these concepts is reconciled upstream of this interface, so the twin itself never contains hospital-specific workarounds.

Because the Computational Twin consumes a standardised event stream rather than raw hospital systems, onboarding a new hospital doesn't mean re-architecting—it means calibrating. Each new campus trains the same model structure on its own data, adjusting for local differences in patient volume, case mix, ward composition, and resource constraints. The underlying dynamics of patient flow from emergency arrival through discharge are broadly consistent across hospitals; it's the distributional parameters that differ.

Before any site goes live, we validate the calibrated twin by comparing forecasts against what actually happened over dozens of held-out historical time periods, with accuracy thresholds calibrated to each site's patient volumes. This balance between generalisable system design, local configurability, and rigorous pre-deployment validation is what lets the framework scale while maintaining accuracy and interpretability.

Safety & Governance

Explainability & interpretability. Every relationship in the Computational Twin can be explained in plain language, each model recalibrates quickly with new data, and clinical and operational stakeholders can trust what they see because they can understand it in their own domain language. Likewise, the design of the decision function is intentionally interpretable, so that staff can trace every score back to explicit factors. The Computational Twin becomes a shared mental model of how the hospital works, rather than a black box. This is crucial for adoption and safety in highly regulated domains like healthcare.

No clinical data in the system models. The system-level models deliberately use only operational features, e.g., time of day, admission source, discipline. Clinical variables add minimal predictive value for aggregate system dynamics, and excluding them reduces governance overhead and makes models transferable across hospitals. Clinical context enters only at patient-level predictions, like the effort score, where it genuinely helps.

Humans stay in the loop. The system produces ranked priorities and forecasts. Clinicians and operational teams make decisions. Nothing is automated away from staff judgement, and every score is traceable to explicit, explainable factors.

Aggregate prediction, not patient surveillance. The Computational Twin predicts flows between system states, not individual patient outcomes. That framing matters both technically and ethically. It's the right tool for capacity management, keeping the product's data footprint proportionate to its purpose.

Results

TeleTracking’s Decision IQ engagement with University of Louisville Hospital started in January 2025, followed by a full product launch in August 2025. To measure impact rigorously, hospital leadership and TeleTracking agreed upfront which KPIs to track during the trial period, including discharges before 11am and 2pm, and average length of stay. These metrics were tracked at both the live hospital and a control hospital in the same network with a similar patient mix. This controls for seasonality, network-wide policy changes, and external factors: if the improvement is real, the live hospital should demonstrate improved KPI trends compared to the control. It did!

The headline result was a 22% reduction in average length of stay, while the control site remained flat over the same period. Reducing length of stay by limiting avoidable delays is widely considered the holy grail of patient flow improvement, indicating better patient outcomes as well as cost efficiencies. The operational KPIs moved in the same direction. Discharge processing decreased by 15 min on average and 20% more patients were discharged before 11am, freeing beds when demand from the ED is highest. A full results breakdown is available in our case study.

The next step is scaling this impact across many more sites in the US and UK, with five more sites ready to launch in September.

Care to learn more?

Faculty Frontier™ is Faculty’s Decision Intelligence Platform. At its core is the Computational Twin, a virtual representation of an operational process that connects data and AI models to simulate outcomes and guide decisions.  

If you're interested in exploring how computational twins can be applied to complex operational challenges in healthcare and beyond, or want to see how Faculty Frontier’s Computational Twin works in practice, we’d love to connect.

Contributors

This article was developed with contributions from colleagues across Faculty’s data science, engineering, product and delivery teams:

• Charlotte Harris, Senior Manager

• Zoe Leadbetter, Delivery Manager

• Joanna Huang, Lead Data Scientist

• Lukas Malms, Senior Data Scientist

• Roxana Alexandru, Lead Data Scientist

• Patrick Oladimeji, Engineering Manager

• Tara Ganepola, Principal Data Scientist

• Vishaal Thanawala, Principal Product Manager