FHIR Chat · FHIRPath usage question · fhirpath

Stream: fhirpath

Topic: FHIRPath usage question

Simone Heckmann (May 07 2018 at 19:21):

Hi all,
FHIRPath-newbee-question:
I have a definition for billing code 30110 in a 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 ChargeItem I want to validate 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 dive deeper into the FHIRPath spec to I refine it: is this generally something you could do using FHIRPath without breaking it? Or am I too far gone here...?

Bryn Rhodes (May 07 2018 at 20:10):

The difficulty will be accessing other ChargeItems from the FHIRPath. If there's a reference in the current element, you could resolve it. Where will this expression be defined?

Bryn Rhodes (May 07 2018 at 20:24):

Seeing the context for this question over on the conformance thread, yes, FHIRPath accesses through a specific resource provided to the evaluation as context. So you could express this with a CQL expression, but you'd have to use a retrieve:

Bryn Rhodes (May 07 2018 at 20:25):

not exists ([ChargeItem: "13250"])

Simone Heckmann (May 07 2018 at 21:53):

The difficulty will be accessing other ChargeItems from the FHIRPath. If there's a reference in the current element, you could resolve it. Where will this expression be defined?

That's where I'm unsure too. There are going to be multiple ChargeItems referencing one Account. The context for the FHIRpath expression is one of these ChargeItems. It does have a direct reference to the Account, but not to any of the other ChargeItems. So I basically need to do a search for all ChargeItems which reference the same account as the one I'm evaluating from.
So I'm not sure if this:
ChargeItem.where(code='http://fhir.de/CodingSystem/kbv/ebm|13250' and account=%context.account)
is legitimate.

I'm currently building the ChargeItemDefinition resource, that's where the rules will live...

Grahame Grieve (May 08 2018 at 05:05):

so there's a reason why invariants don't include language support for searching other resources - there's all sorts of reasons why you wouldn't have access to them

Grahame Grieve (May 08 2018 at 05:05):

if you really want to make rules like this, the nearest we have to it is a graph definition

Simone Heckmann (May 08 2018 at 06:36):

Could CQL handle this @Bryn Rhodes ?

Simone Heckmann (May 08 2018 at 07:30):

So, following your suggestion, @Grahame Grieve , I'd establish the context by creating a Bundle of all resources the fhirpath expression needs, using a graphQL expression.
Like this...?

    <applicability>
        <description value="Exclude: 13250"/>
        <!-- create a Bundle of all ChargeItems in the same Account as the current ChargeItem-->
        <context value="ChargeItem {account:Account { search ChargeItem?account={ref}}"/>
        <language value="text/fhirpath"/>
        <!--evaluate expression in context of the Bundle-->
        <expression value="%context.entry.resource.where(code='http://fhir.de/CodingSystem/kbv/ebm|13250').count() = 0"/>
    </applicability>

Bryn Rhodes (May 08 2018 at 13:14):

@Simone Heckmann , yes, CQL allows access to resources, either server-wide or filtered to a particular patient.

Simone Heckmann (May 08 2018 at 14:33):

Thanks, @Bryn Rhodes ! I guess I really ned to start reading the CQL spec ;-)
What I'm still having issues understanding: How do you e.g. pass context (patient, encounter...) that is given as parameters to the $apply-operation into the CQL expressions in PlanDefinition? Is there a syntax for that?

Bryn Rhodes (May 08 2018 at 14:49):

CQL defines a Patient context that is expected to be supplied by the evaluation environment. You can access that context within CQL using "Patient" as an identifier, and when you're in Patient context, all resources returned are filtered to that Patient.

Bryn Rhodes (May 08 2018 at 14:50):

The implementation of the $apply-operation then uses the value of the patient parameter to provide that context to the evaluation.

Grahame Grieve (May 09 2018 at 04:20):

@Simone Heckmann perhaps you can define for me what you're trying to do - CQL doesn't have the entry point it sounds like you want. and I suggested to use GraphDefinition, not GraphQL. They're very different things. But I think that the real problem you have is that you are trying to say is not sensible.

Simone Heckmann (May 09 2018 at 08:36):

@Grahame Grieve
ok, so in a ChargeItemDefinition, we're basically keeping stuff like prices or point values for billing codes or products.
There may be surcharges/discounts that apply in certain conditions or the price may vary over time.
Some billing codes may not be applicable at all in a certain scenario.

So, what I'm trying to do is to create an operation "$apply" consitent with the other definitional resources, that checks if an instance of a ChargeItem is applicable and returns the calculated price based with all applicable surcharges/discounts.

I believe in terms of logic involved this is pretty much the same thing as what PlanDefinition is doing. So I try to model ChargeItemDefinition consistently.

FHIRPath will work perfectly fine for conditions like:
- code only applicable for inpatient encounter
- discount only applicable for minors
- surcharge applies for certain coverage types ...
because all of these informations are directly or indirectly linked from the ChargeItem resource.

Problem is if I need to evaluate conditions that apply to stuff that's not linked from ChargeItem, like collisions with other ChargeItems in the same Account, or existence of certain diagnosis for the patient...

BTW, I meant to use "a text short hand form for GraphDefinition, loosely based on the graphQL language." rather than "graphQL" ;-)

Simone Heckmann (May 09 2018 at 09:22):

The implementation of the $apply-operation then uses the value of the patient parameter to provide that context to the evaluation.

@Bryn Rhodes ...but this isn't stated explicitly. The implementation "just knows" that it needs to do that. Because it isn't really that obvious to me since the $apply operation has many more parameters like encounter, practitioner etc. I would assume that many CQL expressions need the ecounter context as well, since it can't be inferred from the Patient resource. :thinking_face:

Brian Postlethwaite (May 09 2018 at 12:13):

This to me is feeling like its getting closer to server internal business rules, that might be better just described in narrative.

Simone Heckmann (May 09 2018 at 12:29):

Hm. Isn't this the same kind of rules the Clinical Reasoning Module is tackling right now?
Also, I think there is a real world need for being able to distribute these kind of rules from those who make them (Payers) to those who implement them (EHR vendors) in a machine readable, standardized way.
I don't assume that this is going to happen any time soon, but being able to show that this is something you could do with FHIR is an important sales pitch if we want vendors to adopt the FM module.

Grahame Grieve (May 09 2018 at 21:38):

you're certainly outside the scope of FHIRPath, which is a query language. It's a logical part of what you're doing, just like it's a part of all sorts of things we do, including CQL.

Grahame Grieve (May 09 2018 at 21:39):

I'm also not sure it's CQL either

Bryn Rhodes (May 10 2018 at 01:08):

@Simone Heckmann I think you're right that this is an area that is not clear. We do say in the documentation of the $apply operation that CQL parameters defined in libraries referenced by the PlanDefinition are bound by name to the parameters of the operation, but we don't explicitly define how that relates to CQL context. I suggest that you could rely on that parameter-name binding behavior and use the name of the operation parameters in your condition expression. If you wanted to submit a tracker to clarify, that would be fantastic too.

Simone Heckmann (May 17 2018 at 12:09):

@Bryn Rhodes following a discussion in PA/FM joint meeting today, I added a tracker item to suggest the introduction of a MetaDataType to harmonize the usage of machine readable expressions across resources: GF#17227
This also contains a request for making the mechanisms of establishing the context more expressive.

Bryn Rhodes (May 17 2018 at 13:10):

I think that's a great idea, it would keep representation consistent across the spec. I'd also like to see it as a type that can be used in an extension, though I understand that represents additional work for implementations.

Last updated: Apr 12 2022 at 19:14 UTC