Stream: implementers
Topic: Account Resource
Mounika (Apr 24 2019 at 07:08):
Hi all,
Account resource which is in R3 has Account.balance element. But, in R4 Account.balance was removed. I am unable to find which elemet replaces Account.balance. Can anyone suggest me.
Thanks in advance.
Phillip Liu (Apr 24 2019 at 08:12):
Hi all,
Account resource which is in R3 has Account.balance element. But, in R4 Account.balance was removed. I am unable to find which elemet replaces Account.balance. Can anyone suggest me.
Thanks in advance.
According to this page: http://hl7.org/fhir/diff.html, I don't think there's any replacement.
Mounika (Apr 24 2019 at 08:54):
@Phillip Liu which element we need to use for Account.balance in R4?
Lloyd McKenzie (Apr 24 2019 at 14:26):
@Simone Heckmann ?
Lloyd McKenzie (Apr 24 2019 at 14:26):
@Brian Postlethwaite
Brian Postlethwaite (Apr 24 2019 at 22:13):
The discussion around this was that balance was more likely to be an operation or something similar as the balance is very transient.
Brian Postlethwaite (Apr 24 2019 at 22:14):
But I believe there will be discussion in Montreal on this issue
Brian Postlethwaite (Apr 24 2019 at 22:15):
And it's effect on the history of the resource itself.
Simone Heckmann (Apr 25 2019 at 12:44):
We concluded that the balance of an Account is hard to maintain. If you wanted to have a reliable balance on the Account, you'd have to make sure, that it's being recalculated every time a ChargeItem is added, updated or deleted.
It makes much more sense, to calculate the balance only when it is needed, e.g. for the generation of a Claim or an Invoice. You can store the result of your calculations in Invoice.totalNet or Invoice.totalGros
Drew Torres (Apr 25 2019 at 13:07):
I will log a tracker about this. If a system is always going to calculate the balance why couldn't that just be an attribute of the resource instead of requiring some operation?
Lloyd McKenzie (Apr 25 2019 at 14:14):
You can only update one resource at a time. If you post a new ChargeItem, the Account.balance would be out-of-date as soon as the ChargeItem is posted until the Account gets updated
Drew Torres (Apr 25 2019 at 14:28):
The system implementing account can chose to update the resource/database tables immediately using database triggers.
Drew Torres (Apr 25 2019 at 14:28):
The field should still live on the resource even if you would impose the use of an operation to force the field to be populated.
Drew Torres (Apr 25 2019 at 14:30):
Let's play this out: An API consumer sends an operation to request the balance. WHat do you expect the response of the that operation to be? An extension, a string, operation outcome? I would expect the response to be an account with the field populated.
Lloyd McKenzie (Apr 25 2019 at 14:32):
FHIR needs to allow for systems where the only updates possible are via REST.
Lloyd McKenzie (Apr 25 2019 at 14:33):
The response to a "calculate balance" operation would be a Parameters resource containing a Money
Drew Torres (Apr 25 2019 at 14:37):
Can you clarify that statement? Updates only possible via REST are not realistic, but I may not understand the statement. Can you elaborate?
Lloyd McKenzie (Apr 25 2019 at 14:43):
In FHIR, we try to ensure that the interface can function such that all updates happen through the RESTful API. If that's not possible, then we've broken something. That doesn't mean that you have to operate that way, only that it's possible to operate that way.
Drew Torres (Apr 25 2019 at 14:52):
Is the concern that in theory you cannot directly update the balance on account?
Lloyd McKenzie (Apr 25 2019 at 14:56):
The concern is that the balance is intrinsicly tied to updates to other resources. We try very hard in FHIR to ensure that making an update to one resource never requires a simultaneous update to another resource to keep things "consistent". (That's also the reason why relationships only exist in one direction.)
Drew Torres (Apr 25 2019 at 15:00):
The relationship requirement has put us in the exact position you describe. Encounter/appoint have a issues like that for us. Some of that is due the nature of our EHR implementation. Example would be an appoint update via an API call automatically cancels the encounters associated.
Drew Torres (Apr 25 2019 at 15:00):
Due the way the relationship is handled in FHIR. We require the API consumer to make 3 calls to complete the workflow of scheduling. Create appointment, create encounter, and update appointment with the encounter just written.
Drew Torres (Apr 25 2019 at 17:09):
I logged: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20972&start=0 to discuss in person.
Shannon Locklear (Nov 17 2020 at 20:59):
Hello! I am a first-time poster so please forgive me if I haven't found the correct space.
We're struggling to make a decision on how to provide balance and a 3rd party integrator has indicated that other vendors give them an extension on the Account Resource for the balance. Has any further discussion happened on this topic that isn't captured here?
Lloyd McKenzie (Nov 17 2020 at 21:06):
Welcome :)
The main reason that Account doesn't have a balance is that every time a new transaction gets posted, the balance would change, and in a RESTful design, you don't want to force updating one resource to automatically force a change to another. The most natural way to get the 'current balance' would be an operation, though it doesn't look like a standard one has been defined. You could certainly submit a change request for that. An extension is also possible, but in general, you don't want people to change the balance on an account by updating the Account.
@Brian Postlethwaite for any other context?
Last updated: Apr 12 2022 at 19:14 UTC
