Stream: implementers
Topic: Encounter, rendering and billing providers
Mark Sternig (Apr 02 2019 at 14:57):
I am trying to represent the rendering provider and billable provider for a patient Encounter. My assumption is that the rendering provider should be represented as Encounter.participant.individual that references a practitioner, having an Encounter.participant.type = "ATND". Can anyone provide guidance on how to represent the BILLABLE provider? I had not found a particpantType code that seemed to match.
Lloyd McKenzie (Apr 02 2019 at 15:34):
@Brian Postlethwaite
Mark Sternig (Apr 02 2019 at 15:36):
The Cerner R4 implementation appears to use their own codes to define each participant, but if there is a more "standard" approach, I would prefer that. https://fhir.cerner.com/millennium/r4/encounters/encounter/#retrieve-by-id
Dennis Patterson (Apr 02 2019 at 16:04):
@Mark Sternig yes we have proprietary codes returned now for participant type, but that's not the limit of our strategy. We have a team working on creating proper mappings for http://hl7.org/fhir/ValueSet/encounter-participant-type
Brian Postlethwaite (Apr 03 2019 at 10:34):
As you go through that process, please do let us know if there are any oddities in there that we should address.
Brian Postlethwaite (Apr 03 2019 at 10:34):
@Simone Heckmann have you covered this in the billing stuff you've been looking into lately?
Simone Heckmann (Apr 03 2019 at 11:47):
The Encounter is not a financial resource and is not designed to hold any billing information. It's just capturing that a Patient has visited an Organization for a certain purpose during a certain period of time. We have explicit references to requestingOrganization and providingOrganization on each ChargeItem, assuming, that it's eventually the ChargeItems that are being billed rather than the Encounter itself. Account helps us to collect ChargeItems for one or multiple Encounters for the purpose of billing.
Mark A Johnson (Oct 31 2019 at 20:42):
I have a followup question. @Simone Heckmann , you mentioned "...it's eventually the ChargeItems that are being billed..." We see PriceOverride as well as a Quantity on ChargeItem, but no actual UnitPrice. How should the unit price be represented for a ChargeItem?
Simone Heckmann (Oct 31 2019 at 21:03):
Prices are captured in chargeitemdefinition unless the list price is overridden for the instance
Mark A Johnson (Oct 31 2019 at 22:08):
And if we're using STU3, should I assume I'd be using the definition uri property and defining an extension, perhaps similar to the R4 ChargeItemDefinition?
Last updated: Apr 12 2022 at 19:14 UTC
