Ambulatory Surgery Center Software: Fixing Block Time, Implants, and the Billing Gaps HST and SIS Leave Behind

Why surgery center software makes or breaks a high volume ASC operator

An ASC sells one thing: prime time minutes converted into facility fees. Everything else is overhead on that conversion. At four centers doing 12,000 cases a year, a 4 hour ortho block that sits empty on a Tuesday is three cases you never recover, and nobody gets a report about it until the month end board packet, by which point the block has been empty for six Tuesdays.

The stack running that machine is predictable. HST Pathways or SIS Complete for scheduling and the chart. Provation for GI op notes, or ModMed gGastro if you went that route. Casetabs so surgeon offices can post cases without calling. Surgical Notes or an outsourced biller downstream. Waystar or Availity for eligibility and claims. QGenda or a laminated grid for anesthesia coverage. Vendormate or SEC3URE gating the reps at the door. GHX moving some of your bill-only POs, and paper moving the rest. And then the actual system of record: a shared Excel workbook the business office manager rebuilds every Friday, a Smartsheet the regional director keeps, and a group text with 14 surgeon schedulers in it.

The scene that decides your Tuesday: 6:52am, and the 7:30 total knee is a bill-only case. The Stryker rep is in the lot with a tray, but the implant sizes on the preference card are two revisions old because the surgeon changed his femoral component in March and told the scrub tech, not the system. The charge nurse texts the rep. The rep drives back. First case starts at 8:14. That 44 minutes cascades: the 9:15 goes at 10:05, the surgeon's last case gets bumped to another day, and the 2:00 to 3:00 prime time hour is dead. Nobody logs the root cause anywhere a query can find it. In three weeks the same thing happens with the same surgeon, and your only evidence is a nurse remembering.

Block time that looks full on the grid and runs empty in the room

Every ASC has a block policy. Release at 14 days, utilization threshold at 75%, prime time defined as 7:00 to 15:00. Almost nobody enforces it, because enforcing it requires a number the incumbent tools will not give you cleanly. HST and SIS will report block utilization, but they report it the way the vendor defined it, typically scheduled minutes against allocated minutes. That is the wrong number. Scheduled minutes are a promise. What you need is in-room minutes against allocated prime time minutes, netted of turnover you caused versus turnover the surgeon caused, with abandoned block credited back to whoever abandoned it.

The off-the-shelf tools cannot fix this because the definition of utilization is not configurable down to the level a real block committee argues about, and because the release decision lives in a human conversation. Your scheduler knows Dr. Patel never fills his Thursday second half but will scream if you take it. So nothing moves.

A custom layer reads case data out of HST or SIS on a nightly HL7 feed or an API pull, recomputes utilization on your definitions, and does three things the vendor will not. It runs a release engine: at day 14, unfilled prime time is automatically offered to a ranked waitlist of surgeons who have historically filled that day and specialty, by text, first accept wins, with an audit trail the block committee can read. It produces a per surgeon scorecard with utilization, on time first case percentage, turnover contribution, and case mix contribution margin on one page, which turns a political conversation into an arithmetic one. And it forecasts: given the last 24 months of posting behavior for this surgeon, this day, this season, the model predicts fill probability at day 21, so you release before the block goes cold instead of after. Fill probability comes from a model trained on your own posting history. It is a scoring job, not a chatbot.

The bill-only implant black hole

On a $9,200 contracted ortho case, a $4,800 implant is not a supply line. It is the margin. Bill-only implants arrive with the rep, get documented on a paper sheet or a photo of the box labels, get keyed into a PO days later, and get invoiced by the vendor at a price that may or may not match your contract. Meanwhile the payer requires the invoice to pay the carve-out, and your biller cannot find it.

The incumbent tools handle the parts they own and drop the seam. HST and SIS track inventory items you stocked. They do not natively reconcile a rep delivered implant against a contract price, a PO, a vendor invoice, and a payer carve-out claim line, because that chain crosses four systems and two companies. So a nurse photographs labels, someone types them, and nobody reconciles the chain end to end. Variances survive because there is no place they could be caught.

The custom build closes the loop. Scan the UDI barcode at the point of use on an iPad in the room, which captures device identifier, lot, and expiration in one action and writes it to the case record and the implant log the same second. Match the captured DI against your contract price file, and flag any implant used that is not on contract before the case is closed. Then use document extraction on the vendor invoice PDF that lands in the AP inbox, whether it comes from Stryker, Zimmer Biomet or Arthrex: pull line items, DI, quantity, price, match against the scanned usage, and route only the exceptions to a human. Extraction is load bearing here because those invoices are unstructured, every vendor formats them differently, and rules based parsers break constantly. Finally, auto attach the matched invoice to the claim so the carve-out gets paid the first time instead of on the second appeal. Run your own arithmetic before you sign anything: take last year's implant spend, take a 2% price variance against it, and put that next to a $60k first release.

Staffing the schedule you actually have, not the one you posted

Your OR schedule and your staffing plan are built in different tools by different people on different days. Scheduling lives in HST or SIS. Anesthesia coverage lives in QGenda or a spreadsheet. Nurse and tech shifts live in UKG or a paper grid the DON keeps. When two cases get added Friday afternoon to a Monday that was already tight, nothing recomputes. You find out at 6:45 Monday that you are one scrub tech short for room 3.

No off-the-shelf ASC product solves this because it requires the case schedule, the credential matrix, the anesthesia group's own roster, and your labor rules to be in one model. The vendors do not own three of those four.

What a custom build does: maintain a live coverage model that ingests the case schedule and, for every posted case, resolves the required staff by specialty and procedure, checks who is credentialed and current for that case type, and flags gaps the moment a case is posted, not the morning of. Add per case labor cost so the ops director can see that the 4:30 add-on case triggers 2.5 hours of overtime across four people and generates $600 of contribution. That is a decision, not a surprise. Route the gap to a ranked internal float list by text before it goes to an agency at 1.8x.

Billing that dies in the gap between the case and the claim

The case ends. The chart closes. Then a coder pulls the op note out of Provation, reconciles it against the posted CPT, applies multiple procedure logic, checks the implant carve-out, and drops an 837 through Waystar. Between those steps sit the denials: missing implant invoice, procedure not on the ASC covered list at the site of service billed, modifier missing, prior auth on the wrong CPT because the surgeon's office authorized a 29881 and the surgeon did a 29880.

Off-the-shelf billing modules validate what they can see in their own database. They cannot see that the auth number your scheduler took over the phone was for a different CPT than the one now in the op note, because the auth lives in a fax, a payer portal, and a note field.

A custom pre-claim gate fixes the highest yield version of this. At posting, extract the authorization from the faxed or uploaded approval using document extraction, store CPT, units, date range and auth number as structured fields, not free text. Then run a rule at three checkpoints: at posting, at 48 hours pre-op, and at chart close. If the documented CPT diverges from the authorized CPT, it stops and pages the business office while the patient is still on the table's schedule, not 45 days later when the denial arrives. Pair that with an eligibility recheck 72 hours out via the 270 and 271 through your clearinghouse, because coverage changes and the January cases are brutal.

What this costs and how long it takes

These are Digital Heroes delivery bands across 2,000 plus projects, not market averages. A focused first release, typically block management plus the surgeon scorecard, or implant capture plus invoice reconciliation, runs $60k to $130k and ships in 12 to 16 weeks. A full platform spanning block, staffing, implants, pre-claim gating and multi-center reporting runs $150k to $400k, phased over 6 to 12 months, and you should insist on phasing so something is live in the first quarter.

What drives the number up in this category, specifically: the number of interfaces. One HL7 feed from HST is routine. HST plus Provation plus a clearinghouse plus an ERP (Enterprise Resource Planning) for AP is four integrations and four vendor relationships, and vendor side interface fees and lead times are frequently the long pole, not the code. UDI scanning with real hardware in a real OR adds device testing. Multi-entity is not free: five centers with five payer contract sets and five accreditation bodies is a data model problem, not a config problem. And the compliance floor, HIPAA controls, BAAs, audit logging that survives a survey, access controls per role per site, is roughly 15 to 20% of the build and is not optional.

Build vs buy: when HST or SIS is genuinely the right answer

Take the position seriously: do not build a chart. If you are a single center or two, under 3,000 cases, one specialty, and one payer mix, HST Pathways or SIS Complete plus disciplined process is the right answer and a custom build will make you slower and poorer. The vendors have solved clinical documentation, ASCQR abstraction, and accreditation evidence, and re-solving those is a bad trade.

The signals that it is time to build are concrete. You have more than 1.0 FTE whose job is retyping data between systems. Block utilization has been stuck under 70% for three quarters despite a policy that says 75%. Implant variance is above 2% of net revenue and you cannot say why. You are acquiring centers and each new one arrives on a different stack, so every integration is a bespoke project anyway. Or the moment that decides it: you asked your vendor for a report that would change a decision, and they quoted you nine months and a change fee. That is the signal. Keep the chart, own the orchestration layer around it.

How to choose a developer for ambulatory surgery center software

Ask them to model your domain on a whiteboard before you sign anything. A firm that has done this can draw case, block, allocation, prime time, turnover, and the difference between scheduled and in-room minutes without you explaining it. If they use case and appointment interchangeably, they have not built one.

Ask for the integration scars. Who have they pulled data out of, HST, SIS, Provation, ModMed, Nextech, and did they use HL7 v2, FHIR, an API, or a nightly file drop, and what did the vendor charge to open it. The honest answer includes a story about a vendor who slow walked an interface for four months, because that always happens and you want a partner who plans for it.

Ask what they will do about compliance before you ask. HIPAA is table stakes: signed BAA, encryption at rest and in transit, role based access per site, immutable audit logs. Beyond that, ask how the system produces evidence for an AAAHC or Joint Commission survey and how it stays out of the way of your ASCQR reporting, which should keep flowing from the system of record.

Ask who owns the code and where it runs. You want the repository, the infrastructure account, and the right to hire someone else next year, written into the contract before the first sprint, not negotiated during a divorce.