What OR Forecasting Needs From The EMR
By Bradley McLain, Chief Technology Officer, ORlogic
Resource-strapped technical buyers usually focus on two primary questions: What do you need from us? And how much of my team’s time is required?
Analytics projects have earned a reputation for arriving with modest requests for data that somehow expand into a six-month integration death march. So it is worth being specific about what an OR forecasting EMR implementation actually requires, where those data live in the environment, and what the extraction work might look like.
Here is the good news: the EMR is already producing everything as a by-product of running the OR schedule. The real work is locating those data, not generating them.
What the Model Needs
Forecasting surgical volume is a case-level problem, so the primary input is a case-level record. Each case should come with the scheduling and execution facts that describe when the case was booked, when it was scheduled to occur, and then what actually happened:
Identity and location. Case identifier, facility, and room.
Timing. Scheduled start and end. Actual start and end — wheels in, wheels out.
Classification. Procedure, service line, surgeon, and anesthesia type.
Provenance. The booking timestamp, and the timestamps on subsequent status changes. When a case entered the schedule matters as much as the fact that it is there.
Disposition. Whether the case was completed, canceled, bumped, or added on, and when that determination was made.
That is the core. Those fields are matched to configuration details that rarely change: the room inventory, the block schedule, service line assignments, and the facility calendar — holidays, planned closures, scheduled downtimes.
Calendar configuration pays significant dividends if maintained regularly, and should never be skipped. Generally, a surgical suite behaves differently on any given Wednesday than it does on the Wednesday before Thanksgiving. Failing to account for this distorts the baseline and introduces avoidable errors for all forecasts.
Finally, case history is extremely important. Twelve months is acceptable, but eighteen or twenty-four is much better for positively identifying recurring seasonality in the data. This effort requires no new fields, so the data generally exist at least back to implementation of the EMR.
What Is Not Required
It is worth stating plainly what is absent from the list above. No clinical notes. No labs, imaging, medication records, diagnoses, or problem lists. No billing or claims data. No patient identifiers — no names, no MRNs, no dates of birth. A case is a scheduling event with a surrogate key.
The consequence is that the extract is narrow. It is a scheduling table, not a clinical one, and that shapes everything downstream: the review it requires, the agreement that governs it, and how much of a privacy officer’s attention it consumes.
Where Data Live
In most environments, these data sit in two distinct places, and the distinction matters because it usually means two different teams.
The operational record lives in the perioperative scheduling module — OpTime in an Epic environment, SurgiNet in Cerner, the equivalent module elsewhere. This is the live system of record for the OR schedule, and it is the source for anything that needs to reflect current state.
Historical records live in the reporting layer — Clarity or Caboodle, a Cerner data warehouse, or whatever enterprise warehouse the organization has adopted. This is where the multi-year case history required for a backfill is already modeled and queryable, typically by a report writer who has written a hundred variations of this query before.
So the initial ask generally goes to an analytics or reporting team, and the ongoing ask generally goes to an integration team.
How Data Arrive
There are multiple pathways for obtaining case records:
Flat-file extract. A delimited file, dropped to SFTP or object storage on a schedule. For the historical backfill this is almost always the right answer — it is a report-writing task with a well-defined output, not an interface project. It is also perfectly legitimate for the ongoing feed, and is the most common mechanism.
HL7 v2. If an interface engine already exists — Rhapsody, Mirth, Cloverleaf — scheduling messages are the standard path for an ongoing feed. Most facilities are already generating SIU messages for other consumers, and adding a subscriber to an existing feed is meaningfully less work than building one from scratch.
FHIR. Where the EMR exposes it, the relevant resources map cleanly onto necessary fields, and authorization and audit are cleaner than for HL7. FHIR coverage for perioperative scheduling still varies by vendor and by version, so this is a conversation about the specific environment rather than a general recommendation.
Direct database read. Usually not permitted, but an available option.
What This Costs
None of this requires new instrumentation. The OR schedule generates these records as a condition of functioning, so the forecasting problem is one of access and assembly rather than collection — a narrower effort than is usually assumed.
That narrowness determines the resource requirement. The historical backfill is a query against tables the reporting team already maintains, and in most environments against reports that already exist in some form. The work is filtering and formatting, not building. The ongoing feed is either that same query on a schedule or a subscriber added to a message flow that is already running. In neither case does anyone construct something that did not exist before.
Measured in effort, the extraction is small and concentrated in one or two people who have done this kind of work many times. Measured end to end, an initial delivery generally lands within a couple of weeks, and most of that window belongs to review and approval rather than to engineering. That is the correct proportion for a project of this shape.