Surgical Stage Tracking, Case Estimates, and Notifications
Vetro detects the stages of a surgical case as they happen: wheels-in, induction, knife-to-skin, wound closure, room ready. Each event carries a timestamp and a confidence level, so the case timeline reflects what was observed rather than what someone remembered to type. Once trained, no one in the room logs anything.
Those events do more than record the case. They drive live estimates of when each case will finish, and they trigger notifications to the teams whose next step depends on it. Detection, estimation, and coordination run as one chain rather than three separate tools.
Stage tracking is one capability on a broader platform. Vetro is a 3D-native, context-aware operating-room intelligence platform, designed as an extra pair of hands for perioperative teams.
Why manual milestone capture makes the day unpredictable
Surgical milestones are usually captured by hand. A circulating nurse pauses mid-case to enter a timestamp, some events are logged late, some are reconstructed afterwards, and some are never captured at all. The result is a case record built on interruption and recall, where timestamps drift and phase durations cannot be relied on.
That noise compounds. If the timeline is approximate, so is every estimate built on it, which means nobody can say with confidence when a case will finish. Coordination then falls back on phone calls and walking the floor: pre-op asks whether to send the next patient, turnover teams wait for word that the room is free, and schedulers work from a plan that stopped matching reality hours ago.
The systems downstream inherit it too. Timestamps entered by hand are the same records that feed the EHR, the schedule board, utilization reporting, and any registry or billing process that depends on when things happened. A case record that drifted by ten minutes does not announce itself; it simply becomes the number everyone plans and reports against.
The people who feel it are the ones holding the day together. Perioperative directors plan from data they know is soft, OR managers field status requests they cannot answer precisely, and informatics leaders inherit a case record that will not support utilization analysis.
How automated stage tracking works
Stage detection runs continuously through the case. After a short training period, nothing in the sequence asks anyone in the room to stop and enter data, and every event it produces remains reviewable by the team. During that period the team confirms events as they happen, which is how Vetro learns the workflow of each specific room and service.
- Observe. Overlapping coverage keeps the room observable even when any single view is blocked, so stage transitions are seen rather than inferred.
- Detect. The Spatial Context Engine recognizes stage transitions in real time: wheels-in, induction, knife-to-skin, key intraoperative milestones, wound closure, patient out, cleaning and preparation during turnover, and room ready. In research terms this is surgical phase detection, done ambiently.
- Record. Every event carries a timestamp and a confidence level, and writes back to the EHR so the case record is built from what was observed. Events are also available to the schedule board and to utilization reporting, which is where the drift described above usually shows up.
Detection is the foundation the rest of this page rests on. Because the events are observed rather than recalled, the estimates and notifications built on them start from a reliable timeline rather than an approximate one.
How case completion estimates work
Once stages are detected reliably, the same events support a live estimate of when each case will finish. The estimate updates through the case rather than being set once at the start, so the schedule reflects how the day is actually running.
- Built from the current case, not an average. The estimate is grounded in the stages already observed in this room today, and adjusted for the team in the room, the case type, and case details read from the EHR. It responds to what is happening rather than to a historical mean for the procedure.
- The team teaches it first. During the training period, the team confirms remaining duration once or twice per case, typically when something significant changes. Those confirmations are how Vetro learns each service's pace, and the system takes over the estimate as it becomes reliable.
- Updated as the case progresses. Each detected stage refines the estimate, so a case that runs long is visible while there is still time to act rather than after the overrun.
- Flagged when a phase runs long. Where a phase exceeds what the case pattern suggests, the estimate changes and the delay is surfaced rather than left for someone to notice.
An estimate is only as good as the events behind it, which is why detection comes first. Where confidence is low, the estimate is presented as uncertain rather than as a firm time.
How stage events trigger notifications
A detected stage is only useful if it reaches the person whose next step depends on it. Vetro sends updates automatically as the case progresses, so teams stop calling the room to ask what is happening.
- Triggered by the case, not by a person. Notifications fire from detected stages and updated estimates, so nobody has to remember to make the call or send the page.
- Timed to give teams a head start. Because the estimate updates through the case, an update can arrive with time to act on it: send the next patient to OR 4 in ten minutes, or bring the turnover team up now. Teams get lead time rather than a status report after the fact.
- Sent to the team whose next step it affects. As a case approaches closing, turnover and the next patient's team can prepare. When a room is ready, the people who move the patient know without being told twice.
- Delivered where teams already work. Updates route into the communication tools the hospital already uses rather than adding another app to check.
Which updates go to which teams, and through which channels, is configured with the hospital during activation. Perioperative workflow automation covers the wider coordination picture, including how the schedule adjusts as the day changes.
What changes for each perioperative role
The three capabilities on this page change different things for different people. What they share is that nobody has to ask for information the system already has.
- Circulating nurses: Milestone logging stops being a mid-case typing task, and after training the case record builds itself.
- Surgeons: Fewer interruptions asking for status, and a case record that matches what actually happened in the room.
- OR managers: Live phase status for every room and honest phase-duration data across cases, rather than numbers assembled after the fact.
- Schedulers and coordinators: Every case is logged in the same form with the same events, so the scheduling systems they already rely on work from observed durations rather than timestamps entered after the fact. Over time that makes block planning more accurate too, because the history behind it is real.
- Turnover and cleaning teams: Notice that a case is approaching closing, so preparation starts before the room is empty rather than after someone makes a call.
- Pre-op teams: A clearer signal of when to send the next patient, so patients arrive on time rather than early and waiting.
- Quality and informatics: Consistent, observation-based timelines that make utilization and turnover analysis meaningful.
None of this changes who is accountable for the case. It changes how much of the day is spent finding out what is happening.
Trust, control, and how teams stay in charge
Vetro is designed so that understanding the surgical process never means monitoring the people carrying it out, and so that the team can always overrule what it records.
- The team can always step in. Where staff disagree with a detected stage, an estimate, or a recorded timing, they can correct it, and the correction is what stands. Vetro's record is a starting point the team can change at any time.
- Operational context, not clinical judgment. Stage detection describes what happened and when. Clinical decisions and established safety processes stay with the care team.
- Uncertainty is shown, not hidden. Where confidence is low, the event or estimate is flagged for review rather than recorded as fact, and every event and correction is auditable.
- Vetro tracks the process, not people. It is designed to understand surgical workflow and operational events. Vetro does not track individual performance metrics of any sort, and no one is scored, ranked, or compared.
- Identifiable video is never stored. Recognizable detail is removed automatically as the case is observed, and the original footage is deleted immediately, with no way to recover it. Processing happens on servers inside the hospital.
- Short retention by default. A small amount of data, the segments around logged event timestamps, is kept fully anonymized to improve the models. Everything else is deleted on the schedule agreed with the hospital, seven days by default.
Each of these is confirmed with the hospital during activation rather than assumed, including retention periods, who can see what, and which events are recorded at all. Hospitals set those terms, and Vetro operates inside them. The system is built to give perioperative teams a more accurate picture of the case without changing who runs the room or who is accountable for what happens in it.
Frequently asked questions about stage tracking and case estimates
Which stages does Vetro detect?
Case-level milestones: wheels-in, induction, knife-to-skin, key intraoperative milestones, wound closure, patient out, cleaning and preparation during turnover, and room ready. The set in scope for a given hospital is agreed during deployment.
How is accuracy validated?
Validation happens per site rather than as a single global figure, because detection accuracy varies by event type, room layout, and procedure mix. During the training period, the events Vetro detects are compared against the events the team confirms in the OR Console, and that comparison establishes whether a given event type is reliable in that room. Vetro moves from training to augmentation to automation as that evidence accumulates, with clinical oversight maintained throughout, and events stay flagged for review where confidence is low.
What happens if the system misses an event?
Events carry confidence levels, and uncertain or missed events are flagged for review rather than written as fact. The team can add or correct any event, and the correction is what stands.
What if the team disagrees with what Vetro recorded?
They correct it, and the correction stands. Detected events, estimates, and timings can all be reviewed and changed by the team, and every change is auditable. Vetro also learns from those corrections, so the record improves with use.
Do staff need to confirm each stage?
Not once the system is trained. During the training period the team confirms events and remaining duration, typically once or twice per case, which is how Vetro learns the workflow. After that, capture is ambient and nothing requires an extra step in the room.
How accurate are the case completion estimates?
Accuracy improves as the system learns each service's pace, in the same way detection does. The estimate is built from the stages observed in that room today, adjusted for the team, the case type, and case details read from the EHR, and it updates as the case progresses. Where confidence is low it is presented as uncertain rather than as a firm time, so teams can see when an estimate should not be relied on.
Does Vetro measure individual staff performance?
No. Vetro does not track individual performance metrics of any sort. No one is scored, ranked, or compared.
Which teams receive notifications, and how?
Updates route into the communication tools the hospital already uses. Which events go to which teams is configured with the hospital during activation.
Does this work across procedure types?
Yes. Vetro tracks the operational structure of a case, which generalizes across specialties. The specialties in scope are agreed with the hospital during deployment, and we raise any challenges we anticipate for a specific specialty as part of that process.
