QA Review Process Overview

A sample QA review process using AngelTrack's built-in systems

This guide provides a step-by-step guide to performing a QA review on a run report.

Before proceeding, you must be familiar with the QA Protocol in force at your agency. AngelTrack imposes certain minimums on reports before they can be sent to QA, and your agency may specify additional requirements. In any event, the current QA Protocol document is available as a link in the upper-right corner of the QA Review page.

By the way, the best way to perform a QA review is with a dual-monitor computer. Open the run report (or PCR) on one monitor, and use the other monitor to fill out the review form. If you do not yet have a dual-monitor computer, consider requesting one: many computers already have dual-monitor capability (or it can be added for $100), and computer monitors are cheap nowadays.

View the Run Report

QAReview.ReportLinksOpen the run report using the links in the upper-right corner of the QA Review form. The formatted run report will open in a separate tab. Switch back and forth between the review form and the run report as you work your way through it. (This is where a dual-monitor computer really comes in handy.)

When opened from the QA Review form, the formatted run report contains many blank rows. It does this in order to show you what data the crew did not supply. Normally, these unanswered datafields would be hidden: they are only shown to QA reviewers. If you wish to hide them yourself, remove the "&HideEmptyFields=0" from the formatted report's URL.

You can also open the PCR and see the call as the crew sees it. It shows the exact same data as the formatted run report, but it allows you to look at the various drop-down lists to see what other options the crew might've chosen.

Check the Billing Notes and Patient Notes

Always check the "Billing Notes" field to see if there are any instructions from dispatch or from the Billing office. Remember, the Billing office can send reports back to QA if they are lacking the data necessary to secure payment, and if that happens, there will usually be an explanation given in this field.

Also check the "Patient Notes" field for advice about the specific patient. This field is stored in the patient's record rather than in any dispatch record; as such, it appears in all of the patient's dispatches. If you modify the notes, your changes will appear everywhere that billers and QA reviewers are handling receivables for the patient.

Use the Completeness Grades

PCRCompleteness.Summary-1 Just below the report links is a chart of completeness grades, showing how completely the main PCR items (vitals, assessments, procedures, NFIRS modules, etc.) were filled-out. Sometimes it is okay if there are many missing datafields, especially if the scene was chaotic or if the patient was uncooperative. The completeness grades alone are not sufficient to pass or fail a dispatch, but they do provide a quick indication of the quality of the run report.

100% complete is not always possible

Remember, it is not always possible for crews to get 100% completeness on all PCR forms, because sometimes they do not have access to complete information. Unresponsive and uncooperative patients, or desperate emergencies, or extremely short transports, can prevent it. And we do not want them to lie; it is fine to sometimes leave some fields blank.

In other words, the purpose of the completeness grades chart on the QA review form is not to say "Here is the reason for an automatic QA failure". Rather, its purpose is to say "Here is the reason for QA failure if there is no justification for the omissions".

List Your Objections

In the middle of the review form is the list of objections. At first it will be empty, with a blank objection item waiting to be filled in. Just fill it in and click "Add".

Take care in specifying the proper category for each objection. The category data is used by AngelTrack's analytics to identify areas where more training is needed.

Be sure you read any comments from the crew (in the "Dialog With the Crew" box) before registering an objection; they may have already explained something you would otherwise object to.

Retracting an objection

If you change your mind about an objection, you can easily delete (retract) it, using the ☑ Deleted (retracted) by QA checkbox at the right. Retracted objections are not counted against the attending in the various QA performance reports that supervisors use to judge the quality of crew members' reports.

Determine the Service Level Provided

QA is responsible for deciding what service was actually provided. Often this will differ from the service that was requested.

The service requested / service provided datafields look like this:


As noted in the image above, AngelTrack examines the PCR records input by the crew, and estimates what service level can be justifiably billed. The estimated service is underlined. If this estimate is different than the service requested, then be sure you understand the reason. Some common reasons for service level changes are:

  • Dispatch intentionally downgraded the call based on patient condition on-scene. For example, nursing homes commonly make the mistake of booking wheelchair patients for stretcher transport, and vice versa.
  • The run report was sent to QA before the crew was finished with it.
  • The crew members did not have the necessary EMS certificates on file for the date the service was performed, and so AngelTrack does not consider them qualified to legally provide the requested service.

Also note that some services will be greyed-out, if the assigned vehicle is not legally capable of delivering that service.

The legal criteria for BLS and ALS service

The Centers for Medicare and Medicaid Services [CMS] dictates the criteria for BLS and ALS service designations. The criteria are laid out in Chapter 10 - Ambulance Services of the Medicare Benefit Policy Manual. The pertinent requirements are in sections 10.1.1, 10.1.2, and 30.1.1.

Those rules legally bind the Medicare and Medicaid carriers. Some state Medicaid carriers will pay for additional services, such as oxygen and sometimes even BLS supplies. Commercial carriers usually follow the CMS (Medicare) guidelines.

The legal criteria for MICU service

MICU service is known by all of these names:

  • Mobile Intensive Care Unit [MICU]
  • Critical Care Transport [CCT]
  • Specialty Critical Transport [SCT]

Unfortunately, the exact criteria for MICU service varies by state. The CMS (Medicare) policy manual says:

The EMT-Paramedic level of care is set by each State. SCT is necessary when a beneficiary’s condition requires ongoing care that must be furnished by one or more health professionals in an appropriate specialty area. Care above that level that is medically necessary and that is furnished at a level of service above the EMT-Paramedic level of care is considered SCT. That is to say, if EMT-Paramedics - without specialty care certification or qualification - are permitted to furnish a given service in a State, then that service does not qualify for SCT.

Note the highlighted sentence. It means that MICU service is any service that your state's health department does not allow paramedics to perform unless they obtain a "specialty care certification" from the state authorizing them to perform that service.

MICU service in states that do not codify MICU service

Some state health codes do not provide for a "specialty care certification", and so you cannot file MICU claims against Medicare in those states. Meanwhile your state's Medicaid carrier may have their own benefit schedule for MICU services... or may simply follow Medicare's lead and pay only for ALS-1/ALS-2.

If you are located in such a state, then you (the QA reviewer) must coordinate with the biller in deciding how to address the MICU service level. Your agency may have facility contracts which do spell out exactly what qualifies as MICU service, in which case you will need to establish a procedure like this one:

  1. If the call meets the MICU criteria defined in the facility contracts, then QA marks the call as MICU. For example, a request for a PALS-certified crew would qualify as MICU service in the sense of being "specialty critical care" that requires a certification above and beyond the EMT-P patch.
  2. When claiming the call against Medicare, the biller will downcode it as ALS-2. Downcode using the override control on AngelTrack's Coding page, so as to preserve the MICU determination from QA.
  3. Any denials or non-covered calls are then invoiced to the facility as MICU, which AngelTrack will do automatically on account of the MICU determination by QA.

The legal criteria for car, wheelchair, gurney, labs, and telemedicine service

These services are not covered by Medicare, and therefore are not defined in the CMS guidelines. They are either defined in your state's health codes, or are spelled out in your facility contract terms.

Fire service downgrades

The QA review form will suggest a downgrade of any fire-related call (fire, hazmat, extrication, rescue, inspection) to "good intent" if none of the responding crews had the necessary capability.

Your decision is binding on the entire billing process

Once you decide which service was actually provided, all aspects of AngelTrack's billing process will thereafter honor your decision. The service originally requested is ignored; the dispatch is forever after treated as the service provided.

The biller will have one opportunity to override your decision, when coding a claim for insurance... but not at any other time, or for any other purpose. The invoicing system always honors your decision and does not offer any option to override.

Raising the exception flags

If there is something unusual about the service provided, something which will affect the insurance claim and so ought to be brought to the attention of the Billing office, then set the red billing flag or the yellow "documentation problem" flag Flag.small.yellow-4. These flags are discussed further in the Billing Exception Flags guide. Have a conversation with the Billing office if unsure how they interpret these flags.

Review the ☑ Insurable Flag

The call-taker has already made an initial decision whether the call should be claimed against the patient's insurance. This decision is reflected in the ☑ Insurable checkbox, which is displayed on the review form next to the service level controls.

As the QA Reviewer, you are responsible for double-checking that decision... especially since the service actually provided may be much different than the service originally requested, as we know. It may be that a non-insurable wheelchair car turned in to a stretcher trip after the patient fell and got hurt. The dispatcher may or may not have remembered to go back and raise the ☑ Insurable flag.

Be careful flagging a stretcher call as insurable if the dispatcher has marked it non-insurable: there may have been a phone conversation already, warning the caller that the patient's condition or destination does not justify an insurance claim. Before you undo that, read the dispatcher's notes and comments to make sure you understand the situation.

Verify the Reason for Transport and the Reason for Stretcher

These two fields are urgently important for any EMS transport that will be claimed with insurance.

It is the attending crew member's responsibility to fill the fields out correctly. If there is a problem, your company policy will determine whether you 1) make the necessary corrections yourself, or 2) fail the report back to the attending. Either way, you are responsible for ensuring that the fields are correct before passing the dispatch on to the billing office.

AngelTrack will provide a bit of assistance here, highlighting in red any field that is required but left blank.

As a general rule, the reason(s) for an emergent or ALS+ transport are given in the Acute Symptoms list, whereas the reason(s) for a low-acuity or scheduled transport are found within the patient's medical history.

Assess Line-Item Service Charges

QAReview.ServiceCharges-2If your company assesses line-item service charges for certain things, it may be the responsibility of QA to identify and record the charges. Ask your supervisor to set expectations for this task.

If it is indeed the responsibility of QA to assess service charges, do so right inside the QA review form. The charges will later be reviewed by the Billing office, and they will appear as line-items in any subsequent invoice.

Specifying a quantity

To specify an item quantity, such as "5 NRB masks", in a manner that will be transmitted in any NEMSIS data exports of the trip, write the comment like this:

NRB masks quantity 5

In any subsequent NEMSIS export of EMS data, the data "NRB masks" / "quantity 5" will be included in a ePayment.SupplyItemGroup element in the ePayment XML group. The NEMSIS spec does not allow for AngelTrack to include the price; only the comment and the quantity are transmittable.

Some service charges are automatic

If there is a line-item service charge in the list which you did not add, it may have been added automatically by AngelTrack. It does so when there is a price configured for a medication or for a lab test. The price will be added automatically as a service charge when a crew member notes the administration of a medication or a lab test in the PCR.

If the crew member subsequently deletes the medication or service charge, then AngelTrack will likewise delete the accompanying service charge that it added.

Setting up a list of standard service charges

If you have a standard list of service charges at standard prices, then you can input that list into AngelTrack, under Settings. The list will thereafter appear in the QA form, so that you can pick charges and let AngelTrack automatically fill out the description and price fields.

To learn more, refer to the Line-Item Service Charges guide.

Services charges are ignored after insurance adjudication

If an insurance carrier adjudicates a price for a dispatch, then that price governs the rest of the billing process. It voids any service charges (and other discounts) on file for the dispatch. The service charges will remain on file in AngelTrack, but they will not be applied to an invoice unless the biller clears the insurance adjudicated price -- something that happens when there is a facility contract in play which spells out how service charges are handled in the presence of an insurance adjudication.

Review Patient Records if Necessary

If you need to look through the patient's (or customer's) record stored in AngelTrack, links to it are right on the review form.

To check the basic demographic, insurance, and medical information, click the Expand-Sep-21-2022-07-38-53-13-PM button to open the patient data folder. You can read the patient's basic information right inside the review form. Click the Shrink button to close the patient data folder again.

To dig further into the patient's history, click the patient's name. The full Patient Edit page will open, allowing you to view the patient's data for any checkpoint in the past. (To learn more about patient data checkpoints, read the Patient Data Checkpoint guide.)

Remember that for fire-related calls, the attached patient record represents the customer who is reponsible for the bill, if any.

Other Things to Check

While reviewing a run report, there are certain error-prone items that may merit inspection:

Leg times

"Leg Times" means the progress waypoints marked by the crew as they ran the call:

  • date and time they went enroute
  • date and time they arrived on-scene
  • date and time they began transport
  • date and time they arrived at destination
  • date and time they completed patient transfer and returned to service

The review form analyzes the leg times and calculates the number of minutes spent on each leg of the journey. If leg times are unusual, the crew should -- using the "Followup" page -- give the reason why. This reason will be displayed on the review form underneath the timespan in question.

Transport mileage

Accurate transport mileage is important, and not just for billing purposes. Every dispatch's transport mileage adds to AngelTrack's growing database of transport distances. This database is used by AngelTrack's billing systems to detect odometer mistakes and to counteract the superfluous extra miles caused by double-loading.

This statistical data is called "Normal Mileage". If AngelTrack knows the Normal Mileage for the route in question, it will be displayed next to the Actual Mileage, along with a percentage calculation comparing the two. If the Actual Mileage differs significantly from the Normal Mileage, there ought to be an explanation. (To learn more about Normal versus Actual Mileage, read the Mileages guide.)

If you need a second opinion of how far the transport should've been, click the "Map…" link to pull up an online map of the route.

Attached documents

AngelTrack cannot know when paper documents are present and ought to be scanned in. It is up to the QA reviewer to decide if important documents are missing... and to log objections for their absence.


AngelTrack has basic rules about which signatures are required for which sorts of dispatch. If the crew collected signatures to satisfy these basic rules, then the review form will indicate that signatures are "OK". Otherwise, the form will display the names of the signature forms that AngelTrack thinks are lacking.

If AngelTrack indicates a missing signature and you agree with the assessment, then register an objection.

As well, if you are reviewing the report and discover that an unusual circumstance necessitated additional signatures, and those signatures are not present in the run report, then register an objection.

Check Corrections

If you are re-reviewing a run report after the crew corrected it, go down the list of objections and verify that each one was adequately addressed. Once verified, check the ☑ Addressed by the crew box.

Once all objections are addressed, click the "Pass, Send Onward" button to graduate the dispatch from QA.

Send it Back or Onward

At the bottom of the QA review form are buttons allowing you to send the dispatch back to the crew for corrections, or onward to billing. You can also save your review but leave the dispatch in QA, if you intend to finish it up later.

If you have any comments for the crew, add them to the "Dialog With the Crew" box before you save.

If you fail the report back to the crew, you have the option of not counting the failure against the attending's QA performance statistics. AngelTrack provides supervisors with reports showing each crew members rates of QA failure and numbers of QA objections, and each QA failure matters. So, if you are sending back the report to the crew simply for clarification, or for their own edification, uncheck the box so as not to score it as a failure.

State Data Validation

When you pass the dispatch onward to billing, AngelTrack will perform a state data validation, using the validation rules provided by your state, as well as the national rules.

EMS (NEMSIS) data validation

For an EMS call, the set of validation rules is called a "schematron", and your state's schematron is already installed in AngelTrack for this purpose.


Unfortunately, AngelTrack does not control the content of these schematrons, and many of them are incongruous -- sometimes throwing error messages that make no sense, or warning messages that cannot be satisfied. Your state may or may not publish guidance on this subject, and may or may not enforce the warnings; consequently, AngelTrack will allow you to pass a dispatch onward even if it throws warnings.

If you are getting validation errors (not warnings) and cannot figure out the problem, call AngelTrack support.

Fire (NFIRS) data validation

For a fire call reportable to your state fire database, AngelTrack applies the set of all national NFIRS rules:

  • 184 Relational edits
  • 19 Incident module rules
  • All "star" rules

If any rule throws an error, AngelTrack will display it for you. You can then fail the call back to the crew to be corrected. Normally, a failing rule will prevent the crew from submitting their report to QA, but it is possible for a dispatcher or biller to jump a call past data validation and straight to QA or billing, in which case it could still have data validation errors.