An acute pain service round is a visit made on a day after surgery to manage the patient's post-operative pain. Most facilities send the comprehensive record for that visit. The record still contains the original surgery documentation in the same packet.

The autocoder detects the round and codes that visit. It does not code the surgery again. The surgery was already billed from its own surgery-day submission.

## What the autocoder produces

The autocoder picks the round service from evidence that it quotes verbatim from the record. There are three outcomes.

| Outcome | When the autocoder selects it |
|---|---|
| 01996, one unit | An epidural or subarachnoid catheter was in place. A provider managed it at the visit, on a day after placement. The line carries no time units. |
| Subsequent hospital care 99231-99233 | A peripheral nerve catheter was infusing, or the patient had a single-dose neuraxial opioid. The visit levels as subsequent hospital care. |
| No billable line | The record documents no catheter to manage. The autocoder builds no round line and raises an alert. |

A routed round claim carries no anesthesia time units and no medical direction modifier. It also carries no attestation record. Claim checks that expect times or an X modifier on every anesthesia claim do not apply to a round claim.

## Dates of service in a multi-day packet

A round packet spans more than one day. The autocoder keeps the documented date on each dated clinical note: a progress note, a history and physical note, a post-operative anesthesia note, and a pain round note. Earlier behavior pushed those later dates back to the encounter start date, which made a round look like the surgery day.

A round with no establishable visit date gets an alert instead of a line. Dating the round to the surgery date would duplicate the surgery claim.

## Alerts you can expect

The autocoder raises alerts on round packets so a coder confirms the outcome.

- **Possible pain-round packet coded as surgery** asks a coder to decide which encounter the packet represents. It fires when the packet carries some round signals, but not enough to code it as a round. Type HARDSTOP, default severity 10.
- **No billable pain-round service** asks a coder to read the named criterion that failed, for example a catheter that the record does not document as still in place. Type HARDSTOP, default severity 8.
- **Pain-round date not documented** asks a coder to establish the round date from the note header, the signature timestamp, or the post-operative day number. Type HARDSTOP, default severity 10.
- **Pain rounds on more than one day** asks a coder to split the packet into one claim per round day. The autocoder built one claim, for the latest round date. Type HARDSTOP, default severity 10.
- **Surgeon transfer of pain management not documented** asks a coder to confirm a documented request from the surgeon. Type COMPLIANCE, default severity 7.
- **Catheter insertion date not documented** asks a coder to confirm the round date follows the placement date. Type COMPLIANCE, default severity 5.
- **Pain-round coverage is payer variable** tells a coder the round followed a single-dose neuraxial opioid, so payer policy decides coverage. Type INFORMATIONAL, default severity 4.

Three more alerts cover packets that produced more than one round extraction, evidence the autocoder could not quote from the record, and a diagnosis validation step that did not complete. Read the alert reference for the full list.

## Configuration

Your facility configuration controls this lane through the `postOpPainRounds` setting. With the lane off, round packets code the way they did before the lane shipped, which re-codes the surgery in the record.

Your facility configuration can also enable a review gate, `postOpPainRounds.reviewGate`. The gate is off by default. When it is on, every in-scope claim gets the **post-op pain rounds review gate** alert (HARDSTOP, default severity 7) so a person validates the round coding. Scope `coded` covers claims the round lane coded. Scope `detected` also covers claims that coded normally from a packet where round content was found. Contact your Hank representative to change these settings.

## How this reaches you

What happens next depends on how your organization consumes HANK CODES. In HANK Claim Maker, a HARDSTOP alert places the claim in the review queue your administrators configured for it. Organizations that consume the coding API directly decide in their own workflow which alerts pause a claim, who reviews them, and when a claim is released.
