A walkthrough of how AngelTrack's billing system automatically handles your batch files for you, and how to use it
The Insurance Transmission Queue and related pages exist to help you track and manage your batches of claims that are headed to the clearinghouse. When those batches are accepted or rejected, AngelTrack can automatically make the appropriate post-process workflow moves for you.
If you are not yet familiar with the numbers 837P, 999, 277CA, and 835, or if you do not yet know how your billing software, your clearinghouse, and the insurance carriers all work together, then read the EDI Primer first.
Creating a Batch
There are several places in AngelTrack where you can select dispatches and create an 837P batch of claims:
- Insurance Filing Queue
- Insurance Appeal Queue
- Insurance Exception Queue
- Master Billing Records
Select all dispatches that you wish to include by ticking the checkboxes along the left-hand side of the grid. Then select the X12.837P Batch option and click the export button.
After creation, your new batch is marked "Pending", and it appears in the Insurance Transmission Queue. You will be immediately transferred to that queue, and your new batch's row will be highlighted in light blue.
Dispatches must be coded first
Your dispatches must be coded first before it is useful to batch them into 837P documents. If you select an uncoded dispatch for your batch, AngelTrack will ignore it without issuing an error message.
Automatic Upload of Batches to the Clearinghouse
AngelTrack has an automatic SFTP uploader that can transfer claim batches to your clearinghouse for you.
To activate it, visit the "Clearinghouse Uploader Configuration" item under Settings. The configuration page is also accessible via a link on the Insurance Transmission Queue page.
To learn more, read the Clearinghouse Uploader/Downloader Guide.
Creating a batch that isn't for upload / Drop to paper
AngelTrack's clearing uploader/downloader will quickly upload any batch you create within a minute of you creating it... but you can also create a claim batch that isn't for upload, i.e. that you intend to print on CMS-1500 paper claim forms.
To do this, use the "Claim batch (no upload)" option in the Insurance Filing Queue's Bulk Operations dialog.
Manually Transferring Batches to the Clearinghouse
If you do not use AngelTrack's clearinghouse uploader/downloader to automatically transfer your claim batches to your clearinghouse, then you must perform that task manually.
The Insurance Transmission Queue keeps track of all claim batches -- active and finished. From there you can download them to your computer in order to send them onward to your clearinghouse.
Downloading a batch from AngelTrack to your computer
The 837P batches you create are stored indefinitely in batch records, which are listed in the queue. You can download each 837P document by clicking the 
suitcase icon. AngelTrack will send the file down to your computer. Downloading the file makes no changes to AngelTrack's databases, so feel free to download it as often as needed.
When you download the file from AngelTrack, you are saving it to your local computer.
Meanwhile, the 
suitcase icon will download to you a .PDF containing the claims as paper CMS-1500 forms, ready for printing.
Record your uploads
As soon as you finish manually transferring a batch to your clearinghouse, return to the transmission queue and click the "✔ Mark as transmitted" button to indicate that you've done so.
When you do that, AngelTrack will create all the necessary payment event records and advance all the included dispatches forward to "Awaiting payment". The dispatches will then leave the Insurance Filing Queue, Insurance Exception Queue, or Insurance Appeal Queue wherever they were while they awaited batching.
Canceling a batch
If you cannot complete a transfer due to some external cause, or if you change your mind about it altogether, you can cancel the batch instead of marking it transmitted. Click the batch ID number to open the Edit Batch page, change the status to "Cancelled", and save.
You can even cancel a batch retroactively after it was marked "transmitted". Doing so will delete all the "Claim" payment event records that it previously created and will push all of its dispatches back to the queue for filing.
Manually Importing X12.999 Replies from the Clearinghouse
If you do not use AngelTrack's clearinghouse uploader/downloader, then you must manually fetch and import any X12.999 EDI documents issued by your clearinghouse.
X12.999 replies should be uploaded back into AngelTrack using the Insurance Transmission Queue. AngelTrack processes the 999 documents to learn which batches were accepted versus which were rejected by the clearinghouse.
Uploading a 999 is easy. To get started, visit the Insurance Transmission Queue and click any 
button.
It doesn't matter which one you click because AngelTrack will automatically figure out which batch the 999 belongs to. When the Import an EDI Document page opens, upload your 999 documents when prompted, and then AngelTrack will process it and show you what's inside. You'll see a list of one or more batches (usually just one), and for each batch, an indication of whether it was accepted by the clearinghouse. If a batch is rejected, AngelTrack will attempt to decode the explanatory error codes and show them to you.
If the 999 contains something that AngelTrack doesn't recognize or is corrupted, that will be displayed in a "Parse Exceptions" column. If you see a parse exception and don't already know why it happened, please contact AngelTrack support so that the parser can be improved.
If everything is in order, press the "✔ Import" button. AngelTrack will then do all of the following:
- Save a copy of the 999 raw EDI data into the batch record for later review. (Click the batch ID to view it.)
- Update all of the "Claim filed" payment events that were earlier created when the batch was marked "Transmitted", in order to reflect "Success" or "Failure".
- If failure, push all affected dispatches back to the Billing office to be re-coded and re-batched... causing them to reappear in the Insurance Filing Queue*.
- Write journal entries for the affected dispatches, explaining what happened.
- Mark the batch record as "Successful" or "Failed", causing it to drop out of the Insurance Transmission Queue.
999 documents with multiple transaction sets are supported. AngelTrack matches them up to its batch records using their transaction set control numbers carried forward from the original 837P batches. When generated in batches (as opposed to singles), AngelTrack transaction set control numbers always begin with "AU", and are in the format AUxxxxxxx, where xxxxxxx is the decimal ID of the associated batch record.
*Specifically, AngelTrack accomplishes this by marking the "Claim" payment event record as "Failed", and then pushing the dispatch back to the Billing office. These two steps will satisfy the search criteria for the Insurance Filing Queue, causing the dispatches to appear unless they are parked.
Manually marking a batch as successful
If you are certain that a batch is accepted by your clearinghouse, then instead of uploading a 999, you can just click the 
button in the 999 column for the batch. AngelTrack will mark the batch "Successful", and perform all the same bookkeeping as though you'd uploaded a successful 999.
Postprocess workflow movements caused by batch status
When a batch changes status, its dispatches will sometimes move forward or backward in the post-process workflow. Here are the possibilities:
|
Pending transmission |
"Claim filed" payment event records will not be automatically created for the dispatches in the batch. If any "Claim filed" payment event records already exist, then they will be updated to show "Pending transmission". All dispatches in the batch will be moved back to the Billing office , if the payor is insurance and no newer insurance payment events are on file. The dispatches will therefore remain in the Insurance Filing Queue until the batch is marked "Transmitted". |
|
Transmitted, awaiting reply |
"Claim filed" payment event records will be automatically created for the dispatches in the batch, if not already. All "Claim filed" payment events associated with the batch will be updated to show "Transmitted". All dispatches in the batch will be moved forward to Awaiting payment , if the payor is insurance and no newer insurance payment events are on file. The dispatches will therefore exit the Insurance Filing Queue. |
|
Accepted by clearinghouse |
"Claim filed" payment event records will be automatically created for the dispatches in the batch, if not already. All "Claim filed" payment events associated with the batch will be updated to show "Successful". All dispatches in the batch will be moved forward to Awaiting payment, if the payor is still insurance and no newer insurance payment events are on file. The dispatches will remain out of the Insurance Filing Queue. |
|
Rejected or failed |
"Claim filed" payment event records will be automatically created for the dispatches in the batch, if not already. All "Claim filed" payment events associated with the batch will be updated to show "Failed". All dispatches in the batch will be moved back to the Billing office if the payor is still marked as insurance and no newer insurance payment events are on file. The dispatches will then reappear in the Insurance Filing Queue. |
|
Canceled, no action is needed |
"Claim filed" payment event records will not be automatically created for the dispatches in the batch. If any "Claim filed" payment event records already exist, then they will be updated to show "Cancelled". All dispatches in the batch will be moved back the to Billing office if the payor is still marked as insurance and no newer insurance payment events are on file. The dispatches will then reappear in the Insurance Filing Queue. |
X12.999 Rejections
When a 999 returns a rejection, it can reject specific claims or the entire batch.
999 rejections usually originate from your clearinghouse's claim scrubber. However, if you use a service that uploads your claims directly to a MAC or other carrier, then the 999 could come from the upload service (if it performs validations) or from the MAC or carrier itself.
When these rejections occur, AngelTrack will send the rejected dispatches back to the Insurance Filing Queue and mark them as "Failed", like this:
The "Failed" link leads to the EDI Batch Edit page for the rejected batch, in case you wish to review the 837P or the 999 or the 277CA (if any) in order to understand the reason for the rejection.
You can also return to the Coding page, where the decoded rejection will likewise be displayed:
Remember that a 999 can reject an entire batch, even for just one erroneous claim. When that happens, AngelTrack must therefore fail all claims back to the Insurance Filing Queue, even though only one of them is problematic, because all of them must be re-batched. This is so because the clearinghouse/carrier did not accept any of the claims; they must all be submitted again after the error is corrected.
If the rejected batch contained 100 claims, it may be difficult to find the one with the error because all 100 will be sent back to the filing queue as failed. In this situation, you may open the Coding page for one of the rejected dispatches, and you'll see the rejection warning on the "Last 999" tab as shown in the screenshot above, but there will be no messages from the 999 for the dispatch you clicked.
If that happens, then return to the Insurance Filing Queue, and instead of opening up a Coding page, click on the "Failed" link. This will open the EDI Batch Edit page, where you can check the 999 to see which dispatch IDs contain errors:
Manually Cancelling a Batch or Changing Its Status
At any time, you can simply tell AngelTrack whether the batch was accepted, rejected, or canceled. AngelTrack will then make all the necessary adjustments to the underlying payment event records and push dispatches forward or back in the workflow as outlined above.
To do so, visit the Insurance Transmission Queue and click the desired batch ID to open the Edit Batch page. Tick the desired status value -- "Successful", "Failed", or "Cancelled" -- and then save. AngelTrack will then perform all the necessary bookkeeping, just as if you'd uploaded a 999.
You can do that as often as you like, setting or changing the batch's status as you see fit. Whenever you do so, AngelTrack will re-adjust all the associated payment event records and (if applicable) move dispatches forward or back in the post-process workflow.
Likewise, you can cancel a batch at any time or uncancel it.
Be aware that changing a batch's status can impact the post-process workflow locations of its dispatches, according to the table shown above.
Manually Importing X12.277CA Replies from the Clearinghouse
If you do not use AngelTrack's clearinghouse uploader/downloader, then you must manually fetch and import any X12.277CA EDI documents issued by your clearinghouse.
X12.277CA replies from your clearinghouse should be uploaded back into AngelTrack using the very same process as you used with your X12.999 documents described above.
Unlike the 999 document, the 277CA document gives a claim-by-claim account of what was accepted versus what was rejected and why. AngelTrack will parse it for you and save the contents alongside each dispatch that was in the batch. Some common reasons for rejection include:
- Patient name misspelled
- Incorrect member ID number
- Incorrect date of birth
- Invalid pickup or dropoff address
As with the 999 imports, if the 277CA contains something that AngelTrack doesn't recognize or is corrupted, that will be displayed in a "Parse Exceptions" column. If you see a parse exception and don't already know why it happened, please contact AngelTrack support so that the parser can be improved.
If everything is in order, press the "✔ Import" button. AngelTrack will then do all of the following:
- Save a copy of the 277CA raw EDI data into the batch record for later review. (Click the batch ID to view it.)
- For each rejected dispatch, update the "Claim filed" payment events that were earlier created when the batch was marked "Transmitted" or "Successful" to now read "Failure". The batch itself is still marked "Successful", since it was indeed uploaded and processed by the clearinghouse. It will be individual payment events -- which means: individual dispatches -- that are now marked as "Failure".
- Push any dispatches marked with "Failure" back to the Billing office to be re-coded and re-batched... causing them to reappear in the Insurance Filing Queue.
- Write journal entries for the affected dispatches, explaining what happened.
- Mark the batch record as "Successful" if not already.
277CA documents with multiple transaction sets are supported. AngelTrack matches them up to its batch records using their transaction set control numbers carried forward from the original 837P batches. When generated in batches (as opposed to singles), AngelTrack transaction set control numbers always begin with "AU" and are in the format AUxxxxxx, where xxxxxx is the decimal ID of the associated batch record.
Split 277CA replies
Normally your clearinghouse will return a single 277CA document, originated by the carrier, telling AngelTrack which claims were accepted for adjudication versus which claims were rejected. The 277CA document contains the AngelTrack batch number (in the format AUxxxxxx) and covers all claims in the batch.
However, some carriers return two 277CA documents:
- A primary 277CA, reporting claims that were accepted and rejected by the carrier's primary screening. The primary screening looks for simple errors such as missing data fields, invalid policy ID numbers, math errors, and invalid ZIP codes. The primary 277CA document appropriately contains the AngelTrack batch number (AUnnnnnn) so that AngelTrack can match it up.
- A secondary 277CA, reporting additional rejections produced by the carrier's secondary screening. The secondary screening is more intensive, looking for data mismatches like inconsistent diagnosis codes and invalid modifiers. The resulting secondary 277CA document does not contain the AngelTrack batch number like it should; instead, it contains only claim control numbers and payor control numbers. It may also contain rejections of claims which were in different batches.
Because the secondary 277CA does not match up 1:1 with any batch in AngelTrack, AngelTrack does not store it with any batch the way a primary 277CA is stored. Instead, its contents are divided up by dispatch and stored in the matching claim payment event records.
The primary and secondary 277CAs are blended seamlessly by AngelTrack when you view the claim payment event record or when you are using the Coding page. In both cases, the "277CA" tab will show the secondary 277CA content if the claim has one, else it will show the primary 277CA content for the claim's batch. Therefore the biller is not required to sort or choose from multiple 277CAs: AngelTrack always shows you whichever one is relevant.
Deciding not to upload a 277CA
Once a 999 document indicates that a batch of claims is accepted, a 277CA document can later reject individual claims from the batch while keeping the rest. If you are certain that all claims are accepted, and thus no 277CA is needed, you can tell AngelTrack to stop waiting for one by clicking the 
button in the 277CA column for the batch. The batch will then exit the Insurance Transmission Queue.
X12.277CA Rejections
Carriers will return a 277CA in order to reject specific claims from a batch. AngelTrack processes 277CA documents just like it does for 999 documents, so the "X12.999 Rejections" instructions just above apply likewise to 277CA rejections.
There is one additional complication for 277CA documents. Some carriers will return an initial 277CA indicating that the batch has passed the first validation... but then, a day or so later, will return additional 277CA documents to reject specific claims.
This may happen in situations where a carrier's own computer systems perform the first validation and then passes the claims to a subcontractor who uses an entirely different computer system. The subcontractor's computer system will perform its own validation and issue its own 277CA documents for rejections. The subcontractor will return the 277CAs to the carrier, and then the carrier will return them to your clearinghouse, who will then return them to you.
AngelTrack handles this situation automatically. Simply upload any and all 277CA documents that you receive, regardless of their source. If a secondary 277CA later rejects a claim, AngelTrack will decode and display that rejection in the usual way (on the "277CA Decoded" tab of the rejected dispatch's Coding page).
Reviewing Old Batches
At any time you can return to the Insurance Transmission Queue and view old batch records; just untick the ☑ Hide finished batches, and ☑ Hide canceled batches checkboxes to see them.
For each batch, you can view the raw 837P and 999 EDI data using the respective tabs on the Edit Batch page. You can copy and paste that raw data into a third-party EDI viewer as desired.
Manual Download of Batches from AngelTrack
At any time, you can re-download the 837P from a batch no matter how old. Simply visit the Insurance Transmission Queue, switch to the "Finished Batches" tab, and then click the relevant suitcase icon.
You can also bypass all of AngelTrack's workflow UI and manually download the 837P directly by a simple URL:
https://your_server_name.angeltrack.com/batch/12345
That will download the 837P from batch 12345 right into your browser.
Likewise, to download a combined .PDF containing filled-out CMS-1500 forms for all claims in batch 23456, enter this URL:
https://your_server_name.angeltrack.com/batch/pdf/23456
These URLs are accessible to anyone in the "Biller" role.
You can also download individual CMS-1500 forms using URLs; to learn more, read the Data Export guide.