Stream: conformance
Topic: Dynamic context for FHIR-Path expression
Simone Heckmann (May 07 2018 at 15:52):
ok, so here's the thing:
exposition:
I have a resource ChargeItemDefinition, that defines rules of whether or not a BillingCode is applicable in a specific context. And I have the ChargeItem resource that provides the context for an instance. ChargeItem points to ChargeItemDefinition.
Now I want to define an operation, that evaluates the rules in ChargeitemDefinition in the context of a ChargeItem instance.
problem:
How do I define a FHIRpath expression in the ChargeItemDefinition resource that is evaluated in the context of the ChargeItem. I feel like I need some sort of placeholder for that, but I can't find any documentation on how to do that...
...or is that out of scope for FHIRpath and I need to read up on CQL? :stuck_out_tongue_closed_eyes:
Ewout Kramer (May 07 2018 at 15:59):
You would need the concept of having several instances of resources in the evaluation workspace of your evaluator and being able to refer to them from a FHIRPath expression. I am not aware we have that in FhirPath....
Simone Heckmann (May 07 2018 at 16:03):
So FHIRPath only works within the scope of one single resource? I didn't realize that...
Lloyd McKenzie (May 07 2018 at 16:05):
FHIRPath can certain traverse referenced types and profiles
Simone Heckmann (May 07 2018 at 16:08):
Ok, so I guess it's not a big deal to create an expression to say ChargeItem.code=1234 is not allowed, if ChargeItem.subject.gender=male, or something... My problem is, that I need to persist the expression outside the ChargeItem resource...
Simone Heckmann (May 07 2018 at 16:09):
..but then apply it to ChargeItem...
Simone Heckmann (May 07 2018 at 16:11):
Does this dynamicValue thing in the Definition resources help?
Simone Heckmann (May 07 2018 at 16:17):
There's no environment-variable in FHIRpath that could access the parameters of an operation, is there? I mean I could pass the ChargeItem instance id when calling the operation and then maybe do something like param.resolve()
Simone Heckmann (May 07 2018 at 16:42):
Doesn't PlanDefinition have the exact same problem with action.condition.expression and action.dynamicValue.expression...?
These expressions wouldn't resolve whithin the context of the PlanDefinition but rather in the context given by the in-parameters of PlanDefinition/$apply, if I read the spec right side up...
Simone Heckmann (May 07 2018 at 16:55):
...or am I overthinking this? I might as well just add some prose to the operation description saying that all expressions in ChargeItemDefinition need to be evaluated in the scope of the ChargeItem resource and leave the rest to business logic of whichever system implements the operation...
Lloyd McKenzie (May 07 2018 at 17:31):
I'd recommend leaving the implementation to the server. Different servers might implement differently. (I'll avoid the temptation to comment on the wisdom of business rules being tied to administrative gender... :>)
Simone Heckmann (May 07 2018 at 18:37):
You say that now, that I found the %context variable ! :-(
Simone Heckmann (May 07 2018 at 18:39):
So I'd define my expressions relative to %context and put some prose into the definition, that %context needs to be replaced by the current ChargeItem instance at runtime and leave the rest to the implementer's invention. Fair?
Simone Heckmann (May 07 2018 at 19:16):
ok, first draft: I have a definition for billing code 30110 in the current ChargeItem resource that may not be billed in combination with the code 13250. So I need to make sure, the code 13250 does not appear in the current ChargeItem's Account. %context is supposed to be replaced with the instance of the current ChargeItem at runtime.
<applicability> <description value="Exclude: 13250"/> <language value="text/fhirpath"/> <expression value="ChargeItem.where(code='http://fhir.de/CodingSystem/kbv/ebm|13250' and account=%context.account).count() = 0"/> </applicability>
My syntax may be way off, but before I refine it: is this generally something you could do using FHIRPath without breaking it?
Simone Heckmann (May 07 2018 at 19:19):
um. I think this topic has ventured too deep into the scope of the fhirpath-stream... I'll ask over there...
Last updated: Apr 12 2022 at 19:14 UTC
