In 2025, just over half of health system technology leaders said they were willing to wait for their EHR vendor to build the AI scheduling and optimization features their perioperative teams were asking for. By early 2026, that number had fallen to 22%.
That's not a marginal dip. It's a strategic reversal, and it shows up in independent industry research. A survey published in early 2026, drawn from more than 60 health system technology leaders, found that 74% now name EHR dependency as their single biggest barrier to operationalizing AI. The message from the people running these projects is unambiguous: waiting on the EHR roadmap isn't working, and neither is building the capability from scratch.
That leaves three real paths for a health system that wants AI-driven OR scheduling: build it internally on top of Epic, Cerner, or Oracle Health; keep waiting for the EHR vendor's own roadmap to catch up; or add a modular intelligence layer designed to sit on top of the EHR you already have.
Why "wait for the EHR" stopped being a strategy
Epic OpTime, Oracle Health's Cerner SurgiNet, and MEDITECH Expanse Perioperative are built to document the OR — scheduling, preference cards, anesthesia records, the legal and clinical record of what happened. That's the job they were designed for, and they do it well. It is not the same job as predicting how long a case will actually take or telling a scheduler which block to release before it goes unused.
Research published in the Journal of Medical Systems has found that conventional, average-based scheduling models — the kind most EHR modules run on — are accurate within 10% only about one-third of the time. That gap doesn't close because a health system waits longer. It closes when a model is trained specifically on surgeon-level, case-level, and time-of-day variation, which is a different category of software than an EHR's native scheduling module was built to deliver on its current roadmap.
The 52%-to-22% collapse in that survey data reflects that realization spreading across the CIO community. A year of watching EHR roadmaps move slower than perioperative demand has convinced most technology leaders that "next release" isn't a plan.
Part of the reason is structural, not a failure of any one vendor. Epic and Oracle Health each maintain hundreds of modules across the entire hospital — inpatient, ambulatory, revenue cycle, population health — and perioperative AI competes for engineering priority against all of them. A capability that would be a top priority for a 12-room OR is one line item on a roadmap built for the whole enterprise. That's not a criticism of the EHR vendors; it's a description of how enterprise roadmaps get built, and it's exactly why waiting for OR-specific AI to rise to the top of that list has become a losing bet for perioperative leaders on a real timeline.
Why "build it yourself" rarely pans out
The build option looks appealing on paper: your health system already has a BI team, a Reporting Workbench license, and data warehouse access. Why not build the prediction model in-house?
The honest math rarely supports it. A perioperative-focused BI analyst typically runs $120,000 to $180,000 fully loaded. Building and maintaining a genuine OR intelligence capability — not a dashboard, but a predictive model with surgeon-specific variation, real-time orchestration, and a usable interface for schedulers and surgeons — realistically requires three to five FTEs: a data scientist, a perioperative subject-matter expert, a mobile or front-end developer, and ongoing project management. That's a seven-figure annual commitment before the model has proven anything, and the data scientists capable of building OR-specific prediction models are scarce enough that retention is its own risk.
It is a significant investment to pilot. Internal builds don't usually fail because the idea is wrong. They fail because the cost and timeline were underestimated against a health system's actual data science bench strength.
The cost that rarely makes it into the initial proposal is maintenance. A model that predicts case duration well in year one needs retraining as case mix, staffing, and surgeon rosters change — which means the FTE commitment isn't a one-time build cost, it's a permanent line item. Health systems that go this route successfully tend to be large academic centers with existing data science teams and a multi-year horizon to absorb the ramp. For everyone else, the build option is really a decision to defer the outcome by two to three years while carrying the run-rate cost the entire time.
Do you have to replace Epic, Cerner, or Oracle Health to add AI scheduling?
No. A modular OR intelligence layer integrates through the same HL7 messaging and APIs your Epic, Oracle Health, or MEDITECH environment already supports — reading ADT, ORM, and DFT feeds and returning scheduling recommendations, block-release alerts, and case-duration predictions. The EHR remains the system of record for clinical documentation, billing, and the legal record. Nothing about that changes.
What does change is the timeline. Most modular deployments go live with a single module — usually block utilization or case duration prediction — in four to eight weeks, not the multi-quarter build cycle an internal project or a major EHR module rollout typically requires. And because the layer is EHR-agnostic, it survives a future EHR migration instead of forcing a rebuild.
Build, wait, or layer: a straight comparison
Is Leap Rail an Epic OpTime alternative?
Not exactly — and the distinction matters. Leap Rail isn't a replacement for Epic OpTime's scheduling and documentation functions; it's a layer that sits on top of them, alongside Oracle Health's Cerner SurgiNet and Millennium, Altera Sunrise, MEDITECH, McKesson Paragon, NextGen, eClinicalWorks, athenahealth, and other leading platforms. Your EHR strategy doesn't need to change for the layer to deliver value, and it doesn't need to change again if your EHR strategy does.
What the layer adds is the prediction and action layer the EHR isn't built to provide: a published, Harvard Medical School–validated study in the Journal of Medical Systems documented a 70% improvement in case duration prediction accuracy over EMR averages using this kind of model. Health systems running a modular layer alongside their existing EHR have reported up to 20% increase in block utilization rates and a 20% reduction in preventable surgical cancellations — recovered without a rip-and-replace project or a multi-year capital ask.
For the CIO evaluating this against the due-diligence questions above: Leap Rail's business is running perioperative software, full stop — not claims management, not supply distribution, not a payer relationship.
The real decision in front of you
The decision most CIOs think they're making is "which vendor." The decision they're actually making is "which category" — build, wait, or layer a modular, provider-focused intelligence tool on top of the EHR investment already made.
For most health systems without a multi-year capital cycle and a data science bench to spare, the honest answer is that waiting and building have both been tried, and the 2026 data from CIOs who tried them says so. Layering isn't the only option. It's the option that doesn't ask you to do nothing for another budget cycle or bet years of engineering time on a capability you may not retain the talent to maintain.
See how a modular layer would connect to your EHR
If you're weighing this decision for your own environment, connect with the Leap Rail team to learn exactly what integration looks like against your specific EHR and perioperative systems — no rebuild, no rip-and-replace. Reach out today.