Call Completion

In AngelTrack every dispatch has two key datafields that are set when the dispatch is completed or cancelled:

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, these two datafields are never changed 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:


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:

Effect of Execution Status on Postprocess Workflow

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 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 Patient Disposition Datafield

After call completion, the crew sets the "Patient Disposition" datafield, as part of the followup information (leg times, odometer readings, delay reasons, etc.) set for every run before the report can be submitted to QA.

For wheelchair calls, AngelTrack attempts to set all of the followup fields automatically, including Patient Disposition.

Like "Execution Status", "Patient Disposition" controls how the dispatch moves through the postprocess workflow, causing some steps to be skipped where appropriate. For example, if the Patient Disposition indicates that no patient contact occurred, then the dispatch will skip over the insurance billing steps of the workflow.

Possible values for the "Patient Disposition" datafield are listed in the table in the next section.


Conflict Between Execution Status and Patient Disposition

It is possible for the "Execution Status" datafield (set by the dispatcher) to conflict with the "Patient Disposition" datafield (set by the crew). For example, if the dispatcher closes a dispatch as "Complete, as ordered", but the crew sets the patient disposition to "Cancelled on scene, no patient found", then the fields are in conflict.

Remember, the purpose of "Completed, best effort" 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 Patient Disposition and Execution Status fields:

Patient Disposition Transport was requested Transport was not requested*
Assist - another agency Completed, best effort Completed, best effort
Assist - public Completed, best effort Completed, best effort
Assist - another unit at this agency Completed, best effort Completed, best effort
Cancelled prior to arrival on scene Completed, best effort Completed, best effort
Cancelled on scene - no patient contact Completed, best effort Completed, best effort
Cancelled on scene - no patient found Completed, best effort Completed, best effort
Patient dead at scene - no CPR attempted, no transport Completed, best effort Completed, best effort
Patient dead at scene - no CPR attempted, transported Completed, as ordered Completed, best effort
Patient dead at scene - CPR attempted, no transport Completed, best effort Completed, best effort
Patient dead at scene - CPR attempted, transported Completed, as ordered Completed, best effort
Patient evaluated - no treatment/transport required Completed, best effort Completed, best effort
Patient refused evaluation - transported Completed, as ordered Completed, best effort
Patient refused evaluation - no transport Completed, best effort Completed, best effort
Patient treated - released AMA Completed, best effort Completed, as ordered
Patient treated - released per protocol Completed, best effort Completed, as ordered
Patient treated - transferred care to other EMS Completed, best effort Completed, best effort
Patient treated - transported in our vehicle Completed, as ordered Completed, best effort
Patient treated - transported by law enforcement Completed, best effort Completed, best effort
Patient treated - transported by private vehicle Completed, best effort Completed, best effort
Standby - no support provided Completed, best effort Completed, best effort
Standby - support provided to other agency Completed, as ordered Completed, as ordered
Transport of body parts or organs only Completed, as ordered Completed, best effort

Any combination not shown in the table, is a conflict. The crew will be prompted to resolve it.

*The phrase "Transport was not requested" means the dispatch was booked with the expectation that transport will not be necessary. Examples: telemedicine visits, on-scene labs visits, BLS/ALS calls with no destination specified (such as well-person checks and IV starts).

The Crew Resolves the Conflict

When such a conflict occurs, 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:

Crew Resolve Conflict page

What the page is really asking is: which field -- be it Execution Status or Patient 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 Patient 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 -- it was decided that re-opened dispatches would be too disruptive. It is better if every participant in the system can operate on the core assumption that "Once it's closed, it stays closed".

You can, at least, visit Dispatch Followup and change the execution status of a closed call, from "cancelled" to "completed" to "delegated"... but even 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 absolutely 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.



AngelTrack Help Index - AngelTrack Support