AngelTrack 2.1 build 261 release notes

Release dates

New releases are always installed during a maintenance window, at 02:00 local time Sunday morning.

To join the early access program, contact AngelTrack Support at (800) 946-1808.

Improvements and new features

1. AngelTrack's EDI importer now tolerates the idiosyncratic format of 277CA files returned by the Optum clearinghouse. To illustrate, suppose we send an 837P that looks like this:

   AU0000042 (batch number 42)
       AD00001 (claim 1)
       AD00002 (claim 2)
       AD00003 (claim 3) - suppose this claim is bad and will be rejected
       AD00004 (claim 4)
       AD00005 (claim 5)

   A normal 277CA reply will look like this:

   AU0000042 (batch number 42) accepted
       AD00001 (claim 1) accepted
       AD00002 (claim 2) accepted
       AD00003 (claim 3) REJECTED
       AD00004 (claim 4) accepted
       AD00005 (claim 5) accepted

   The 277CA reply sent by Optum actually looks like this:

   AU0000042 (batch number 42) accepted
       AD00001 (claim 1) accepted
   AU0000042 (batch number 42) accepted
       AD00002 (claim 2) accepted
   AU0000042 (batch number 42) accepted
       AD00003 (claim 3) REJECTED
   AU0000042 (batch number 42) accepted
       AD00004 (claim 4) accepted
   AU0000042 (batch number 42) accepted
       AD00005 (claim 5) accepted

   When an Optum 277CA is detected, AngelTrack will now automatically reconstruct it in the standard format, merging the superfluous transaction sets into a single transaction set.
2. Revenue Accrual Report now includes ledger activity as a separate column.
3. Faster NEMSIS validation when the crew is sending their report to QA, and when the QA reviewer is sending a report on to the Billing office.
4. During import of an X12.835 EDI, the contents of PLB loops -- which describe carrier-initiated adjustments not associated with any particular dispatch or claim -- will now be displayed in a separate chart, because they require independent bookkeeping. AngelTrack does not track PLB adjustments because they are not associated with a dispatch or claim.
5. Payment Event Finder can now filter by the date that bookkeeping was performed. This is useful when calculating billings or commissions which occurred in a set time period, irrespective of the posting date or the date of service.
6. Payment Event Finder is now capable of handling much larger datasets, via the elimination of some grid features, including bulk export to .ZIP. However it can handle ten times as many rows, which can then be exported to Microsoft Excel or Google Sheets for further manipulation. With this change, Payment Event Finder now works like Bulk Excel Export and Line Items Report.
7. If a crew member's mobile device is not reporting GPS location via its web browser (as happens if the user answers "no" when prompted to allow AngelTrack to use location data), but their device is running the AngelTrack Beacon app, their position as reported by Beacon will now be used as the GPS pin.
8. Coding page now supports an explicit declaration of A0888 medically unnecessary mileage. AngelTrack will automatically subtract the specified mileage from the total transport mileage, in order to balance the claimed mileages and charges.
9. Coding page now supports the UB modifier, an obsolete modifier for the mileage service line required by the California Medicaid carrier.
10. Coloration of PCR buttons and fields is now standardized: yellow for data that is missing or incomplete, and red for data that is wrong, inconsistent, or which indicates an abnormal health condition.

Significant bugfixes

1. If a HCPCS code is accidentally typed into a facility record's "State facility code" field, any linked dispatches would subsequently fail NEMSIS validation.
2. If a biller accidentally enters an ICD-9 code for a dispatch that should be coded in ICD-10, the dispatch will fail NEMSIS validation with an error in ePayment.51.
3. Beginning in the previous build (260), if a biller accidentally uploads an X12.835 EDI two times, duplicate payment events will be created. This vulnerability is now fixed, and any duplicate payment events heretofore created by this vulnerability will be automatically marked 'deleted'.