★★★★★· Trusted by Brisbane finance and operations teams· Fixed-price, always· 0433 345 000

Operating theatre analytics in Australia, and what it costs

Theatre time is one of the scarcest resources in a surgical service. Reporting that shows where it goes — list by list rather than quarter by quarter — is what makes lost theatre time visible early enough to do something about it. This page covers what that reporting shows, what it runs on, and what it costs.

Ask a question Get started — book & pay

What operating theatre analytics actually reports

Operating theatre analytics is reporting built on data your surgical service already generates — bookings, case timings, rosters, and whatever record is kept when a procedure does not go ahead. Its job is to show where theatre time went, at the level of the individual list, while there is still time to change the next one.

Most theatre reporting stops short of that. A single utilisation figure averaged over three months is enough for a board paper and close to useless to the person building next Tuesday’s list, because it cannot say which theatre lost the time or what took it.

Reporting that changes a decision has to work at the level of the individual case: was the list ready when the session opened, how long did the room sit empty between patients and what was it waiting on, and which bookings fell over before they reached theatre. That is a data-model question before it is a dashboard question, which is why this work so often stalls at the extract rather than at the visual.

Roar Data builds this reporting for health providers — public health services, private hospital groups and day hospitals, in metropolitan, regional and remote settings. We are a reporting and analytics practice, not a clinical software vendor: clinical judgement stays with your people, and what changes is that the numbers stop being an argument.

What the reporting covers

Theatre utilisation at list and session level, rather than a quarterly average

On-time starts for the first case in each theatre, weekday by weekday

Time between patients — and what the room was waiting on, where your data records it

Cancellations grouped by cause, by specialty and across the year

Session starts and finishes measured against the scheduled list

Visiting and fly-in surgeon sessions tracked apart from resident sessions

Theatre time lost to equipment, staffing and bed availability

The case-level detail behind every number, so a list can be opened up rather than argued about

What operating theatre analytics costs in Australia

Four things make up the total. One is a published fixed price, one is quoted in writing before work starts, one is Microsoft's, and one is yours.

Roar Data publishes its starting prices: focused builds start at $3,250 and full transformations from $10,000, always fixed-price, including GST. What cannot honestly be published is where a theatre build lands between those, because that depends on data nobody can see from outside your organisation. What can be published is the structure of the cost, the things that move it, and the one number that is the same whatever your situation.

Reporting diagnostic: $1,950 including GST — the same starting point for every engagement. Credited back in full against the build if you proceed within 30 days. You keep the written action plan either way, including the 30-day fix path.
The build: Quoted as a fixed price before any work starts, based on what the diagnostic found, with the scope it covers written next to it. Focused builds start at $3,250 and full transformations from $10,000, excluding GST. No open-ended invoices: any change to the agreed scope is quoted as a fixed price of its own before it is done.
Platform licensing: Paid to Microsoft, not to us. Power BI is licensed per user per month, with capacity-based licensing (Fabric) as the alternative once you are sharing widely or refreshing heavily. Microsoft publishes both list prices — check the current rates when you budget, and count the people who need to open the reports, not the people who build them.
Running it afterwards: Refreshes, access changes, new measures and the occasional definition argument. Some providers absorb this internally after handover, which is what the training is for; others prefer an ongoing support arrangement. Either way it is a separate, ongoing decision from the build.

What moves the build number

How many systems have to be joined: One clean extract from a theatre management system is a different build to joining that system with a patient administration system and a rostering tool, each with its own idea of what a session is.
Case-level data, or already aggregated: Case-level scheduling data — booked start, actual start, in and out of theatre, finish — supports every metric on this page. Data that arrives already summarised by month cannot be taken back apart, and rebuilding that detail is usually the most expensive item on this list.
Structured cancellation reasons, or free text: Reasons chosen from a list can be grouped and trended on day one. Reasons typed into a note field have to be categorised before they mean anything, and that is scoping work rather than a keystroke.
Whether staffing and rosters are in scope: Joining the roster to the theatre session is what turns “the list started late” into “the list started late, and here is what was happening in the department”. It also adds a source system, a matching rule, and a set of access decisions.
How many sites, and whether they agree: Multi-site is rarely a multiplication. The cost is in reconciling definitions: if two sites count a session start differently, the reporting has to hold both and say so, or the group number means nothing.
How the data comes out: A supported view, scheduled extract or API is straightforward. A system that will only produce a nightly report rather than data is not, and the answer there is usually a conversation with your vendor before it is a build.
How much history you want loaded: Seasonality in cancellations needs more than one quarter to be visible. Loading and cleaning history is usually modest, but it is not free, and it is worth deciding deliberately rather than by accident.

Three scopes, so you can locate yourself

Single suite, one clean source

One site, case-level scheduling data out of one system, cancellation reasons already coded. Utilisation, first-case starts, time between patients and cancellations, built against definitions your team signs off. This is the smallest version of the work, and the shape a single day-surgery suite usually calls for.

One site, rostering joined, reasons to structure

Theatre lists in one system, staffing in another, and cancellation reasons captured as free text that has to be categorised before it can be trended. Two sources, a matching rule between them, and a real piece of data work in the middle. This is the shape a single-hospital build usually takes.

Multi-site, PAS and theatre management joined

Several sites or a whole surgical service, a patient administration system joined to theatre management and rostering, history to load, and definitions that differ between sites and have to be agreed before anything is trusted. The build is bigger; the reconciliation is the part that takes the time.

The part that costs you rather than us

Two things reliably surprise people, and neither of them appears on our invoice. The first is data access: getting an extract approved out of a clinical system is an internal process with its own queue, and it is worth starting the week you engage rather than the week we ask. The second is your own people’s time — a few hours from whoever knows how the scheduling system is actually used, and a decision from whoever owns the definitions about what counts as a session start, what counts as a cancellation, and who is allowed to change either. Reporting that skips that conversation gets argued with instead of used.

Want a sense of the number before you spend anything? Tell us which of the three scopes above looks most like your situation and how your cancellation reasons are recorded. That is enough for a straight conversation about magnitude. The diagnostic is what turns it into a fixed price we put in writing.

Pricing and licensing information on this page last reviewed August 2026.

What software operating theatre analytics runs on

Three layers: the systems that already hold your data, the reporting layer you read it in, and the decision between buying a product and building on your own data.

The systems your data already lives in

None of this requires new clinical software, and nothing gets replaced. The systems you already run are producing the data; the work is getting it out of them and into the hands of the people making the day-to-day calls.

Theatre management system — bookings, session allocation, case timings

Patient administration system (PAS) — the patient journey either side of theatre

Rostering or workforce system — who was scheduled, and who was actually on

Elective surgery waiting list data — where the demand behind the lists sits

Spreadsheets — where cancellation reasons and local rules usually live in practice

The reporting layer

Roar Data builds in Power BI, and in Microsoft Fabric where data volume or refresh frequency calls for it. That is a deliberate choice rather than a house preference: where your organisation already runs Microsoft 365, the reporting sits inside the identity, access control and data-residency arrangements you have already made, and your team can be trained on a tool they can keep using without us.

Practically, that means reports are shared to named people and groups rather than emailed around, refreshes are scheduled rather than manual, row-level security can restrict a site or a specialty to the people who should see it, and licensing is per user per month or capacity-based, paid to Microsoft. The build itself is ordinary Power BI dashboard development work applied to a clinical scheduling problem.

Buy a product, or build on your own data

There is a real choice here, and it is not always a build. A theatre analytics module sold by your theatre management vendor is quick to switch on, needs almost no data work, and reports what that vendor’s system knows. If your question is “did our lists start on time”, that may be all you need.

A build joins systems the vendor cannot see. If your question is “why did they start late, and what was happening on the roster and in the ward when they did”, a single product rarely holds the answer, because the answer lives in the joins. That is the work we do — and if a product would answer your question, the diagnostic will say so rather than quote you a build.

Theatre reporting across Australia: public, private and day surgery

Theatre reporting is not one problem. What the numbers are for changes with who owns the theatre.

Public health services

State and territory health services typically report against elective surgery waiting lists and urgency categories, and much public hospital activity is funded on an activity basis rather than a block budget — arrangements vary by jurisdiction. That puts weight on the same case-level record twice, once for the operational question and once for the funding one, so definitions have to survive both. Reporting that cannot be reconciled back to the source record is not much use to either.

Private hospital groups

Theatre time is directly commercial. The recurring questions are session allocation between visiting medical officers, utilisation against what was allocated, and where sessions are being handed back too late to refill. Group reporting also means several sites, which means a reconciliation problem before any comparison between them is fair.

Day hospitals and day surgeries

High volume, short cases, and the gap between patients as the dominant variable — a few minutes per case compounds across a list in a way it does not in long tertiary work. The data is often cleaner and confined to one system, which usually makes this the fastest version of the build.

Regional and remote services

Visiting and fly-in specialist blocks, locum cover and travel logistics mean the list is shaped by things a metropolitan planner never has to model. Reporting has to be built around the theatre and the case rather than a named clinician, or it stops making sense the week the roster changes.

Theatre reporting is usually one part of a wider picture — patient flow, workforce, activity and cost all sit next to it, and the same data work supports more than the theatre suite. Our Power BI for healthcare page covers how that fits together across a health service.

What your theatre data has to look like

You do not need clean data to start — establishing what you actually have is what the diagnostic is for. But these are the things the reporting leans on, and they are the same things that move the price.

Case-level records rather than monthly summaries

Booked and actual times: scheduled start, in and out of theatre, finish

A stable identifier for the session, the theatre and the specialty

Cancellation reasons recorded against a code list, ideally with who cancelled and when

Roster data that can be matched to a session, where staffing is in scope

A supported way to get the data out on a schedule, rather than a manual export

The item most often missing is the cancellation reasons. They get typed into a note field, abbreviated differently by each person who records them, and they are a common reason a theatre dashboard can show what happened but never why. It is fixable — usually by agreeing a short reason list with the people who record it, and categorising the history you already hold — but it is scoping work, and it belongs in the quote rather than in a surprise.

Where a reason was never recorded, the reporting says so. A blank is a finding about your data, not a gap to be filled in with an assumption.

Patient data, privacy and access

Health data attracts more care than most reporting work, and buyers are right to ask about it before anything else. Two things are worth saying plainly.

The first is that theatre reporting rarely needs identified patient data at all. Utilisation, on-time starts, room turnaround and cancellation analysis are built on the session, the theatre, the specialty and the case timings. Where an identifier is needed to join records across systems, it is kept inside the data model rather than surfaced anywhere in the reporting.

The second is that the data stays inside your controls. The reporting is delivered into your Microsoft tenant and runs under your organisation’s access rules, with row-level security where a site or a specialty should only be visible to particular people. Where data is handled during the build is agreed with your information governance people up front, and we work to the access your organisation grants and the agreements it puts in place — Roar Data is a reporting practice, not your privacy adviser, and we would not want to be. Involve those people at the diagnostic rather than after the build; the conversation is much shorter that way.

How an engagement runs

Diagnostic

We look at the scheduling, staffing and cancellation data you already hold, and establish what is reportable now and what needs work first. $1,950 including GST, fixed.

Written action plan

Speed issues, KPI drift, governance gaps, and a practical 30-day fix path — plus which of the three scopes above you are actually in. Yours whether or not you continue.

Fixed-price build

The theatre reporting itself, quoted before it starts, built against the definitions agreed in the diagnostic. The diagnostic fee is credited back in full if you proceed within 30 days.

Handover

Your team runs it afterwards. Training and handover are included in the quoted build rather than charged as a separate engagement, and the model is documented so the next person can pick it up.

Common questions

What is operating theatre analytics?

Reporting built on the data your theatre suite already produces — bookings, case timings, rosters and cancellation records — so theatre time can be measured at case and list level rather than as a quarterly average. In practice it answers four questions: did the list start on time, how long did the room sit empty between patients and what was it waiting on, what did not go ahead and why, and how much of the allocated session was actually used.

What does operating theatre analytics cost in Australia?

Roar Data publishes its starting prices: focused builds start at $3,250 and full transformations from $10,000, always fixed-price, including GST. Where a theatre build sits between those depends on how many systems have to be joined, whether your scheduling data is case level, and whether cancellation reasons are coded or free text. That is what the $1,950 including GST reporting diagnostic establishes, and the diagnostic fee is credited back in full if you proceed with the build within 30 days. Power BI licensing is paid to Microsoft separately, at their published rates.

Why isn’t there one price for a theatre build?

Because the same theatre dashboard is a different amount of work at two hospitals: one has clean case-level data in a single scheduling system, the other has theatre lists in one place, staffing in another, and cancellations recorded as free text. The starting prices are published; the figure for your build is set once someone has looked at your data. This page sets out the four things that make up the total and three scopes you can locate yourself in, and the diagnostic turns that into a fixed number in writing.

What software does operating theatre analytics run on?

The reporting is built in Power BI, and in Microsoft Fabric where refresh volume calls for it, on top of the systems you already run: theatre management, patient administration, rostering, and usually a spreadsheet or two. No new clinical software is involved, and nothing is replaced.

Should we buy a theatre analytics product instead?

Sometimes, and we will say so. A module from your theatre management vendor is quick to switch on and reports what that system knows. A build is the right answer when the question spans systems the vendor cannot see — scheduling against rostering, or theatre against ward and patient flow. The diagnostic is where that call gets made, and it is made before you have committed to a build.

Which states and territories do you work in?

We work with health providers anywhere in Australia — public health services, private hospital groups and day hospitals. Theatre reporting is built around scheduling and rostering systems rather than a physical location, so most of the work happens remotely, with on-site workshops where they earn their place. Our office is in Brisbane.

How is patient data handled?

Most theatre reporting does not need identified patient data at all: it runs on session, theatre, specialty and case timing. Where an identifier is needed to join records, it is kept inside the data model rather than surfaced in the reporting. The reporting is delivered into your Microsoft tenant and runs under your organisation’s own access rules, with row-level security where a site or specialty should only be visible to particular people. Data handling during the build is agreed with your information governance people up front, and we work to the controls and agreements they set — we are a reporting practice, not your privacy adviser.

Does it integrate with our theatre management system or PAS?

That is the normal case rather than the exception. What matters is not the brand of the system but whether it can give you a supported, scheduled extract, view or API at case level. Where a system produces reports rather than data, that is worth establishing early, and it is one of the first things the diagnostic checks.

What data do you need to start?

Usually theatre scheduling data at case level, staffing or roster data where that is in scope, and whatever record you keep of cancellations and their reasons. If some of that lives in spreadsheets rather than a system, that is normal and does not stop the build — it is one of the things the diagnostic scopes.

How long does a build take?

That is set in the diagnostic along with the price, because it depends on the same variables. The diagnostic itself gives you a written action plan whether or not you continue — speed issues, KPI drift, governance gaps, and a practical 30-day fix path.

Ask about theatre reporting

Tell us what your theatre data looks like now and what you cannot see. We reply within one business day — a practical conversation about your numbers, not a sales pitch.

Theatre planning in the Northern Territory

Working in the Top End? Theatre planning there is shaped by charter flights, wet season logistics and fly-in specialist blocks, which changes what the reporting has to surface and how it has to be structured to survive a rotating roster.

Theatre reporting for Darwin and the Top End

See what your theatre reporting should look like

Book the diagnostic and get a written action plan for your theatre data — $1,950 including GST, credited back in full if you proceed with the build within 30 days.

Get started — book & pay Or ask a question first