Epic Anesthesia

What is Epic Anesthesia?

Epic Anesthesia is the Epic module for the anesthesia side of perioperative care: the pre-anesthesia assessment, the intraoperative record fed by monitors and anesthesia machines, and the handoff to recovery. It shares each surgical case with OpTime, so outside systems must respect both.

For a vendor, the useful view of the module is not its screens but its edges. The questions that shape a project are which data the module accepts from outside, which data it publishes, and who at the hospital owns each of those connections.

Anesthesia documentation also feeds professional billing, so an outside system that touches case times or staffing needs the same care as one that touches vital signs.

Where does the module fit in a surgical case?

Epic Anesthesia covers the anesthesia clinician's part of the case, while OpTime runs the surgical log, the case schedule and supply use. Both write to the same case, so an outside system has to know which application owns each piece of data before it sends anything.

• Before the procedure: The anesthesia assessment, airway history and plan, with decision support that each health system configures for its own pre-surgery rules.
• Room and staff assignment: Anesthesia clinicians are assigned to rooms and cases, and a case can change hands during the day as rooms open and close.
• During the procedure: A time-based record of medications, fluids, events and vital signs, with monitor values filed through the device interface.
• After the procedure: The handoff to recovery and, at some sites, to an acute pain team that follows the patient onto the ward.
• Specialty workflows: Obstetric anesthesia, airway procedures and regional blocks can each have their own documentation path in the local build.

Much of this is local build. Event lists, medication shortcuts, decision support rules and handoff formats are configured by each health system's own Epic analysts, so two Epic hospitals can present the intraoperative record quite differently.

How do monitors and pumps reach the anesthesia record?

Physiologic monitors and anesthesia machines usually reach Epic through a device aggregator, a middleware layer that collects readings and sends them over HL7 v2 to Epic's Incoming Device Data interface. The hospital builds its side of that interface in Bridges, Epic's interface module, and the vendor builds the sending side.

open.epic points out a setting that matters most in the operating room. Device readings normally wait for a user to validate them, but for surgical procedures the interface can be configured to validate and file on its own. The same page states that the interface is not used for consumer-initiated or home monitoring.

Automatic filing moves responsibility upstream. When values file without a click, patient association, timestamps and units must be right before the message leaves the middleware, and the clinician needs a quick way to mark a bad value after the fact.

• Device association: Decide whether Epic or the middleware owns the link between a monitor and a patient, and make the other side follow it.
• Sampling: Agree the interval at which values file to the record. Monitors measure far more often than a chart needs, so the middleware should send the agreed interval and keep the rest.
• Waveforms: Keep waveforms in the device system or a dedicated viewer, and file only discrete values to the record.
• Infusion pumps: Pump integrations usually run as a pair, with order details going out to the pump gateway and documentation coming back against that order. Confirm what the customer has licensed and built before scoping it.
• Events: Ventilator mode changes, alarms silenced and pump rate changes are events, not readings. Decide with the department which events belong in the record and send them on their own message type.

Which integration path fits which product?

The right path follows the direction and timing of the data. Streams of readings take HL7 v2, occasional reads and writes take FHIR, and a tool the clinician opens during the case takes a SMART on FHIR launch where the health system enables one.

• Monitor or anesthesia machine middleware: HL7 v2 to Incoming Device Data, with one agreed owner for device association. Plan for automatic validation in the room.
• Infusion pump gateway: An order and documentation pair over HL7 v2, so pump programming starts from the Epic order and readings come back against it.
• Room tracking or case board: The surgical case scheduling feed out of Epic and the case tracking feed back in, covered in the next section.
• Perioperative analytics or quality dashboard: FHIR reads for current case data, plus a reporting extract from the health system for history. Expect gaps in what live APIs return.
• Clinician app used during the case: A SMART on FHIR launch from inside the Epic session with the patient in context, once the organization approves and configures the app.
• Medication system that acts outside Epic: An HL7 v2 feed that files administrations back to Epic, agreed with the pharmacy and anesthesia teams so doses are not charted twice.

One product can need several of these. A monitoring vendor with a supervision view needs the device feed for charting and a separate read path for the view, each with its own review at the health system.

How do case schedules and case events move?

Case schedules leave Epic on an HL7 v2 scheduling feed, and case events come back on a tracking feed. open.epic describes Outgoing Surgical Case Scheduling, which sends new, rescheduled, updated and canceled cases, and Incoming Surgical Case Tracking, which files case events and their timestamps to the surgical case log in real time.

A case board or staffing tool usually needs both: the schedule says which cases exist, and the tracking feed reports what happened.

• Treat every message as a change: A rescheduled case can move room, date and staff in one message. Apply the whole update, not only the field you expected to change.
• Handle cancellation first: A canceled case should release its room, devices and staff in the vendor system at once, before any other work on that message.
• Use Epic's case identifier: Key every record on the case identifier Epic sends, never on room and time, because two cases can share a room and a start time on paper.
• Send events once: The tracking feed should send each event a single time with its true time. Resending on retry without a check files the same event twice.

Test with a full day of cases, including add-ons and late cancellations.

What can a FHIR app read about a surgical case?

An outside FHIR client can see the scheduled and performed surgery and some of the charted data around it, but not every detail of the anesthesia record. open.epic lists R4 read and search for Appointment (Scheduled Surgeries) and Procedure (Surgeries), and read, search and create for Observation (Flowsheets).

Writing is narrower than reading. A flowsheet observation can be created through FHIR, but filing it against a customer's anesthesia rows depends on that customer's row mapping and approval, which means a mapping session with every new hospital.

Coverage also varies by build. Some anesthesia data, such as intraoperative medication detail, may not come back through the APIs a customer has enabled, and an HL7 v2 feed or a reporting extract may be the only way to get it. Confirm each data element in the customer's test environment before promising a feature that depends on it.

Plan reads around change. Clinicians correct values and times after the case, so an app that copies data should re-read it once the case is closed.

Where Epic Anesthesia integrations break

Most breaks happen where device data, patient identity and case timing meet.

• Auto-filed artifacts: Readings validate on their own in the room, so a transducer opened to air or a probe off the finger reaches the record unless the clinician corrects it.
• Binding that ignores Epic: The middleware links monitors to patients by bed or room on its own terms and disagrees with the association Epic holds.
• Silent filing stop: Automatic filing stops and nobody notices until the record shows a gap. Interface errors need alerts to the integration team, not only a log entry.
• Room-to-recovery gap: The patient moves to recovery but the monitor link stays with the operating room, so recovery readings file nowhere or to the wrong case.
• Assumed API coverage: A feature is designed around anesthesia data that the customer's build does not return.
• Unsynced clocks: Device and middleware time differs from Epic's, and medication events sit next to the wrong vital signs.
• Canceled cases left open: A cancellation arrives from the case scheduling feed, but the vendor's system keeps the room and devices assigned.

What should a vendor settle before the first live case?

A vendor should settle the data list, the validation model, device linking, ownership, downtime, testing and monitoring with the hospital before go-live. Each item below is cheaper to agree in a meeting than to fix during a case.

• 1. Data list: Every value, its unit, its sampling interval and the flowsheet row that receives it at this customer, kept in configuration rather than code.
• 2. Validation model: Whether the customer turns on automatic validation for surgical procedures, and how clinicians mark and correct artifacts.
• 3. Device linking: Who starts and ends each device-to-patient link, and what happens to it when the patient leaves for recovery.
• 4. Interface owners: The Bridges analyst on the hospital side and the engineer on the vendor side for each HL7 v2 feed.
• 5. Downtime: What the middleware holds during an Epic or network outage and how it replays without filing values twice.
• 6. Simulated cases: Test runs with the customer's own monitor models, including a cancellation, a room change and a device swap partway through a case.
• 7. Monitoring: Alerts for rejected messages and for a silent stop in filing, with a named person who acts on them.

How Agnotic can help

Perioperative products reach Epic through several interfaces at once, and each one has an owner at the hospital. Agnotic Technologies builds the vendor side for the client: middleware feeds to Incoming Device Data, infusion order and documentation interfaces, surgical case schedule and event integrations, and FHIR or SMART on FHIR apps that read the case.

Agnotic also builds the per-customer mapping layer, so flowsheet rows, units and validation choices live in configuration, with HIPAA Security Rule safeguards and message monitoring built in.

Sources

• open.epic: HL7 v2 clinical interfaces, including Incoming Device Data
• open.epic: Scheduling interfaces, including Outgoing Surgical Case Scheduling and Incoming Surgical Case Tracking
• open.epic: FHIR interfaces, including Appointment (Scheduled Surgeries), Procedure (Surgeries) and Observation (Flowsheets)