Stream: implementers
Topic: Invoices
Mattias Flodin (Apr 10 2018 at 11:38):
Hi,
I'm looking for some guidance on how to represent invoices. I've been searching the history about ChargeItem and there's been some very interesting discussions about them previously. Among other things, the new Invoice resource was mentioned.
We've been working for some time on building a flow around ChargeItem. The invoice is received in an XML format that we must store for auditing purposes. So we store the Base64 encoded XML in an extension within the ChargeItem, but lift some of the relevant properties into the ChargeItem. Unfortunately we've realized that we won't be able to map the invoice to a single ChargeItem, since an invoice can refer to several procedures for unrelated patients.
We can't break up the XML into parts for each patient, so instead I tried creating a Bundle that contains multiple ChargeItem resources and puts the XML extension in the Bundle. But a Bundle can't have an extension since it is not a DomainResource (why not?)
So now I'm unsure which path is the best. Should I create Basic resource and add extensions to contain the ChargeItems? Do I make a Bundle containing all the ChargeItems plus a Basic resource with the XML data? Do I try to incorporate the new Invoice resource (but we use fhir-net-api and it's not avalable there, right)? Something entirely different? Do you have any recommendations on how to think about this?
Mattias Flodin (Apr 10 2018 at 12:03):
If I'm going to make a Basic resource that mirrors the work-in-progress Invoice, would I need to create an extension with URI för every property that Invoice has? How do I put a list of resources in an extension?
Lloyd McKenzie (Apr 10 2018 at 13:38):
Bundle is a dumb packager. It has no semantics - and thus should not need extensions. What you might want to do is to use List or Basic as the root of your "Invoice" (until we have a proper Invoice resource). And if you want to put your Basic or List resource into a Bundle with all of the ChargeItem instances, that should work.
Mattias Flodin (Apr 11 2018 at 08:14):
@Lloyd McKenzie OK, thanks.
I'm pretty lost on my other question though: how does one encode a Basic resource with extensions that contains "standard" data such as a list of ChargeItems? Would I need to encode every ChargeItem property as an extension value?
Mattias Flodin (Apr 11 2018 at 08:15):
Are extensions containing lists even possible?
Jose Costa Teixeira (Apr 11 2018 at 11:15):
Why List and not Composition?
Mattias Flodin (Apr 11 2018 at 12:09):
Composition requires a subject. I don't know what that would be in this case.
Mattias Flodin (Apr 11 2018 at 12:10):
When I said "list" I wasn't necessarily referring to a FHIR List though.
Lloyd McKenzie (Apr 11 2018 at 14:06):
You would just have references to the ChargeItems. You'd still have the ChargeItem instances. List should let you do that without any extensions. However, perhaps I'm misunderstanding the use-case if you don't have a subject - is this not for a specific patient?
Jose Costa Teixeira (Apr 13 2018 at 13:11):
and this could be another argument for relaxing patient cardinality in Composition.
I was not considering patient as Mandatory because I thought there was an agreement already that patient would be optional, based on a requirement from Catalog discussions. (this is not about the Catalog, just that there may be more cases where a Composition is issued and there is no patient)
Simone Heckmann (Apr 13 2018 at 14:53):
Hi Matthias,
I guess we had a very different workflow in mind when we created the Invoice resource. We expect the collected ChargeItems for a Patient/Encounter to end up in an Invoice, whereas in your case, the Invoice creates ChargeItems, right?
What you discribe to me sounds more like a sort of Provenance. Such as that you receive an Invoice (which might be a FHIR Resource or something else alltogether) and create ChargeItems from it's content. The ChargeItems may and up in completely different Patient Accounts, bu somehow you need to be able to backtrace them to the Invoice from which they originated. Do I get this right?
Maybe a Bundle of ChargeItems + a Provenance Resource pointing both at the ChargeItems and the Invoice, might be appropriate for your scenario?
Simone Heckmann (Apr 13 2018 at 14:55):
BTW we do plan on adding an operation similar to $document to the Invoice resource, in order to create a Bundle of the Invoice and all related Resources (e.G. ChargeItems, Patient,...) for submitting, signing, archiving etc.
nicola (RIO/SS) (Apr 13 2018 at 15:00):
We need Invoice resource too.
Simone Heckmann (Apr 13 2018 at 15:02):
@nicola (RIO/SS) : Does this work for you? http://build.fhir.org/invoice.html
nicola (RIO/SS) (Apr 13 2018 at 15:03):
Thank you. We will check - @Varvara ?
nicola (RIO/SS) (Apr 13 2018 at 15:04):
Looks like what we need!
Simone Heckmann (Apr 13 2018 at 15:26):
Please let me know about your use case, so we can add this to our resource proposal and maybe, finally convince FM to approve it ...
nicola (RIO/SS) (Apr 13 2018 at 15:27):
We are implementing billing for network of dermatology clinics. @Varvara can describe our user cases in more details.
Mattias Flodin (Apr 18 2018 at 06:36):
@Lloyd McKenzie @Simone Heckmann In Sweden, each county is financially responsible for the healthcare of its citizens. If a citizen receives care in another county, then that county will bill the citizen's home county. However, they don't necessarily send a separate bill for each patient. A single Invoice can refer to hundreds of patients.
Mattias Flodin (Apr 18 2018 at 06:39):
I'm not convinced our workflow has to be different though. We can certainly create chargeitems separately. But we do need to collect them into a resource that groups many chargeitems for multiple patients. Using references to chargeitems instead of putting them inside the Bundle is fine.
Mattias Flodin (Apr 18 2018 at 06:44):
@Simone Heckmann There is also the case when we receive an Invoice from another county. Then all the chargeitems would have to be sent together with the invoice. It's certainly doable - our approach now is to use a container "message" object that is not standardized in FHIR. Of course it would be nice if everybody had the same understanding of what is the obvious way to represent that bundle of information.
Mattias Flodin (Apr 18 2018 at 06:50):
If you're working on the Invoice proposal it would probably be a good idea to pay some attention to the Swedish healthcare system, since I suspect its model is different from most other countries. There's generally no insurance company that pays for healthcare; it's paid for directly by the government through taxes. But at the same time healthcare is often provided by organizations not part of the county that pays for it. For example a private healthcare provider could bill the county, or counties can bill each other.
Lloyd McKenzie (Apr 18 2018 at 14:46):
Agree that invoices should be able to span patients (and in other cases, won't apply to any patients at all)
Simone Heckmann (Apr 23 2018 at 12:19):
@Mattias Flodin @Lloyd McKenzie I think the current design of the Invoice resource supports that, since the Invoice.subject reference is not mandatory and all individual ChargeItem resources have their own distinct ChargeItem.subject reference to a patient. Would you need an additional mechanism to group ChargeItems by Patient in the Invoice?
Als far as the bundled transport is concerned, I think a message type bundle with the Invoice as focal resource plus all referenced resources as part of the bundle is the best way to go. I guess we'd need to define an appropriate event-code and a MessageDefinition, to make the creation of the message-type bundle from an Invoice resource a part of the core specification, but that seems like low hanging fruit...
Mattias Flodin (Apr 23 2018 at 12:59):
Alright. No I don't think it's necessary with a grouping by patients. Surely that can be done programmatically by just looking at the patient ID.
We wouldn't be using the Message bundles since they are not appropriate for our communication pattern (broadcast, not point-to-point), but maybe someone else would. Invoices can't be the only use case for transferring resources from external parties though.
nicola (RIO/SS) (Apr 23 2018 at 13:43):
Do we need complimentary Payment resource or should we use CharteItem for that?
Mattias Flodin (Apr 26 2018 at 09:31):
@nicola (RIO/SS) what real-world concept would the Payment resource reflect? It sounds as if it's the actual payment that balances the chargeitem?
nicola (RIO/SS) (Apr 26 2018 at 16:15):
@Mattias Flodin Yes, this is a record about patient payment. We are implementing common billing module for dermatology clinic - so our not-FHIR model now is Invoice (ChargeItem) - PaymentAllocation - Payment.
Mattias Flodin (Apr 27 2018 at 06:08):
Ok. Invoice has a status that can say that it has been balanced, i.e. paid. Perhaps ChargeItem should have the same.
In our source system, a checkout from the hospital is an entity that contains both encounter information and amount payable by the patient. There's a code that says whether it has been paid at the register or if it should be paid by invoice. If it is the latter, then that triggers a signal to the billing system. But if it was already paid at the register, then there's no other entity to represent that.
Simone Heckmann (Apr 27 2018 at 13:36):
Wouldn't a patient paying at the register receive an Invoice as well?
nicola (RIO/SS) (May 09 2018 at 16:46):
Payment is a record about patient payment. One payment can cover many charge items or go to deposit. Another important entity, which is used by billers is "PaymentAllocation" - i.e. bind some portion of payment with charge item or invoice
Varvara (May 18 2018 at 16:53):
Hello, @Simone Heckmann, considering Invoices, for now our main use case is the same as you described above - when an invoice is issued for a patient to pay for particular services provided.
We are working on a billing system for our client, an outpatient provider of cosmetic and medical services. When a patient leaves an office, front desk staff have to issue an invoice for a patient to pay for specific services and products bought (if any). In this case, an invoice is a set of service lines and products with their quantities and prices, total balance and invoice status (draft, if not paid or partially paid, or balanced, if fully paid). In our case, the invoice always has a reference to a patient. If the invoice was created for a specific encounter, it also has a reference to the encounter.
I will be glad to provide more details if you have any further questions.
Simone Heckmann (May 18 2018 at 17:09):
Hello @Varvara ,
glad, you find the Invoice resource useful! Please let us know if you find anything missing. FYI: We decided at the past WGM to change the Invoice.lineitem from Datatype "Reference" to a choice of either "Reference" or "CodeableConcept" to allow for the addition of in-line items that do not relate to a previously created ChargeItem resource. The change has however not yet been applied in the current build.
Last updated: Apr 12 2022 at 19:14 UTC
