Stream: terminology
Topic: adding prices to CodeSytem
Simone Heckmann (Nov 11 2017 at 15:11):
We are currently looking for a way to capture money and point values for billable codes.
However we found that concept.property.value[x] doesn't allow for Quantity.
Is that a legitimate Change Request or is this too far out of scope?
Grahame Grieve (Nov 12 2017 at 07:17):
don't know. I think we'd need to understand more about the use case and other use cases - has this come up in the catalog project? @Eric Haas @Lorraine Constable
Simone Heckmann (Nov 12 2017 at 11:44):
We've looked at the Catalog and CatalogItem Resource proposals, but they seem a bit overkill for our rather simple useCase.
Also, they don't seem to support prices either at this point.
We basically just need to be able to look up the price information for ChargeItem.code in order to create the Invoice.
Since CodeSystem already provides the $lookup operation that returns the properties, CodeSystem looks like a really good fit here without much hazzle.
...except for the missing Quantity option...
Grahame Grieve (Nov 12 2017 at 20:07):
I wasn't necessarily saying to use catalog output - just that we should understand the uses cases and their thoughts
Brian Postlethwaite (Nov 12 2017 at 22:04):
which leads me to a question on the expand operation. should that be returning any extensions on the concepts it is expanding?
Grahame Grieve (Nov 12 2017 at 22:13):
we haven't said - and it would depend on the extensions.
Brian Postlethwaite (Nov 12 2017 at 22:33):
Thought it would help with Simone's case, as she could put the extension on the concepts, and they could expand through
Brian Postlethwaite (Nov 12 2017 at 22:33):
(my server does this already)
Rob Hausam (Nov 13 2017 at 04:59):
Yes, I think this should be an extension. And if the extension can be returned by $lookup (which I'm assuming isn't likely to be the default), then that should meet Simone's use case.
Brian Postlethwaite (Nov 13 2017 at 05:29):
and $expand
Simone Heckmann (Nov 13 2017 at 08:32):
At this point, I can't say for sure, whether we'd need to have the prices in the ValueSet extensions as well, I think it would be sufficient to be able to $lookup them in the CodeSystem. Maybe @Udo Siefker can weigh in?
Simone Heckmann (Nov 13 2017 at 08:41):
I would assume that the reason why the concept.property has been designed as key-value-pairs in the first place, was to allow capturing all kinds of properties without having to use extensions. Why not allow valueQuantity here? The inconsistency of having to put half of the properties in value[x] and the other half in extensions feels wrong to me.
Agree that it has to be an Extension for STU3, but I would like to see it as core in R4.
There may be other useCases where valueQuantity might be useful, aside from prices.
Simone Heckmann (Nov 13 2017 at 08:43):
e.g. some diagnosis codes might have a minAge property indicating that they only apply to grownups.
Rob Hausam (Nov 13 2017 at 12:38):
I agree with you on that, Simone. Since we have valueInteger, I can't see a reason not to also allow valueQuantity. The other aspect to consider, though, is whether these properties are intended to be only for those that are defined by the code system itself (which pricing isn't), or also for any other properties that someone may what to define and associate with a code. I think it might make a lot of sense to allow the broader usage (similar to the HealthLanguage notion of "facets"), but I think we probably will also want a way to clearly distinguish which is which - possibly they could be handled as a separate top-level property, or we could add an additional flag (property.type currently isn't sufficient and we probably don't want to overload it).
Simone Heckmann (Nov 13 2017 at 13:25):
I would even go so far to say that the prices are indeed part of the CodeSystems in the use cases we have been discussing. In the first, the codes are billing codes for services, in the second we have internal order-codes for materials. In both cases, the prices are part of the original data structures we are creating the CodeSystems from, however, we might argue over whether these are still "CodeSystems" or something else altogether. :)
Lloyd McKenzie (Nov 13 2017 at 14:09):
As soon as you start to put time ranges on your prices, using CodeSystem starts to fall down. I think the pricing data is associated with the code system, but I'm not sure it should live there
Eric Haas (Nov 13 2017 at 15:20):
Same concern's as Lloyd and surprised by Rob's response. I think this is an attribute on Catalog entry or some other pricing structure. @Jose Costa Teixeira why isn't there any pricing information on catalog entry?
Simone Heckmann (Nov 13 2017 at 15:25):
The billing codes in our case are published quarterly, each constituting a new CodeSystem version, the prices don't change outside these publications. But changing prices might be a problem for the use case of internal order codes.
Eric Haas (Nov 13 2017 at 15:32):
Makes sense
Lloyd McKenzie (Nov 13 2017 at 15:58):
I don't think pricing has anything to do with catalogues. Pricing data is just pricing data. I'd expect there to be a resource called something like BillableItem that linked a particular procedure or product code to a price with a time-range, tax information, and potentially other information about what circumstances the price was valid for. That information might or might not find its way into catalogues, but it would certainly be used in lots of non-catalogue use-cases too.
Simone Heckmann (Nov 13 2017 at 16:11):
Yes, that would also be what chargeItem.definition should point at, I guess...
Rob Hausam (Nov 13 2017 at 16:35):
@Eric Haas, and everyone, I think we should keep CodeSystem generally and CodeSysytem.property, in particular, for information that is specific to and is defined as part of the code system. If folks feel that for whatever reason they need to or want to attach non-code system defined "properties" or other such information that is associated with a code, then this should be in extension space (at least for now). I think it's a bit unusual (I don't recall having encountered it anywhere else before), but it sounds like Simone is making the case that for their billing codes the price actually is defined and published as a part of the code system. The spec states that "Each concept defined by the code system may have one more values for each property defined by the code system". So if Simone's case actually does fit that (and the possibility of changing prices isn't an issue), then I imagine it's reasonable to allow for valueQuantity so it can be represented. But something like BillableItem probably would be a better place for this kind of information to reside, and if that works both in this case and more broadly then we wouldn't need to be changing or extending CodeSystem to accommodate it.
Simone Heckmann (Nov 13 2017 at 18:17):
I agree that BillableItem makes sense when we want to walk the extra mile (although that's a lot of miles actually) and also capture the complete set of rules that apply to the code in a billing context, e.g. when a code is only applicable to females or newborns, may not be used in combination with certain other codes, applies only once per encounter etc. Plus all the rules for when discounts or surcharges apply, tax rules as Lloyd mentioned... I guess the BillingItem is going to become a pretty fancy monster, when I think about it. So there may be situations (like ours) where this is just too much overhead. Especially when the CodeSystem has frequent releases and needs to be distributed among many systems.
Simone Heckmann (Nov 13 2017 at 18:21):
Though I'm actually quite intrigued by the BillingItem. Both ChargeItem and Account could have Operations, that check the viability of a code in their respective context by checking all the rules defined in the BillableItem...
Lloyd McKenzie (Nov 13 2017 at 19:35):
We have code systems for medications, locations, devices and a lot of other things - but we don't typically model things like drug strength or device manufacturer or location assets in the code system. Instead we use the code as a link to the appropriate resource for that data (Medication, Location, Device, etc.) I think pricing information ought to be handled the same way. (There's actually a section in the notes on CodeSystem.)
Lloyd McKenzie (Nov 13 2017 at 19:36):
BillableItems would also be specific to the organization that does billing - different organizations might use the same "billing codes" or product codes, but price things differently.
Bettina Lieske (Nov 15 2017 at 13:01):
Maybe we can provide some input to the discussion by describing the business problem that we face:
In many countries there are legally defined billing catalogs like the EBM catalog in Germany, the Tarmed in Switzerland, or DRG catalogs. They are published on a regular basis, often quarterly.
[see the picture below as illustration, sorry it’s only in German. In the appendix 2 of the EBM catalog (xls) the procedure codes and their mapping to service codes for surgery, anesthesia etc. can be found. For service code 31351 the EBM catalog item is shown below with its description, exclusion rules and also the price in Euro]EBM_catalog_Example.png
Bettina Lieske (Nov 15 2017 at 13:02):
In our understanding, a ChargeItem documents the provisioning of such a catalog item for a given patient which is then later on invoiced via an account.
The catalog item covers attributes like charge types (e.g. Departmental per Diem, Flat Rate Charges for Psychiatry), gender constraints, and prices.
These prices are actually base prices (there are possibly several base prices depending on the type of service provisioning e.g. when provided by a GP in contrast to a hospital physician)
Based on those, surcharges or discounts would be applied depending on the patient’s coverage and insurance information. This would then result in items on the final invoice.
In official catalogs price changes are handled through catalog versioning, but of course customers also define their own catalogs e.g. for wellness treatments not covered by the public healthcare system. In those customer-specific catalogs time-dependent prices are commonly used to reduce the catalog maintenance effort.
We had a look at catalog and catalog entry. Obviously they are in an early stage and seemed to address another problem. That’s why we then evaluated CodeSystem which seems to be well suited. We only missed the type Quantity as property value and the possibility of modeling time-dependent attributes.
We do not have enough FHIR expertise to decide whether the usage of codeSystem would be correct, we simply are looking for a solution for the described business problem.
Therefore we reach out to you for a better proposal if the codeSystem is not appropriate from your perspective.
Note: As far as we understood the BillingItem it is supposed to cover detailed pricing rules and further terms and conditions. This would rather be an internal resource for a Billing/Accounting module that receives ChargeItems as input and produces invoices as output.
Paul Knapp (Nov 16 2017 at 17:58):
It sounds like you are creating a price list which would include multiple elements, some of which would be codes, another element would be the prices (Money). This would not itself be a codeset or valueset - it would be more like a catalogue. The 'part number' or 'billing code' or 'medication number' is clearly a code as it is a singular 'tag' for a concept or thing which is resused as needed and typically survives over time. A parts (or billing, or medication) price list will list that code plus other values such as points, body site of use, active ingredient and then will include the price as a single value, a quantity purchase grid or series of costing components. The price record is a complex object and may be part of a list of complex objects but not a codeset itself - in part because there may exist multiple price lists all of which are in play at the same time and which include different prices for the same part, billing item, packaged drug etc.
Michael Lawley (Nov 21 2017 at 04:48):
Pricing data may vary in time and in other dimensions. Also, they're not a definitional part/property of the code itself. I had imagined that ConceptMap might be used to capture this kind of information
Grahame Grieve (Nov 21 2017 at 04:52):
how?
Michael Lawley (Nov 22 2017 at 06:43):
I was imagining that target.product could be used, but looking more closely I see that it's not quite what I wanted. OTOH, with a well-known code system for +ve decimals you could still do it.
Grahame Grieve (Nov 22 2017 at 07:38):
I feel as though the fact that the prices are time limited really means that these are not properties of the codes
Bettina Lieske (Nov 22 2017 at 10:38):
In the real world however, prices are often published with the codes in a catalog (like in my picture above). What would you suggest in terms of modelling approach instead?
Simone Heckmann (Nov 22 2017 at 10:42):
I think we havee to distinguish two use cases:
1) the prices are loosely linked to the codes and may vary over time or from Organization to Organization. In that case, I absolutely agree that they are not part of the code system.
2) the CodeSystem is a billing code system and the prices are published with the codes and the time during which the prices are valid are identical with the validity of the codes. In this case the codes are used for no other purpose than billing (e.g. in ChargeItem.code).
For the latter I believe that handling the prices as property of the code isn't that far out of line...
Simone Heckmann (Nov 22 2017 at 10:44):
In any case however I still like the Idea of defining a "BillableItem" or "BillingRules" Resource, that could be used to not only capture the prices for a particular code but also the time ranges for their validity and the rules under which discounts of surcharges may apply.
Rob Hausam (Nov 22 2017 at 11:17):
Even in Simone's #2 case, the pricing data still seems additional to and independent from the properties of the code system itself. So my thought is still +1 for the "BillableItem" or "BillingRules" resource (or something similar).
Simone Heckmann (Nov 22 2017 at 12:36):
About that: I'm having difficulties to wrap my head around where and how such a resource would be referenced.
The only place I can think of would be ChargeItem.definition. Should CodeSystem.concept.properties point at BillableSomething, too?
Lloyd McKenzie (Nov 22 2017 at 17:56):
In the real world, drug ingredients, location addresses, device characteristics and lots of other things are published with codes too. We have a pattern for dealing with such things that does NOT involve moving data that we have resources to address into code systems: http://build.fhir.org/codesystem.html#detailed-metadata
Lloyd McKenzie (Nov 22 2017 at 17:58):
Cost feels like something that should be handled in the same way. Cost information isn't necessarily associated with codes and can often be maintained separately from the code system that defines the thing being costed - If you're using RxNorm for drug codes, you certainly won't be embedding your prices in RxNorm. Having a supplemental resource that represents the time (and often client/location/etc.)-based costing information will work consistently regardless of the source of the codes describing what's costed.
Michael Lawley (Nov 23 2017 at 02:01):
The pattern is good, but how does it address arbitrary / ad-hoc details? That is, the pattern seems to require a pre-existing detail resource type - is Basic the starting point for these cases? If so, then how do you reference back to the code because Basic.code does not seem appropriate and Basic.subject is a Reference - so Basic.subject.identifier ?
Lloyd McKenzie (Nov 23 2017 at 04:06):
Ad-hoc things can be handled as code system properties. But if the information seems like it might be a candidate for a resource, that should be explored. I think there are lots of uses for a "cost" resource other than just a catalogue.
Simone Heckmann (Dec 07 2017 at 13:00):
I have submitted a resource proposal for a ChargeItemDefinition
http://wiki.hl7.org/index.php?title=ChargeItemDefinition_FHIR_Resource_Proposal
please comment!
Robert McClure (Dec 07 2017 at 13:26):
I'll take a look at the proposal but agree with Lloyd that code system properties should be things that are mostly static, ie: stay the same for that concept over time. A code system resource is where you associate things that change but are associated with a code. There are other uses of a code system resource (such as frequency of use) but pricing is a classic case.
Simone Heckmann (Dec 07 2017 at 15:09):
So you propose an all-purpose CodeDefinition resource rather than an accouting specific "ChargeItemDefinition"?
We created a resource proposal that would be generic enough (it's mostily key-value-pair stuff). We could add a type code to allow for different usage scenarios, such as accounting, statistics etc.
The resource would definitely require profiling to be useful in either scenario. But we consider accounting as extremely codesystem-/realm-/domain-specific, so we decided that having something very abstract and flexible is the best way to go forward.
Rob Hausam (Dec 07 2017 at 16:20):
I think the proposed ChargeItemDefinition resource makes sense for this - it seems consistent with the "Code systems with detailed metadata" guidance that Lloyd referenced above.
Simone Heckmann (Dec 07 2017 at 18:32):
Thanks, Rob. On second thought I don't thik it's a good idea to mix CodeStatistics with Billing Details. They should be seperate resource, especially because I think that Statistics is something that can be universally agreed upon with a very concise structure, whereas billing information will have very little common ground across domains.
Rob Hausam (Dec 07 2017 at 20:04):
I think that I agree with you about the statistics.
Marcelo Cabello (Aug 05 2019 at 22:26):
I agree. We have same situation here! To understand clearly, if prices changes means... should I create new version of the CodeSystem?
Robert McClure (Aug 14 2019 at 19:46):
This is an old thread but pricing should be represented as a code system resource with CodeSystem.content = "Supplement"
Grahame Grieve (Aug 14 2019 at 20:44):
(yes, using properties)
Lloyd McKenzie (Aug 20 2019 at 12:31):
Or maintained separately using ChargeItemDefinition
Last updated: Apr 12 2022 at 19:14 UTC
