How to Choose a Smart Operating Room System: 10 Questions to Ask Vendors

Smart operating room systems can look remarkably similar in a presentation. Most vendors talk about artificial intelligence, computer vision, workflow analytics, automation, and improved efficiency.

Underneath those claims, however, the systems may work in fundamentally different ways.

Systems differ in what they sense, how much of the room they can see, and what they do with what they observe. Some recognize a handful of basic milestones. Others are designed to support documentation, resource coordination, training, inventory optimization, and patient-safety applications. And critically, some deliver their output into the systems your teams already use, while others give you one more dashboard to check.

These differences determine what a system can reliably do, not only during a demonstration, but in a crowded operating room where people, equipment, lights, booms, and drapes are constantly moving.

If you are still weighing whether operating room intelligence is worth the investment, that case rests on your own numbers: utilization, turnover, documentation burden. This guide is for the step after that decision: choosing between systems that describe themselves in remarkably similar language, and separating the platforms that will deliver in your rooms from the ones that only demo well.

Ask every vendor these ten questions.

1. How much of the room can the system actually see, and what happens when its view is blocked?

Occlusion is not an unusual exception in an operating room. It is the normal environment.

Staff move between the patient and the sensors. Surgical lights and ceiling-mounted booms change position. Equipment carts enter and leave. Drapes cover the patient and instruments. Crowded cases can block large parts of the room for extended periods.

Coverage sets the ceiling on everything else. A wide-angle camera is not the same as complete room coverage. No amount of software can recover what the sensors never saw, and blind spots discovered after installation are expensive to fix in a room you have already closed once. A system that loses track of the room whenever someone stands in the wrong place will fail in exactly the cases where you need it most: the crowded, complex ones. Those gaps quietly become missing documentation, wrong timestamps, and analytics you cannot trust.

Ask the vendor to provide a room-coverage diagram showing:

• The number and location of sensors
• The area covered by each sensor
• Known blind spots
• How information from different viewpoints is combined
• What happens if one sensor becomes unavailable
• Whether the system must be recalibrated when equipment moves

Then ask what happens in a working room:

• What happens when a person blocks one of the viewpoints?
• What happens when a boom or surgical light moves in front of a sensor?
• Can the system continue tracking activity using another viewpoint?
• Does it recognize when it no longer has enough information?
• Can it recover the same person, object, or activity after the obstruction clears?
• What percentage of a typical case is not observable?

Ask the vendor to demonstrate this live, in conditions you choose: a crowded room, a person blocking a sensor, a repositioned boom, an activity moving between viewpoints. A video of the system working in an unobstructed room does not answer the question. The important question is never how much of the room appears in one image, but whether the system maintains a reliable understanding as people and equipment move.

2. What does the system actually measure?

A conventional camera produces a flat image. It can recognize visible objects and activities, but it may struggle to understand where things are, how they relate to one another, and what is happening when the scene becomes crowded.

A spatial system can use depth and multiple viewpoints to build a three-dimensional understanding of the room.

What the sensors measure sets a hard limit on what the system can ever do. A platform that only interprets flat images can improve its software forever and still never know where things are—and “where” is what scheduling, safety, and coordination decisions depend on.

Ask the vendor:

• What types of sensors does the system use (video cameras, depth sensors, or both), and what does each contribute?
• Is depth measured directly or estimated from ordinary 2D video?
• Does the system build a spatial model of the room?
• Is that model live during the case, or reconstructed after the fact?
• Can it determine where people, equipment, and activities are relative to one another?
• Can it distinguish objects that overlap in a 2D image?
• Can it measure motion and duration, or only presence?
• How does it perform under real OR lighting: dimmed rooms during laparoscopic cases, surgical spotlights, glare from drapes and instruments?
• How is spatial accuracy measured and maintained?

Be cautious when vendors use “3D,” “spatial,” and “room intelligence” interchangeably. Ask what the sensors actually measure.

3. Can the system understand meaningful workflows, or only basic milestones?

Many systems can detect whether a room is occupied or identify events such as wheels in, wheels out, draping, incision, or closing.

Those timestamps can be useful. But recognizing a few visible milestones is different from understanding a complex surgical workflow. Room-state timestamps tell you that time was lost; workflow understanding tells you where and why. The difference decides whether your team gets insight it can act on, or a report that restates the schedule.

Ask:

• Which events and procedural stages can the system recognize today?
• Can it distinguish anesthesia, preparation, surgical activity, closing, cleaning, and turnover?
• Does it support procedure-specific stages?
• Can it recognize activities involving instruments, trays, staff, or equipment?
• How does it handle stages that are skipped, repeated, delayed, or performed in an unexpected sequence?
• What happens when the system is uncertain?
• Which specialties have been validated?

Ask vendors to separate basic room-state detection from detailed procedural understanding. Then ask to see the system live on a workflow that differs from the expected sequence, a low-confidence event, and a scenario the vendor did not prepare in advance.

4. What useful action follows each detection?

Detecting an event does not automatically improve operating-room performance. Every detection that does not trigger an action becomes another screen someone has to remember to check. Adoption dies quietly this way: the system works, nothing changes, and a year later the ROI review has nothing to show.

For every proposed feature, ask:

• Who receives the information?
• What decision or action does it support?
• Does it eliminate a manual task?
• Does it trigger communication or coordination automatically?
• Does it update the surgical schedule?
• Does it generate documentation?
• Does it support inventory or tray decisions?
• Does it help teams anticipate what will happen next?
• How is the operational or clinical impact measured?

A Smart OR platform should connect sensing to action. Otherwise, it risks becoming another dashboard your staff must remember to check.

5. Can the system write information into the EHR?

An integration logo on a presentation does not necessarily mean that a system is integrated into clinical workflow.

Some platforms can read schedule data but cannot write information back. Others require staff to copy information manually from a separate dashboard.

This is where the return on the whole investment is decided. If the system’s output does not land in the EHR and the schedule (the places your teams already work), then every “automated” insight still costs a human copy-paste, and most will simply never be used. If you only have time to pressure-test one answer in a vendor meeting, make it this one.

Ask:

• Can you demonstrate, live, an event in the operating room appearing in the correct EHR record?
• Is the integration operating in production today?
• Is it read-only, or can the system write back?
• Does the integration use standard interfaces (HL7 v2 messaging, FHIR APIs) or a bespoke connection?
• Who maintains the interface when the EHR is upgraded, and what has that cost other customers?
• Which EHR records and fields can it update?
• Is the information structured or added as an attachment?
• Can generated documentation be reviewed and approved?
• If an automated timestamp conflicts with what the clinical team charted, which is the source of truth, and who has correction rights?
• What happens when the schedule changes or a case is added unexpectedly?
• Does the workflow require manual copying or reconciliation?
• What happens if the integration is unavailable?

The value of automation depends on whether its output reaches the place where your teams already work.

6. Which capabilities exist today, and which are on the roadmap?

Smart OR demonstrations can make generally available products, beta capabilities, custom projects, and future plans appear equally mature. You are signing a contract for what exists, but you are being sold what is planned. A long customer list is not evidence that a capability ships. Ask which of those customers actually use the specific feature you are buying.

For every capability, ask the vendor to label it as:

• Generally available
• Operating with selected customers
• In pilot or beta
• Dependent on a third-party product
• Requiring custom development
• Planned for the future

This is particularly important for capabilities such as:

• Detailed surgical-stage detection
• Operative-note generation
• Tray and instrument rationalization
• Training and case review
• Automatic surgical-count assistance
• Retained-object detection
• Predictive coordination
• EHR write-back

For each capability that matters to you, request a written answer, a technical explanation, a live demonstration, and a commitment in the contract or statement of work. If it cannot be demonstrated or described in the proposed contract, evaluate it as a roadmap item.

7. Can the installed architecture support future use cases?

You are not simply purchasing a feature. You are installing sensing and computing infrastructure inside some of your most valuable clinical spaces. The sensors you install this year decide which applications you can add for the rest of the decade.

The risk runs in both directions. Buying less sensing than your roadmap needs can mean paying twice for installation and room closures. Buying more than you will realistically use adds cost and data-governance burden without return. The question is whether the architecture matches the applications you actually plan to adopt.

Ask:

• Which future capabilities can use the same installed sensors?
• Will advanced applications require additional cameras or room closures?
• Can software capabilities be added without replacing the underlying architecture?
• Does the sensing system collect enough information for more sophisticated use cases?
• Can it support spatial relationships between staff, patients, equipment, instruments, and room activity?
• How does the architecture support applications that you may want three or five years from now?

8. What does installation actually require in your rooms?

Every hour an operating room is closed is measured in postponed cases and lost revenue. Vendors describe installation in a slide; you should ask for it as a work plan, because the gap between “cameras on the ceiling” and a working system runs through your facilities team, your infection-control requirements, and your surgical schedule.

Ask:

• How many hours or days is each room out of service, and can installation happen overnight or between cases?
• What physical work is involved: ceiling penetrations, mounting, cabling, power, network drops?
• How does the installation meet infection-control requirements and local building codes (firestop, seismic, electrical) in your jurisdiction?
• What does the system need from your network and IT team, and is processing on-premises, at the edge, or in the cloud?
• Does each room require calibration after installation, and again after equipment moves or renovations?
• How is a multi-room rollout phased so the schedule keeps running?
• Who performs the work: the vendor, a certified contractor, or your facilities team?

Ask for the installation plan in writing, including the downtime commitment per room. A vendor who has installed in working hospitals, rather than demonstration suites, will have one ready.

9. How are the outputs produced, and what leaves the room?

You should understand both the automation and the data flow behind every output. Your privacy office, your surgeons, and your staff representatives will all ask these questions eventually. It is far cheaper to ask them before the contract than to discover undisclosed human review or off-site video processing after deployment.

Ask:

• Which outputs are produced entirely by software?
• Is any human involved in watching, interpreting, labelling, or validating a live case?
• Is human involvement part of normal operation or only quality assurance?
• Is raw video or audio transmitted outside the room?
• Does identifiable information leave the hospital?
• Is processing performed locally, at the edge, or in the cloud?
• Is video retained?
• Who can access it?
• Can the system operate without recording identifiable video?
• Which functions continue if the external network connection is unavailable?

Ask for a simple data-flow diagram showing what is captured, where it is processed, what is retained, and who can access it.

Human oversight is not necessarily a problem. Undisclosed human involvement is.

10. How will your staff experience it, and who governs the data?

An operating room sensing system succeeds or fails on the trust of the people who work under it. Surgeons and nurses will want to know whether they are being watched, measured, and compared. Your counsel will want to know who owns the recordings and what happens to them in litigation. Your privacy and security teams will want evidence, not assurances. These conversations decide adoption, and they are far cheaper before the contract than after an incident.

Ask:

• Can the system operate without identifying individual staff members?
• Can its outputs be used to evaluate individual performance, and can that be disabled and contractually excluded?
• Who sees which numbers day to day, at what level of aggregation, and on what cadence? Room-level comparisons land on teams even when no individual is named.
• How were staff consulted when the system was introduced at other hospitals?
• Who owns the recordings and derived data, and what happens to them if the contract ends?
• What retention options exist, and can the system run without retaining identifiable video at all?
• How does retained footage interact with legal discovery, and does the vendor support your counsel’s review before deployment?
• Which security and privacy certifications does the vendor hold, and will they support your privacy impact assessment with a complete processing description?
• For patient-safety capabilities, what is the regulatory status? Is the function classified as a medical device, and where?
• Is your footage used to train the vendor’s models, and can you opt out in the contract?

One more step costs nothing and decides everything: put the people who will work under the system (your nurses and surgeons) in the demonstrations and on the evaluation committee, from the first meeting.

A vendor that has genuinely deployed in hospitals has heard every one of these questions before—and will answer them in writing.

A better way to compare Smart OR systems

The most important question is not how many features appear on a vendor’s slide.

You should determine:

• How much of the room the system can actually see, and what happens when its view is blocked
• What it can perceive and measure
• How much of the surgical workflow it can understand
• Whether its outputs create useful actions
• Whether information reaches the EHR
• Which capabilities genuinely exist today
• Whether the architecture can support what comes next
• What installation will cost you in room time
• Whether your staff, privacy office, and counsel can live with it

Vendors may use the same language to describe materially different technology. The only reliable comparison is to ask every vendor the same questions, test the same scenarios, and require the same standard of evidence from everyone: live, in the environment where the system will operate. That environment is a complex, crowded, constantly changing room, not a controlled demonstration.

See how VitVio answers these questions

VitVio is building operating-room intelligence around a 3D-native understanding of the surgical environment.

Our approach is designed to maintain spatial context across multiple viewpoints, operate in the presence of real-world occlusion, integrate information into existing hospital workflows, and provide a foundation for applications beyond basic room timestamps.

Ask us the same questions in this guide. More importantly, ask us to show you.

Explore VitVio’s Smart OR platform

Ask us to show you: request a technical demonstration