Where Anesloop plugs into your chart.

01 · Provation

Provation.

Direct DB read + file-based export

Provation is the documentation platform most GI rooms live in, and Anesloop reads from it case-by-case: the day list, the procedure indication, the endoscopist findings, and the post-procedure diagnosis codes. The read is direct and read-only against the Provation SQL backend your facility runs; nothing leaves the box until Anesloop pulls the clinical bundle it needs for the chart.

Anesloop does not write back into Provation. The screening output surfaces in the Anesloop pre-op queue against the case the endoscopist opened that morning, and the endoscopist continues to work in Provation exactly as before. Provation stays the chart of record for the procedure; Anesloop is the chart-side review pass before the case.

• Read: today's case list per room, with indication, scheduled procedure, endoscopist, and ASA class from the pre-op field.
• Read: post-procedure diagnosis codes and findings — written back to the chart as a structured note at the close of the case.
• Write: none direct. Screening holds surface in Anesloop, never in Provation, so the endoscopist's documentation surface stays clean.
• Transport: read-only SQL against your Provation instance inside your network; no public endpoint, no outbound from your environment to ours.

02 · HST (ASC practice management)

HST (ASC practice management).

HL7 v2 over MLLP

HST is the ASC-side practice management system that owns the schedule and the patient-master record at most mid-sized multi-specialty ASCs. Anesloop connects to HST over HL7 v2 ADT and ORM messages — the standard feed the rest of your perioperative stack already speaks, so the BAA stays single and your interface team does not have to wire a new protocol.

On the read side, Anesloop pulls the case schedule, the patient ADT stream, and the case-level pre-op fields HST already keeps (NPO status, allergies, prior anesthesia). On the write side, Anesloop pushes back the screening hold flag the morning huddle acts on, so the cleared vs. held decision is visible in the same HST schedule the front desk is reading at 0630.

• Read: SIU-style schedule messages and ADT (A01/A04/A08) so the morning case list and patient-master updates land before first cut.
• Read: ORM order segments carrying NPO status, allergies, and prior-anesthesia fields HST keeps on the case row.
• Write: a screening-hold flag attached to the case in HST, surfaced in the schedule grid your front desk and anesthesia team already read at 0630.
• Transport: HL7 v2 over MLLP, terminated inside your network; no HL7 traffic leaves the building unencrypted.

03 · SIS (Surgical Information Systems)

SIS (Surgical Information Systems).

HL7 v2 + direct DB read for utilization

SIS is the EHR-and-scheduling system most ASCs standardize on, and Anesloop treats it as the primary clinical surface for the OR. Anesloop reads SIS over HL7 v2 — ADT for the patient stream, SIU for the schedule — and supplements the HL7 feed with a direct read against the SIS scheduling tables for OR-block utilization, the same data the morning rebalance runs against.

Anesloop writes back two things into SIS. The first is the screening hold flag, attached to the case row so the bedside team sees the cleared vs. held decision before the patient walks back. The second, lands later in the day: the post-op charge capture (anesthesia time, modifiers, payer follow-up fields) so the RCM handoff the next morning is complete on day one, not at month-end.

• Read: ADT (A01/A04/A08) for patient flow + SIU (S12/S13/S14) for the day's OR-block schedule.
• Read: direct DB read against the SIS scheduling tables for OR-block utilization — the same data the morning rebalance runs against.
• Write: the screening-hold flag attached to the SIS case row, visible in the schedule view your team reads at 0630.
• Write: post-op charge capture (anesthesia time, modifiers, payer-follow-up fields) landed the same day as the case.

04 · Major EHRs (Epic, Modernizing Medicine)

Major EHRs (Epic, Modernizing Medicine).

HL7 FHIR R4 (SMART-on-FHIR + bulk export)

For the larger EHRs your surgeons and medical directors may carry on their credentialing (Epic at a hospital-affiliated ASC, Modernizing Medicine at a multi-specialty site that runs a specialty EHR), Anesloop connects over HL7 FHIR R4. The connection is SMART-on-FHIR for single-patient reads and FHIR Bulk Data Access for the population-level pulls the screening queue runs against.

Anesloop reads the chart bundle — problems, medications, allergies, recent labs, prior anesthesia notes — and writes a single flag back via FHIR (a chart-holder flag on the patient resource) so the screening decision lands where the rest of the chart is. Epic and Modernizing Medicine are the named examples the brief calls out; the FHIR R4 path covers the same surface for any EHR that speaks the same standard.

• Read: FHIR R4 patient bundle — problems, medications, allergies, recent labs, prior anesthesia notes.
• Read: FHIR Bulk Data Access for the population-level pulls the morning screening queue runs against (no per-patient polling).
• Write: a chart-holder flag on the FHIR Patient resource, so the cleared vs. held decision sits next to the rest of the chart.
• Transport: SMART-on-FHIR authorization handled within your identity provider; no shared credentials cross organizations.