A complete guide of the four execution statuses and their implications in the rest of the system
In AngelTrack every dispatch has two key datafields that are set when the dispatch is completed or cancelled:
- Execution Status, set by the dispatcher, and
- Transport Disposition, set by the crew.
These two datafields summarize what happened during the run. They therefore control how the dispatch will be billed and how it will move through AngelTrack's postprocess workflow.
Once set, we strongly recommend never changing these fields unless found to be incorrect.
The Execution Status Datafield
The Execution Status datafield is set by the dispatcher when a run is completed or cancelled. It has four possible values:
-
Complete, as ordered
This execution status is designed to indicate that the dispatch was executed as originally ordered, and therefore the full postprocess workflow (run report, QA, billing, payment) should be followed normally.
This execution status is set when a dispatcher clicks the
button to close a dispatch after the crew has reported they are back in service. -
Complete, best effort
This execution status is designed to indicate that something changed or went wrong, such that the dispatch could not be executed as originally ordered... yet a crew did go enroute, and so the trip is still reportable to the state trauma registry, and furthermore the trip should be reviewed by the billing department.
This execution status is set when the dispatcher clicks the
button to close a dispatch; this button is available once the crew indicates they are on scene (at the origin). The "best effort" execution status can also be set at any time using the Followup page.AngelTrack is designed so that calls completed as "best effort" receive special attention during billing, because -- depending on what went wrong -- they may not be billable to insurance. Often they must be billed directly to the facility or caller instead. For example, if a patient is being transported to a doctor's appointment, but halfway there refuses to go and demands to be taken back to the nursing home, that transport may not be billable to insurance, instead going onto the nursing home's invoice, or to the patient.
Another time you may opt to use "best effort" is the situation where the crew arrives at the appointed time to pick up the patient, but due to a clerical error, the patient no longer resides at the facility.
-
Delegated to affiliate
This status is automatically set when a dispatch is assigned to an affiliate, rather than to a shift.
In AngelTrack, each affiliate has a setting called ☑ Progress reports, which indicates whether the affiliate's crews are expected to phone in their progress to your dispatchers. When an affiliate is so configured, the dispatcher must advance
the delegated dispatch through its legs (enroute / on-scene / transporting / at destination / back in service) as the affiliate's crew phones in their progress. Once finished, the dispatcher clicks 
to close the call, which sets the Execution Status to "Delegated to affiliate".For affiliates that do not report their progress, any dispatch assigned to them will be immediately closed and marked "Delegated to affiliate"; the dispatches will not appear on the "Assigned Dispatches" grid, because the affiliate's crew will not be phoning in their progress.
The "Delegated to affiliate" status causes a significant change in the dispatch's postprocess workflow, as indicated in the table below.
-
Cancelled
This status is automatically set when a dispatcher cancels a dispatch using the Cancel link and page. It can also be manually set using the Followup page.
We strongly recommend only using "Cancelled" for booked trips that were rescinded before any crew went enroute. This is because AngelTrack does not report "Cancelled" trips to the state trauma registry; whereas trips for which a crew went enroute but were cancelled before arriving on-scene, are indeed reportable, and possibly billable too.
A cancelled dispatch does not participate in the postprocess workflow: no run report, no QA, no billing, no payment, nothing. No reports are gathered, and no monies are collected. For this reason, all dispatchers should be understand the nature of "Cancelled" and when to use it versus "Complete, best effort". Agency policy will dictate what kinds of mistakes, problems, and no-shows should be billed to the facility/caller via "best effort", versus what should be forgiven (not invoiced) via "cancelled".
When a recurring dispatch is diverted, the regular dispatch is automatically marked Cancelled (causing it to reschedule itself normally), and a substitute dispatch is created for the diversion.
Change or Reverse a Completion Decision
After you close a dispatch, you can change its execution status. To do so, open the run ticket, switch to the "Billing" tab, and find the bar of execution status choices.
If a dispatch was assigned to a shift, then you can freely change the execution status between "Complete, as ordered", "Complete, best effort", and "Cancelled".
If a dispatch is marked "Cancelled" but was never assigned to a shift, then to change its Execution Status you must retroactively assign it to the shift or affiliate who ran the call. To do so, click the "Assigned to" link at the top of the run ticket. AngelTrack will show you a list of shifts and affiliates that were available during the trip's time window, and you can pick the one who ran it. AngelTrack will then set the Execution Status to "Complete, as ordered" or "Delegated to affiliate", as appropriate.
If a dispatch is marked "Delegated to affiliate", then you can freely change it to "Cancelled". To change it to "Complete, as ordered" or "Complete, best effort", you must retroactively reassign it to whichever shift actually ran it; see the instructions above.
Effects of Execution Status on Postprocess Workflow
A dispatch's Execution Status controls how it moves through the postprocess workflow. This chart shows the overall path a dispatch will follow, given different Execution Status values:
Keep in mind that other datafields also play a role in determining how a dispatch moves through postprocess. For example, if ☑ Billable is unchecked, then the dispatch will always go straight from QA to Finished, since AngelTrack believes there is no money to be collected. To learn about all the fields that contribute to the postprocess workflow, read the Postprocess Workflow guide.
The Execution Status field can be changed at any point in the postprocess workflow, and AngelTrack will then attempt to place the dispatch at the appropriate spot in the workflow. For example, if a cancelled dispatch is changed to "best effort", AngelTrack will move the dispatch back to the crew to get their run report, followed by QA as usual.
The Transport Disposition Datafield
After call completion, AngelTrack will auto-set the "Transport Disposition" datafield. That datafield is part of the Followup, and AngelTrack auto-sets it using PCR data. The crew is then free to modify the datafield as necessary, and is responsible for ultimately determining whether or not AngelTrack's auto-set field is correct.
"Transport Disposition" controls the PCR data requirement that AngelTrack imposes on the crew, and which your state trauma registry imposes (via their data validation rules) on AngelTrack. Therefore it is a crucial field.
Possible values for the "Transport Disposition" datafield are listed in the table in the next section.
Conflict Between Execution Status and Transport Disposition
If transport was expected (i.e. if a dispatcher has specified a destination name or street address in the run ticket), then it is possible for the "Execution Status" datafield (set by the dispatcher) to conflict with the "Transport Disposition" datafield (set by the crew). For example, if the dispatcher closes a dispatch as "Complete, as ordered", but the crew sets the transport disposition to "Patient refused transport", then the fields are in conflict.
Remember, the purpose of "Completed, best effort" in AngelTrack is to warn the billing department that something about the dispatch is unusual or incomplete.
The following chart shows all non-conflicting combinations of the "Transport Disposition" and "Execution Status" fields, for any dispatch where transport was expected:
| "Transport Disposition" Chosen By Crew | "Execution Status" Expected by AngelTrack |
|---|---|
| [Not applicable] | Completed, best effort |
| Transport by this EMS unit | Completed, as ordered |
| Transport by this EMS unit, with a member of another crew | Completed, as ordered |
| Transport by another EMS unit | Completed, best effort |
| Transport by another EMS unit, with a member of this crew | Completed, best effort |
| Patient refused transport | Completed, best effort |
| Non-patient transport (not otherwise listed) | Completed, as ordered |
| No transport | Completed, best effort |
Any combination not shown in the table is a conflict. The crew will be prompted to resolve it.
The crew resolves the conflict
When there is a conflict between the Execution Status and the Transport Disposition, AngelTrack will ask the crew member to resolve it.
AngelTrack will ask right after a crew member saves any changes to the dispatch's followup data. The crew will be shown a page that explains the conflict and asks how it should be resolved:
What the page is really asking is: which field -- be it Execution Status or Transport Disposition -- is incorrect? After the crew member answers, AngelTrack will make the necessary adjustments in its database, and the postprocess workflow will proceed normally.
Editing the Datafields Afterward
The aforementioned datafields can be edited at any time, if found to be incorrect.
Both of them are available for editing in the Dispatch Followup page, as well as the "Billing" tab of the Dispatch Edit page.
QA Reviewers have the ability to edit the Transport Disposition, but not the Execution Status, on the QA Review form.
Why Can't I Reopen a Closed Dispatch?
This restriction was a conscious design decision in AngelTrack.
Because so much happens to a dispatch in postprocess -- report completion, QA, insurance review, billing, invoicing -- AngelTrack is built on the assumption that you cannot reopen dispatches once closed. Every AngelTrack user must operate on the core assumption that "Once it's closed, it stays closed".
You can visit Dispatch Followup and change the execution status of a closed call, from "cancelled" to "completed" to "delegated"... but that change has serious billing implications, so make sure you understand the impact before doing so.
You can also cancel and then dupe a closed dispatch, if you must re-run it. The original dispatch will thereafter reflect its own history up to the point of cancellation, and then the new dispatch will start from there.
How to Uncancel a Dispatch / How to Uncancel a Call
If you wish to un-cancel a dispatch and instead mark it completed or delegated, you can do so by assigning it to the shift or affiliate that ran it.
To do this, first open the call's Dispatch Edit page. (In order to find the dispatch in the Closed Dispatches list, you must unhide cancelled calls.) With the run ticket open, click the "Assigned To" link:
AngelTrack will open the Dispatch Assignment page, and show you the shifts that were on-duty at the time the dispatch activated, as well as the affiliates that were open for business at that time. Select whichever one ran the call.
It might be necessary to retroactively create the shift that ran the call; if so, refer to the Retroactive Booking Guide.
Afterward, the associated crew will see the trip in their list of incomplete reports. The call will be marked "Complete, as ordered", but you can change that in Followup.
Reports on Cancellations / Canceled Call Reports
There are several ways to pull reports on cancelled trips. Remember that in AngelTrack, a cancellation is a call where no crew ever went enroute; if a crew did go enroute, the call will probably be marked as "Completed, best effort," rather than cancelled.
Here are the reports you can use to analyze your cancellations:
- The Call Cancellation Reasons Report, available under Dispatch Home, shows the various reasons for cancellation.
- The Dispatches Closed page, available in the sidebar in all dispatch-related pages, can list your cancellations if you toggle the filters to include them.
- The Consummation Rates Report, available under Dispatch Home, shows how often your various facilities cancel their booked calls.
- Report Builder's Dispatches-Cancellations category has a dataset containing all the fields you'll need to roll your own analysis.