Certain unified or "dual complete" policies, which unite Medicaid secondary coverage with Medicare or HMO primary coverage in a single policy, issue X12.835 EOBs that cause difficulties during processing and billing.
The Problem: Dual Adjudications Under a Single Policy
The problem with these policies is that they return EOBs as though they are two separate carriers, yet both the primary and the secondary adjudication claim to be primary. It is clearly a hybrid situation that the X12.835 spec cannot handle gracefully.
For example, these policies will typically return a pair of EOBs like this:
- Adjudicated May 12th, Processed as Primary, carrier type '16' (Medicare HMO), patient ID 'ABC123', payor control number 'XYZ123', forwarded to secondary (CLP02='19')
- Adjudicated May 12th, Processed as Primary, carrier type 'MC' (Medicaid), patient ID 'ABC123', payor control number 'XYZ456', original ref number (REF*F8) 'XYZ123'
To make matters worse, the pair of EOBs are often muddled together:
- The original reference number (REF*F8) in the second EOB is supposed to contain the payor control number from the first EOB, yet the data is sometimes incomplete, omitting the XYZ portion and including only the 123. This makes it very hard for software to match it up.
- The two adjudications usually occur on the exact same day, and the EOBs therefore often arrive out-of-order.
- Both EOBs sometimes report the exact same payor control number, despite being separate adjudications with different PR determinations.
- When the secondary EOB reports itself as "Processed as Primary" (CLP02='1'), it throws off calculations of net allowed amount and net patient responsibility.
The problem is also observed in the EOBs of some standalone Medicaid policies when adjudicating as secondary.
AngelTrack Requirements
Because such EOBs behave like a primary adjudication forwarded to a secondary, AngelTrack requires them to be filed in payment events in this manner. That is to say: AngelTrack requires the primary adjudication to be filed as from the primary, and the secondary adjudication to be filed as from the secondary... even though the patient does not technically have a secondary policy.
AngelTrack's EDI Import is aware of the problem and attempts to identify these secondary EOBs. When it finds one, AngelTrack displays it as "Processed as secondary (falsely reported as primary)." It will then raise a yellow warning icon, and suggest that the adjudication be imported as a secondary, rather than as the primary it claims to be.
AngelTrack will thereafter be able to properly calculate the patient responsibility, which will usually be zero.
Medicaid Carriers Do It Too
Some Medicaid carriers issue similarly ambiguous EOBs, even when the patient has distinct Medicare and Medicaid policies on file. The Medicaid EOBs claim to be "Processed as primary" (CLP02='1'), creating the exact same problem as with dual-complete/integrated policies.
When AngelTrack recognizes that the carrier is doing this, it will react as above: It will display the EOB's claim status as "Processed as secondary (falsely reported as primary)," raise a yellow warning icon, and suggest importing it as from the secondary.