Stream: CARIN IG for Blue Button®
Topic: Claim Reversal
Jason Teeple (Aug 14 2020 at 19:21):
@Amol Vyas How do we represent a claim reversal in the spec? If a claim was mistakenly paid (with no cost to the patient) and then payment was recovered, how should this be represented. To the consumer, they wouldn't know about the mistake.
Amol Vyas (Aug 14 2020 at 22:33):
In general, this would be the equivalent of a Claim Void business process, which is similar to the Claim Adjustment business process except no new claim is generated. Essentially, the 3rd party app will see a previously seen "active" status adjudicated claim/EOB but with a "cancelled" status.
Paul Knapp (Aug 19 2020 at 20:11):
@Jason Teeple You send a Claim Reversal (Cancel) see http://hl7.org/fhir/financial-module.html#uses. The specifics of how you would perform this depends on the exchange mechanism you are implementing.
Jason Teeple (Aug 19 2020 at 20:33):
Thanks @Paul Knapp - Wouldn't a claim reversal require a Task resource, which is not part of the IG?
Where I am getting hung up is on the following:
A patient accesses an Inpatient EOB on 7.1.20, they see a total amount of $15,000. One month later (8.1.20), they go back into the same Inpatient EOB and see a total for -$10,000.
In between 7.1.20 and 8.1.20, the payer made adjustments to the payment amount.
Would versioning of the EOB handle the difference b/c the 3rd party would have to get version 1 ($15k) and version 2 (-$10K) , do some math to determine the EOB is really for $5k?
Or is there something else I am missing?
Paul Knapp (Aug 19 2020 at 20:59):
@Jason Teeple The IG is not about using FHIR eClaims in the US - current HIPAA regulation requires X12 adn NCPDP standards for US eClaims. The IG is just for receiving Claims data for Patients, or other purposes, using the FHIR Explanation of Benefit. So if the insurer re-adjudicates a Claim then you would expect 2 EOBs which would be for the same Claim and presumably same EOB id, different .meta.versionId.
Jason Teeple (Aug 19 2020 at 21:10):
@Paul Knapp Would the second EOB show a negative amount (assuming an adjustment of $10k) or the new total amount ($5k)? My thought is that the second EOB would show a negative not a new total.
Paul Knapp (Aug 20 2020 at 03:31):
@Jason Teeple The new total ($5K) in the same way that a new version of a Patient resource to correct their birthdate would show the correct birthdate not the delta from the incorrect date.
Jason Teeple (Aug 20 2020 at 11:01):
@Paul Knapp I was not expecting this response. When a claim system makes an adjustment, the outcome is negative or positive number that needs to be applied to the previous version. (I acknowledge that every claim system is different) Wouldn't we be obfuscating aggregation/transactional details? In the end, someone has to do the math, either it is done before the resource or by the developer.
I appreciate the help on this topic as I have been receiving a lot of questions from our mapping teams.
Jason Teeple (Aug 20 2020 at 18:31):
@Paul Knapp @Amol Vyas Spoke with SME and aggregation isn't done at the claim system level for medical claims. Each claim system is different. If we only report out the most current version of the claim it could show a negative number. If we withhold reversals, then we'd be misrepresenting information. It would be more prudent to give the 3rd party devs all the information so they have all the appropriate details to share with the end consumers. We'd have to let the 3rd party app represent the information.
Last updated: Apr 12 2022 at 19:14 UTC
