Post-Process Workflow

A guide to understanding AngelTrack's automated billing workflow, from dispatch closure to final payoff

When a dispatch closes, it enters the Postprocess Workflow, following a path that leads eventually to payment:

Steps 0, 1, and 2: Report completion and QA review

The path begins when the dispatch closes. If completed (not cancelled nor delegated), the crew must complete their report and submit it. For very simple call types, like car service and wheelchair van, AngelTrack will automatically complete and submit the reports on the crews' behalf, provided the odometer readings and transit times are reasonable, and all necessary signatures are present.

The diagram above shows that some reports can skip QA. QA skips are controlled by a configurable preference in AngelTrack's settings. By default, the only dispatches that can skip QA are car, wheelchair, and gurney... and only if:

• Odometer readings are present
• All progress time punches (enroute, on scene, transporting, at destination, back in service) are present
• Odometer readings are consistent with the transport time
• All required signatures are collected, and the connected fields (name, title) are filled in
• Basic follow-up fields (driving, patient condition) are filled in

If a report does go to QA, it may take several go-rounds before finally passing. During that time, its postprocess alternates between  Awaiting QA review  and  Awaiting corrections .

Step 3: Initial Billing

After graduating (or skipping) QA, the dispatch enters the Billing office. If it is eligible for insurance, it is reviewed to make sure it should be filed. Otherwise, it goes straight to invoicing:

The "Insurance eligible?" question is answered automatically by AngelTrack, based on bill-to fields set during booking. The bill-to fields look like this:

AngelTrack sets these bill-to fields automatically based on the other parameters of the dispatch, though the dispatcher can override the automatic settings if she chooses. A dispatch is eligible for insurance if it is marked both ☑ Billable and ☑ Bill to Insurance.

Dispatches that are eligible for insurance go to the biller for review, to make a final decision whether or not to file against the insurance carrier. When the decision is "no", then the dispatch skips over all insurance steps, and goes straight to invoicing.

Steps 3 and 4: Insurance Interactions

If a dispatch goes to insurance, it may spend quite a lot of time going round with the insurance company. Denials are handled like this:

An insurance approval, on the other hand, can completely finish the postprocess workflow... or send it to invoicing if there is still a copay due:

Steps 3 and 4: Invoicing and Reinvoicing

When the time comes to directly invoice a facility, affiliate, or patient for the balance due, the task is performed by the respective Invoice Generator:

Normally an Invoice Generator will include all dispatches waiting to be invoiced, add them to the invoice, and then move them to Awaiting payment. However, invoices can also include dispatches previously invoiced (i.e. dispatches that area already Awaiting payment) if you wish to re-bill the unpaid items.

When an invoice is later paid, the money is applied to all of its dispatches. When the payment is sufficient to pay off a dispatch in full, the dispatch then moves to Finished; otherwise, it moves back to Billing office to be invoiced again:

This process then repeats until the dispatch is paid in full, or else the invoice is sold to collections. When an invoice is sold to collections, all of its dispatches are moved to Finished, regardless of whether they are paid in full.

To learn more about running a reinvoice cycle, refer to the Reinvoicing Guide.

Step 5: Finished / Write-off

Once a dispatch's balance due reaches zero, it will be automatically or manually advanced to Finished . It is then out of the workflow.

In AngelTrack, when a dispatch is advanced to Finished but not paid in full, it is considered a write-off. It will thereafter appear in the Revenue Accrual Report as a write-off for that year.

Data fields Controlling the Workflow

AngelTrack's postprocess workflow is governed by the following fields:

• Service level requested / Service level provided

  "Service level requested" is set during call-taking, and may change during dispatch and execution depending on what the crew finds on-scene; for example, while on-scene they may discover that a transport booked for wheelchair actually requires a stretcher, in which case they contact their dispatcher and upgrade the service level requested.

  When the call is finished, the QA Reviewer determines the official "Service level provided" by examining the run report.

  During all later steps in the workflow, the dispatch is treated as the service level provided, rather than that requested. Dispatches that skip QA are treated as the service level requested.

• Bill-to fields

  The bill-to fields indicate whether there is a fee for the service, and if so, which parties are obliged to pay it.

  • ☑ Billable
  • ☑ Cash up front
  • ☑ Bill insurance
  • ☑ Bill facility
  • ☑ Bill affiliate
  • ☑ Bill patient

  These fields control how a dispatch moves through postprocess, explained in more detail below.

  AngelTrack attempts to automatically choose the correct bill-to settings during call-taking. It does so based on the selected origin, destination, and patient... but the dispatcher is always free to override AngelTrack's suggestions.

  The bill-to fields do not normally change as a dispatch moves through postprocess, unless they are found to be incorrect.

• Execution Status

  Execution Status tells the overall result of the dispatch's execution in the real world: did it all go according to plan? Or was there a change-up in the thick of things? Or was it cancelled altogether? Or was it rolled to an Affiliate?

  Execution Status is set when the assigned crew reports they are finished and back in service. Thereafter, it is never changed unless it is found to be set incorrectly.

  Execution Status can allow a dispatch to bypass some or all of the postprocess workflow:

  

  To learn more about Execution Status, read the Call Completion guide.

• Postprocess Status

  Postprocess status tells where, in the postprocess workflow, the dispatch is currently waiting. It therefore tells who is responsible for making the next move:

  

  • Finishing report means that the dispatch is waiting for the attending crew member to finish filling out the PCR and then submit it to QA. AngelTrack's timeclock provides some assistance in urging the crews to finish their reports.
  • Awaiting QA review means that the dispatch is waiting for a QA Reviewer to review the run report and either pass or fail it.
  • Awaiting corrections means that the dispatch is waiting for the crew member to make the necessary corrections and then send the report back to QA. The crew will see all calls awaiting corrections, whenever they visit their Crew Home page.
  • Billing office means that the dispatch is waiting for a biller to file or process a claim or invoice or payment. AngelTrack has several billing queues, each representing a certain billing task, and each containing all of the dispatches awaiting that task.
  • Awaiting payment means that the biller has done their part and is now awaiting a response -- either payment or denial -- from the obligated party.
  • Finished means that all billing efforts have ceased, that no further monies are expected for the dispatch. If there is any unpaid balance remaining, it is thereafter regarded as a write-off.

• Payor

  Payor is set during the postprocess workflow, usually when the dispatch emerges from QA and reaches the Billing office (though it can be set at any time). The Payor field tells which party to the dispatch -- be it insurance, or the facility, the affiliate who rolled the call, or the patient personally -- is at the front of the line to be billed. 

  Although many dispatches will have multiple payors (insurance plus patient copay), the Payor field only tells who is currently being asked to pay. For example, the Payor will be set to 'Insurance' until the insurance company has made a final decision, and then afterward the Payor will be set to 'Facility' (if insurance refuses altogether) or 'Patient' (if a copay is due).

  As such, the Payor field changes over time, usually just once, reflecting the process of collecting first from insurance and then later from the facility and/or the patient.

  Newly completed dispatches do not have a Payor set, unless they specify only a single bill-to, in which case AngelTrack automatically sets the Payor to that bill-to. For dispatches eligible for insurance, a biller will set the Payor field while working the Insurance Review Queue; for all other dispatches, Payor will be set by the relevant Invoice Generator.

  Until the Payor field is set, AngelTrack makes the following assumptions:

  Bill-to Fields	Payor is Assumed to Be
  ☑ Cash up front (other fields ignored)	Patient
  ☐ Cash up front ☑ Bill insurance (other fields ignored)	Insurance
  ☐ Cash up front ☐ Bill insurance ☑ Bill facility (other fields ignored)	Facility
  ☐ Cash up front ☐ Bill insurance ☐ Bill facility ☑ Bill affiliate (other fields ignored)	Affiliate
  ☐ Cash up front ☐ Bill insurance ☐ Bill facility ☐ Bill affiliate ☑ Bill patient	Patient

As a result, every dispatch will follow an appropriate path through the Postprocess Workflow, whether or not the Payor is set.

The Postprocess Status Field Tells Who Makes the Next Move

The 'Postprocess Status' data field changes frequently, because it describes who is responsible for taking the next step in the postprocess workflow. It is the most important data field in AngelTrack.

As dispatches make their way through the workflow, the Postprocess Status field passes through these steps:

Each step of the workflow is color-coded and numbered, whichever is easier for you to remember.

Every dispatch will follow its own path, according to the peculiarities involved in getting paid for the trip. Sometimes the path is quick and direct, other times convoluted and full of advances and retreats:

Sometimes a dispatch will go back and forth between two steps -- which means: between two employees -- until finally being allowed to progress forward:

Bill-To and Payor Datafields Set the Path

Once a dispatch graduates from QA, if it does go on to the Billing office, the Bill-to and Payor fields rule its fate. They determine the path the dispatch follows through the workflow, which means: they control which billing queues the dispatch appears in.

The initial workflow looks like this:

The following table goes into greater detail, showing the initial workflow based on the dispatch's bill-to fields:

Bill-to Fields	Initial Billing Path After Finishing QA
☐ Billable	Go straight to Finished (no billing)
☑ Billable ☑ Cash up front* (other fields ignored)	Skip the Billing office, go straight to Awaiting payment If sent back to Billing office, appears in the Invoice Generator for Patients
☑ Billable ☐ Cash up front ☑ Bill insurance (other fields ignored)	Go to Insurance Review Queue If already reviewed, go to Insurance Filing Queue If already claimed/appealed, go to Awaiting payment If already paid in full, go to Finished
☑ Billable ☐ Cash up front ☐ Bill insurance ☑ Bill facility (other fields ignored)	Go to Invoice Generator for Facilities If already in a committed invoice, go to Awaiting payment If already paid in full, go to Finished
☑ Billable ☐ Cash up front ☐ Bill insurance ☐ Bill facility ☑ Bill affiliate (other fields ignored)	Go to Invoice Generator for Affiliates If already in a committed invoice, go to Awaiting payment If already paid in full, go to Finished
☑ Billable ☐ Cash up front ☐ Bill insurance ☐ Bill facility ☐ Bill affiliate ☑ Bill patient	Go to Invoice Generator for Patients If already in a committed invoice, go to Awaiting payment If already paid in full, go to Finished

The Biller who reviews the dispatches in the Insurance Review Queue decides whether they should be filed with insurance. If yes, then the biller ticks the checkbox to set the Payor to ☑ Insurance, causing the dispatch to advance to the Insurance Filing Queue. Otherwise, the biller sets the Payor to ☑ Facility, ☑ Affiliate, or ☑ Patient, whichever is appropriate, and the dispatch then advances to the respective invoice generator.

The Postprocess Status Report shows how many dispatches are in each of the progress points listed above.

*As noted, cash-pay services skip over the Billing office and go straight to Awaiting payment, as they await processing of the payment envelopes. To learn more about offering cash-pay services with AngelTrack, read the Cash Pay guide.

...And Then?

After insurance filing or invoicing, the dispatch advances to Awaiting payment, meaning that the biller is done with the call for the time being.

Once a dispatch reaches Awaiting payment, it remains there until changed by a payment event. A payment event may send it forward to Finished if paid in full, or may send it back to Billing office (perhaps with a different Payor) if the payment received does not cover the entire bill.

After a dispatch has spent an unusually long time awaiting payment, it also appears in the Stale Receivables Queue, in case intervention is required.

Finding a Dispatch in the Workflow

If you are not sure where a dispatch is in the postprocess workflow, open its Dispatch Edit page and select the "Billing" tab. A field named "Workflow location" shows where the dispatch currently resides.

AngelTrack's workflow is fully deterministic, meaning that every dispatch always has an exact position within the workflow, and its position can be deduced from its billing data fields and payment events. No dispatch can ever get lost in the workflow.

Keep in mind, a dispatch may appear simultaneously in more than one place. Dispatches can appear in the following places irrespective of their workflow location:

• Missing Demographics Queue
• Stale Receivables Queue
• Master Billing Records
• Prior Auth Queue

That is why you can -- for example -- ignore the Prior Auth Queue if management decides that you are not going to push your facilities to get their PANs filed. Dispatches will appear in the queue but that does not stop them from moving through the normal workflow.

Pulling a Dispatch Out of the Workflow / Parking

Sometimes you may encounter a billing problem that requires an extended research effort. You need to take a dispatch out of the workflow and keep it to yourself for a while, but you don't want to mark it  Awaiting payment  where it will slip away.

This is accomplished by parking the dispatch. It will immediately exit the workflow, and go and sit in your Parking Lot until you eventually unpark it.

Automatic Write-off When Extremely Stale

AngelTrack will automatically write off (i.e. will automatically advance to Finished) any dispatch that has seen no billing activity (payment events or committed invoices) for 24 months. You can change this interval to as few as 18 months or as many as 36 months, by visiting Preferences under Settings.

When an automatic write-off occurs, a journal entry for the affected dispatch will note the event; you can find these using Journal Search to find entries containing the words "Automatic write-off". Also, any billable dispatch that does not yet have a price quote will be quoted at retail.

Of course you can always un-write-off any affected dispatches, by moving them back to the workflow and adding them to a committed invoice, or by filing another insurance claim or payment.

To learn more, read the Automatic Write-off guide.

Bulk Postprocess Moves Using the Bulldozer

If you wish to move a large number of dispatches forward or backward in the postprocess workflow, then the Bulldozer is the way to do it. It is used for these kinds of situations:

• You are switching from an outside biller to an in-house biller, and wish to pull all receivables back to  Billing office for a full review.
• You are switching billers, and wish to push all older receivables straight to  Finished , to clear out AngelTrack's workflow for the new biller to make a clean start.
• You previously did not use AngelTrack's billing system but now wish to begin, and so all accumulated receivables need to be flushed out of the system.

To learn more about the Bulldozer, read the Bulldozer Guide.