Skip to main content

Practice Operations

ASC Records Requests: Chasing Charts You Do Not Own

An ASC hosts surgeons from outside practices, so the chart arrives from somewhere else. How AI runs the records chase and document routing inside athenaOne.

7 min read

ASC records requests are strange work, because almost nothing you are chasing was created by your own staff. A surgery center hosts surgeons who practice somewhere else, and those practices run their own systems. The document you need on Thursday lives in an office you do not control.

So the day-of-surgery paperwork problem is really a collections problem with paper instead of money. Somebody has to know which cases are missing which document, which office owes it, how long that office has been sitting on it, and when the version already in hand stops being usable. In most surgery centers that knowledge is one coordinator, a fax machine, and a printed grid for next week’s schedule.

The chart belongs to somebody else

This is the structural fact that makes surgery centers different from a practice that owns its own patients end to finish. The pre-surgical history and physical is typically completed by the patient’s own practitioner rather than by anyone on the surgery center’s staff, and federal conditions for coverage assume exactly that arrangement. The regulation requires the center to ensure each patient has the appropriate pre-surgical and post-surgical assessments completed, and requires the history and physical to be placed in the patient’s medical record before the procedure.

Read the verbs. The center is responsible for making sure the document is there. The center is not the one producing it. Every operational problem in this article follows from that gap between accountability and control.

Multiply it by the number of referring practices a busy center works with and the coordination surface gets large fast. Each office has its own staff, its own system, its own fax habits, and its own idea of what counts as urgent.

Your own policy sets the expiry window

Administrators often assume there is one federal number for how old a history and physical may be. There is not, at least not any more. The current rule puts the timeframe in the center’s own hands: the surgery center must develop and maintain a policy identifying which patients require a history and physical before surgery, and that policy has to include the timeframe for it to be completed.

The rule also names what the policy must weigh, and the list is operational rather than abstract. Among the factors it requires the policy to address are patient age, the type and number of procedures scheduled on the same surgery date, known comorbidities, and the planned anesthesia level.

So the expiry window is a local configuration value, and it can differ between two patients on the same Tuesday list. That is fine as policy and awful as a manual tracking problem, because the person watching the grid now has to apply a rule that changes per case. This is the kind of thing software should hold and people should not.

What the automation actually does

The work splits into three unglamorous jobs, and none of them require anyone to read the clinical content of a document.

First, intake and matching. Inbound documents arrive as faxes with no case identifier on them, addressed to a surgeon rather than to a case. The automation matches the document to the right patient and case, files it to the correct document class inside athenaOne, and routes it to the work queue that owns it. When the match is not confident, it does not guess. It parks the item for a human with the candidates it considered.

Second, the chase. For every case on the schedule, the automation knows which required items are missing and which office owes each one, and it calls, refaxes, and calls again on a cadence instead of when somebody remembers. Status calls to an outside office are the single most delegable task in a surgery center and the one most often done by the most experienced person in the building.

Third, the clock. Each item gets a countdown against the center’s own policy window for that case. The value of this is not the reminder, it is the ordering: the coordinator opens a list sorted by what expires first rather than by what was requested first.

One complication worth naming, because naive versions of this break on it: the document class catalog is not stable. Centers add classes, retire them, and fold several into one. An automation that hard-codes the routing map starts misfiling within a quarter. The map has to be read from live configuration, and an unrecognized class parks for a human rather than landing somewhere plausible.

When the outside office goes quiet

Every coordinator has three or four offices that simply do not respond, and the usual escalation is a surgeon calling a surgeon, which works and costs a favor.

There is a cheaper lever that surgery centers underuse. Under HIPAA, an individual has a right of access to their own records, and the provider must act on that request no later than 30 days after receiving it. A patient asking their own primary care office for their own history and physical is a different transaction than a surgery center asking, and it carries a deadline.

The administrative version of this is a scripted call: the automation reaches the patient, explains that one document is outstanding, and offers to send them the request language and the office’s contact details. That is paperwork logistics, and it moves records that a fourth refax will not.

What the automation does not do is decide the request is unnecessary, or judge whether the existing document is good enough. Those calls belong to the surgeon and the center’s clinical leadership.

Where the human stays

The boundary here is easy to draw and worth drawing out loud, because staff will test it in the first week.

The automation handles whether a required document exists, which case it belongs to, which queue it goes in, who owes the missing ones, and how close each is to expiring. Those are questions about the status of paperwork.

It does not read the document and decide what it means. It does not determine whether a patient is appropriate for the ambulatory setting, and it does not resolve a conflict between two versions of a record. When something is ambiguous, the useful output is not an answer, it is a well-prepared question: this case, this missing item, this office, contacted on these dates, expiring on this one.

That is the difference between a system a coordinator trusts and one they quietly re-check every morning.

Key takeaways

  • Write down your history and physical timeframe policy and the factors that change it, then treat that as configuration the automation enforces per case rather than a number people remember.
  • Track inbound documents by which outside office owes them, not just by which case is missing them. The chase is an account-by-account problem.
  • Sort the coordinator’s worklist by what expires first. Requested-date ordering hides the case that is about to fall over.
  • Read the document class map from live configuration and park unrecognized classes for a human. A hard-coded routing table starts misfiling within a quarter.
  • Use the patient’s own right of access on the offices that never respond. It is a different request with a real deadline attached.
  • Keep the automation on paperwork status and out of document interpretation. The handoff should arrive as a prepared question, not a recommendation.

Surgery centers carry accountability for records they do not create, on a schedule that does not move. That combination is why the paperwork chase eats the most experienced person in the building. It is also why it automates well, because almost all of it is status, matching, and a countdown, and none of it requires reading the chart.

Related reading: assembling the surgical pre-operative packet, surgical prior authorization automation, and records request intake and status calls.

Sources:

Ready to See It in Action?

See how Pretty Good AI chases inbound records and routes documents inside athenaOne.

Schedule a Demo →

Written by Kevin Henrikson