An anesthesia-native opportunity map

The call

The best first wedge is an anesthesia-native perioperative flow layer: a thin operational layer that watches case state, recovery-unit capacity, nurse readiness, anesthesia handoff needs, and NORA demand, then routes the next useful action to the right person at the right time.

This should not start as a replacement for Epic, an anesthesia record, or a staffing marketplace. It should start as the missing control surface between Epic documentation, PACU reality, nursing work queues, and anesthesia coverage constraints.

The most concrete version is OR-to-PACU readiness and handoff orchestration. That is where the pain is frequent, measurable, and close to money. It is also where anesthesia sits in the middle of several overloaded systems but rarely owns the software layer.

Why this is probably real

Anesthesiology has become a capacity specialty, not only an intraoperative specialty. The job still includes airway, physiology, analgesia, crisis response, and pharmacology, but the operational leverage now sits across handoffs, staffing, room turnover, PACU capacity, NORA expansion, and perioperative risk selection.

The system pressure is visible in public data. ASA reported that facilities describing an anesthesia staffing shortage rose from 35% in early 2020 to 78% in late 2022, and framed the shortage as a threat to health care delivery.ASA workforce shortage ASA also reported high burnout risk among anesthesiologists in a 2022 survey, with burnout risk up materially from 2020.ASA burnout release

At the same time, the perioperative workflow is fragmented. Epic says OpTime and Anesthesia cover pre-, intra-, and post-procedure surgical workflows in one perioperative record.Epic specialties: Surgery and Anesthesia That is necessary infrastructure, but it does not mean the real-time coordination problem is solved. The lived gap is usually not “can someone document the case?” It is “does the next team know exactly what is coming, when, with what risk, and what action is needed?”

The handoff literature supports that distinction. A postoperative handoff review found that postoperative patient handovers are vulnerable to technical and communication errors, with possible patient-safety impact.Systematic review on postoperative handovers A PACU handoff study describes OR-to-PACU transfer as a susceptible moment for information loss and time spent clarifying information.PubMed: Handoffs in the PACU Another QI project found that a standardized anesthesia handoff report increased report completion for PACU transfers from 79% to 99%.Time-out and standardized report form

The non-obvious point: the durable product is not the checklist. It is the live state machine around the checklist.

A checklist improves a single transfer. A state machine changes the queue: who gets alerted, when the alert is useful, which bed or nurse is likely to be ready, which patient needs a higher-fidelity handoff, which case creates downstream risk, and when the system should escalate before a delay becomes visible.

What this is not

It is not “Slack for the OR.” Messaging alone becomes one more place to miss something.

It is not a dashboard. Dashboards make managers feel informed after the fact. This wedge needs to reduce phone calls, ambiguity, and avoidable waiting while the day is still moving.

It is not an AI scribe for anesthesia. Documentation is crowded, regulated, and already adjacent to Epic Anesthesia. The better opening is operational routing from existing state.

It is not an “Uber for anesthesiologists” as the first wedge. Staffing is a real pain, but a marketplace runs into credentialing, payer/provider contracting, local group politics, coverage liability, call rules, CRNA/MD supervision models, and hospital procurement. A staffing product can come later if the system first knows demand, acuity, and coverage gaps better than the staffing agencies do.

The opportunity map

1. OR-to-PACU readiness and handoff orchestration

Pain. Anesthesia finishes a case, PACU and floor nursing readiness are uncertain, handoff depends on phone calls or local ritual, and missing context creates rework. The literature already supports OR-to-PACU transfer as a vulnerable handoff with information loss and clarification burden.PubMed: PACU handoffs

User. Attending anesthesiologist, CRNA/resident, PACU charge nurse, PACU bedside nurse, perioperative nursing leadership, and OR control desk.

Buyer. Perioperative services, anesthesia department, hospital operations, ASC leadership if the workflow is simplified enough.

MVP. A case-status timeline that predicts “ready for PACU soon,” shows PACU queue/readiness, prepares an anesthesia-to-PACU handoff bundle, alerts the right nurse/charge role, and escalates only if acknowledgement fails. It should start with Epic schedule/state, anesthesia record status, PACU bed/nurse assignment, and manually confirmed local signals.

Why now. Staffing pressure makes wasted clinician minutes more expensive. PACU and OR flow problems have measurable operational cost. Handoff standardization has evidence, but most hospitals still implement it as policy or training rather than a live coordination layer.

Risk. Alert fatigue. If the product sends generic pings, clinicians will hate it. The key design rule is “fewer alerts than today, but better timed.”

Verdict. Best first wedge.

2. PACU bottleneck predictor

Pain. PACU is a downstream constraint on OR throughput. When recovery beds or nurses are unavailable, the OR can become an expensive holding area. This shows up as case delay, turnover disruption, and staff frustration.

User. OR board runner, PACU charge nurse, anesthesia floor runner, perioperative operations.

Buyer. Hospital operations and perioperative services.

MVP. A two-hour forecast of PACU load by phase, nurse ratio, bed availability, expected extubation/recovery profile, and discharge-blocking reasons. Output should be operational: “Case 4 in OR 7 is likely to create a PACU conflict; call backup nurse now or route to alternate recovery plan.”

Evidence anchor. PACU capacity and discharge delay are active operational topics in perioperative literature and health-system operations. Treat commercial “PACU bottleneck” claims cautiously, but the queueing structure is real: every OR feeds a finite recovery resource.

Risk. Data quality. PACU discharge readiness is often partly clinical and partly social: bed availability, transport, floor nurse availability, pain, nausea, airway, hemodynamics, and local policy.

Verdict. Strong second wedge; could merge into wedge 1 after discovery.

3. NORA demand and risk router

Pain. Non-operating-room anesthesia is growing because procedures moved into GI, cath, EP, IR, imaging, and other procedural areas. ASA defines NORA as anesthesia care outside the traditional OR suite and states that OR safety practices should be replicated in NORA locations.ASA NORA statement The AHA/ASA knowledge-exchange material frames NORA growth as a workforce and operations challenge.AHA/ASA NORA knowledge exchange

User. Anesthesia scheduler, procedural service line, pre-op clinic, NORA attending, charge anesthesiologist.

Buyer. Procedural services, anesthesia department, health-system operations.

MVP. A triage layer for NORA requests: patient risk, required monitoring, staffing model, location readiness, equipment readiness, and whether moderate sedation is more appropriate. It should create a shared queue rather than letting each procedural area negotiate separately.

Risk. This gets politically sensitive. Proceduralists want access; anesthesia owns safety; hospitals want throughput. The product must make resource constraints explicit without sounding like anesthesia is blocking growth.

Verdict. Non-obvious and potentially large. Better as follow-on unless Jag already has access to a NORA-heavy site.

4. Anesthesia coverage graph

Pain. Staffing shortages make coverage fragile. Locums and per-diem coverage are symptoms, not the whole disease. The unanswered local question is: which rooms, procedural areas, and call obligations are at risk tomorrow and why?

User. Anesthesia group scheduler, chief, medical director, ASC administrator.

Buyer. Anesthesia group or facility.

MVP. A credentialed coverage map with cases, rooms, NORA locations, supervision ratios, call, requested leave, acuity, and known bottlenecks. It does not match labor first. It shows demand and risk first.

Risk. This is close to workforce politics and compensation. A startup can get pulled into brokerage too early.

Verdict. Strong later wedge. It becomes much more powerful if the product already sees perioperative demand in real time.

5. Anesthesia handoff data layer for quality and billing adjacency

Pain. Handoffs, postoperative complications, PACU events, and documentation gaps create quality and administrative burden. Epic stores much of the record, but local quality work often lives in audits, manual reviews, and disconnected dashboards.

User. Quality lead, anesthesia operations, clinical informatics, residency/QI faculty.

Buyer. Department, hospital quality, perioperative leadership.

MVP. A structured handoff and PACU event layer that turns the handoff into machine-readable quality data. The product can report omissions, escalation patterns, delayed discharge reasons, and near-miss classes.

Evidence anchor. Checklist and standardized handoff interventions show measurable improvement in handoff completeness.Time-out report form The startup question is whether that can become operational software rather than another QI poster.

Risk. Quality-only products often die in committee because the buyer has low urgency. Tie it to throughput and staffing first.

Verdict. Useful data exhaust, not the first product.

6. “Epic modular like Salesforce” app layer

Pain. Clinicians want small workflow tools that fit the day. Hospitals buy and configure enterprise EHR modules. Those incentives do not match.

User. Anesthesia and perioperative teams with local workflow pain.

Buyer. Health-system IT plus perioperative operations.

MVP. Not an app store. Start with one deployable Epic-adjacent workflow module: OR-to-PACU readiness. Prove that a small module can sit beside Epic, reduce phone calls, and maintain auditability. Then generalize.

Evidence anchor. Epic’s own public language presents OpTime and Anesthesia as broad perioperative record systems, not as a configurable specialty operations marketplace.Epic specialties

Risk. Integration and procurement. “Epic app layer” is a strategy, not an MVP.

Verdict. Correct long-term mental model; dangerous first pitch if it sounds like boiling the ocean.

Best first product concept

Call it Flow Anesthesia for now.

The product sits beside Epic OpTime/Anesthesia and listens to perioperative state. It does not ask clinicians to duplicate documentation. It gives each role a small action surface:

For anesthesia: next case state, PACU readiness, handoff bundle, blocked transfers, escalation log.
For PACU charge: expected arrivals, acuity flags, nurse/bed readiness, cases that need special preparation.
For PACU bedside nurse: “patient incoming” context that is shorter than a chart review and more reliable than a phone tag summary.
For OR board runner: likely recovery conflicts before they become OR holds.
For leadership: delay reasons, handoff completion, missed acknowledgement, and capacity patterns.

The first version should be boringly operational. No grand AI. No clinical decision-making. No autonomous orders. No replacement of the anesthesia record. The product earns trust by removing dumb uncertainty.

The wedge metric

Pick one primary metric: avoidable minutes between “case is functionally ready to leave OR” and “PACU is ready and has accepted the handoff.”

Secondary metrics:

failed or delayed acknowledgement;
time from emergence signal to PACU notification;
handoff completeness;
PACU bed/nurse mismatch events;
OR hold minutes attributable to recovery capacity;
number of phone calls or pages per transfer.

This matters because a clinician will not believe “AI optimization” until the product proves it understands the boring queue.

Why this could impress a skeptical anesthesiologist

The pitch is not “we found a big market.” The pitch is: anesthesia sees the whole perioperative system, but the software treats anesthesia as a documentation role.

That is the asymmetry. Surgeons own demand. Nursing owns much of the unit work. Hospital operations owns throughput. Epic owns the record. Anesthesia often becomes the human coordination layer across all of it. A good product makes that implicit coordination visible, safer, and less annoying.

The non-obvious version is a perioperative state compiler:

compile weak signals from schedule, anesthesia record, OR status, nursing assignment, PACU load, NORA request, and local acknowledgement;
infer the next likely bottleneck;
route one action to one accountable role;
record whether that action changed flow;
learn the local exceptions without pretending the model is practicing medicine.

That is closer to air-traffic control than a dashboard.

Questions to test with Jag

In the last week, where did you personally lose time because another team did not know case state?
How does PACU know a patient is coming now: phone, Epic status, charge nurse, runner, text, habit?
Who owns the moment when a patient is ready to leave the OR but PACU is not ready?
What information does PACU actually need before arrival, and what information is noise?
Which delay reasons are documented today, and which are known only socially?
Where does NORA scheduling break first: patient selection, staffing, location readiness, equipment, proceduralist expectations, or recovery planning?
If a tool cut two calls per case but required one more click, would anyone use it?
What would make an anesthesiologist distrust this product immediately?

What would change the recommendation

If Jag says the real daily pain is not PACU/readiness/handoff but credentialing, case assignment, locums, supervision ratios, or NORA patient selection, the first wedge should move.

If the hospital already has a strong OR command center with reliable real-time status and nurse acknowledgement, the product needs to specialize deeper into anesthesia handoff quality or NORA triage.

If Epic integration is impossible at the first site, the MVP should start as a lightweight command-board plus manual acknowledgement tool. That is less elegant, but it may be enough to learn the workflow.

If clinicians describe the problem as “too many alerts,” not “missing the right alert,” then the first product must be an alert suppressor and escalation router, not a notification layer.

Follow-up reports to build next

1. Customer/investor memo. Convert this into a sharper external memo: buyer, market, wedge, competition, adoption path, pilot design, and business model.

2. Founder-fit report. Separate document on whether this is a good founder path for Jag specifically. Keep it honest. Include clinical credibility, product instincts, network, missing gaps, and likely co-founder needs.

3. Padawan/Hareesh-fit report. Separate document on how this project could use Padawan-style research, source graphs, prototype loops, and clinician interview synthesis without making the main handoff self-referential.

4. Competitor landscape. Map Qventus, Apella, Caresyntax, LeanTaaS, Epic-native builds, anesthesia staffing firms, and perioperative command centers. The key question is not “who exists?” It is “which layer do they own, and where is anesthesia still underserved?”

5. Interview script and evidence graph. Build a clinician interview protocol for five anesthesiologists, three PACU nurses, two OR charge nurses, one perioperative ops leader, and one Epic OpTime/Anesthesia analyst. Output should classify pain by frequency, severity, buyer, workflow owner, and integration path.