Updating ExplanationOfBenefit records published for the HL7 CARIN Blue Button IG
The ExplanationOfBenefit (EOB) resource has the ability to reference back to the EOB that it replaces after an adjustment or cancellation. The record can also, where appropriate, point from the cancelled record forward to the record that replaces it.
Think about how consumer apps will handle the data
When publishing updates to EOBs it is important to consider how a connected consumer app will handle the changes.
Why is this important?
Consumer Apps will be connecting to the API and downloading EOBs. If an EOB is cancelled and a new EOB is generated the next time the app connects it will pull any new records. If there is no relationship between the cancelled EOB and the EOB it is replaced by then the Third-Party App may have challenges identifying that a record they hold has been cancelled.
What should a Health Plan Do?
A Health Plan should always provide references to and from EObs when changes are made and an EOB replaces an earlier EOB.
It is NOT recommended that a replaced EOB is deleted without at least identifying which EOB a new EOB replaces. This enables a Third-Party App to trace the changes and keep their version of the records in sync.
If the replaced EOB is marked as cancelled, rather than being deleted, and the record is updated to provide a pointer to the EOB that replaces it the app will see the changed record and will be able to update the records they have stored correctly and present the new EOB to the member.
If the old EOB is deleted and the new EOB is made available in the FHIR API with NO reference to point to the EOB it replaced then the app would have no way to reconcile changes. The member would see the old EOB and the new EOB. It is likely that members would assume these are duplicate claims. This could lead to calls to customer service in order to reconcile the true situation.
There are two possible approaches to handling cancelled EOBS:
-
PREFERRED: Mark the old EOB as cancelled. Update the EOB with the reference to the EOB that replaces it. This will create a lastUpdated date that would be caught by any app that request recent changes to a member’s EOBs. The updated EOB would be downloaded by the app. The App would download the cancelled EOB and the new EOB that replaces it. Since each EOB would reference the other the Third-Party App can make the association to the EOB replacing the cancelled EOB and present the member with the correct information.
-
Delete the cancelled EOB. Record the Identifier of deleted EOB in the EOB that replaces it. When the Third-Party App downloads any new and changed records it will see that the EOB refers back to an EOB record they may have stored. The App can therefore track the replacement and present the new EOB.
It is important to remember that FHIR is an Interoperability specification and not a database model. As such it is important to communicate changes to data since systems connecting to a FHIR API may download data at different times. Therefore, it is important to be able to understand what changes have taken place.
[]: