Stream: CARIN IG for Blue Button®
Topic: Explanation of Benefit - Status and _lastUpdated
Josh Lamb (Apr 06 2020 at 20:40):
Hello All (@Pat Taylor , @Ricky Bloomfield , @Amol Vyas , @Paul Church, @Ryan Howells, @Mark Roberts , others):
Are we allowed to modify an ExplanationOfBenefit resource that has an "Active" status? If so, it would greatly simplify these discussions. Otherwise my suggestion for how to define _lastUpdated is below:
Per my understanding there are only two opportunities for the _lastUpdated date to be set. Once when the resource is initially created (status of “Active”), and again when the resource status is changed to “Cancelled”. My understanding is based upon: https://www.hl7.org/fhir/financial-module.html#resource-status AND https://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-CARIN-BB-ExplanationOfBenefit-definitions.html#ExplanationOfBenefit.status.
We should also impose a status restriction on ExplanationOfBenefit.Status to only allow values of "Active" and "Cancelled". This is based upon our requirement to only communicate Adjudicated claims. We can also call out within the IG that a financial resource must be "Cancelled" and a new resource must be created (with status of "Active") in order to make modifications.
It will be difficult to provide guidance to systems that are utilizing a facade because we would have to know details about how their claims are processed. I was initially going to use a facade but found it difficult to represent point in time financial resources using this approach.
Paul Church (Apr 06 2020 at 21:30):
It's always hard to provide guidance to facades because there's such a variety of stuff behind them. In my mind the fundamental principle is that lastUpdated has to be no earlier than the most recent time where the server's response to a resource request was changed to a different value, but may be later than that. It's ok for a no-op change to advance lastUpdated, or for a collection of resources (e.g. an EoB and its supporting resources) to report that their lastUpdated is the max of all lastUpdated in the collection. The only case that's not allowed is when a client searching by _lastUpdated would miss an update that they could have found by inspecting all of the resources from scratch.
Does that help at all?
Even if you make the EoB immutable except for the status -> cancelled transition, are all of the supporting resources necessarily immutable? That seems like a very limiting assumption.
Josh Mandel (Apr 06 2020 at 22:31):
Paul hit the nail on the head for me. We shouldn't be writing any special guidance for lastUpdated, beyond having it reflect times when the resource content has changed.
Josh Lamb (Apr 06 2020 at 22:49):
I am in 100% agreement and did not mean to imply otherwise. This thread may be missing some context if you were not on the workgroup call earlier. We discussed before that ExplanationOfBenefit was immutable, so to me that means that opportunities to set _lastUpdated would be limited to two instances in time (resource creation and resource cancellation).
Right now I am just looking for clarity on if we can update an "Active" explanation of benefit resource. If we cannot how deeply does this restriction extend, e.g. are all referenced resources locked when we create an EOB?
Josh Mandel (Apr 06 2020 at 22:53):
are all referenced resources locked when we create an EOB?
Thanks -- I think I'm indeed missing context. Are you saying if an EoB references a patient, you might want to "lock" the patient?
Josh Lamb (Apr 06 2020 at 23:02):
We discussed today that if the referenced patient changed we would not need to create a new EOB but it left the implication open that if other resources changed we would need a new EOB. A few months back I remember discussing a case where the EOB should reference a point in time instance of Practitioner, Coverage, PractitionerRole, and other resources that could impact payment but this was never strongly defined. I am also not clear if an EOB in general can be updated, or if its just the EOB.Status field that cannot be updated once it is created, outside of Active -> Cancelled.
Josh Mandel (Apr 06 2020 at 23:04):
It's not clear to me why this IG needs to deal with this level of what I'd consider to be "internal" implementation details; isn't it possible that different systems will make different choices on this front?
Josh Lamb (Apr 06 2020 at 23:05):
That sounds like great advice to me.
Pat Taylor (Apr 08 2020 at 12:15):
Hello everyone, @josh lamb , @Ricky Bloomfield , @Amol Vyas , @Paul Church , @Ryan Howells , @Mark Roberts @Mark Scrimshire @Nick Radov
Yes, modifying an ExplanationOfBenefit resource that has an "Active" status is allowed. Mark Scrimshire can confirm, but my understanding is that there is no CMS requirement to keep the prior transaction.
However, unless we establish a rule otherwise, payers could keep the prior transaction with a status of "Cancelled". Adding Nick Radov. To your point, the IG should restrict values to "Active" and "Cancelled"
Pat Taylor (Apr 08 2020 at 13:12):
Note that an EOB is as of a point in time, which is the date of service. Changes to an EOB would reflect changes in the way the claim was adjudicated; for example, a previously denied claim was paid after the payer received additional information. Changing any underlying information, such as provider name, would not trigger a new EOB.
Pat Taylor (Apr 08 2020 at 13:14):
On a related note, we would support a 'MUST SUPPORT' requirement for date of service and last update date.
Pat Taylor (Apr 08 2020 at 13:15):
My bad.. should be 'SHALL'
Last updated: Apr 12 2022 at 19:14 UTC
