Stream: fhirpath
Topic: Addressing choice[x] types
James Agnew (Sep 15 2020 at 13:29):
We've had a few people report bugs against HAPI FHIR lately where the investigation revealed that the reported was actually using an invalid FHIRPath expression (typically in a custom SearchParameter).
The common error is around addressing choice[x] types. People seem to often write expressions like this:
Patient.extension('http://foo').valueString
This of course returns no matches because there is no element called valueString. I'm wondering if it would be reasonable for FHIRPath to allow for this syntax. Or perhaps even if the spec doesn't explicitly allow it, for the implementations to be a bit more lenient and accept it. Anecdotal experience certainly seems to suggest that people find the current way counterintuitive.
Paul Lynch (Sep 15 2020 at 16:43):
fhirpath.js for a while only supported ".valueString" for something like that (because it didn't have data from the FHIR spec), and now supports both ".value" and ".valueString" to be more compliant. So, I am in favor of James' proposal, even though at this point we are adding more type information from the FHIR spec for other things.
Brian Postlethwaite (Sep 15 2020 at 20:54):
The other thing you could do is validate the fhirpath expression and report that out. We have code like that in our server and also in forge to check the expression works in the context.
Brian Postlethwaite (Sep 15 2020 at 20:54):
But there are edge cases on it too.
Brian Postlethwaite (Sep 15 2020 at 20:55):
But I too support being more lenient on it at execution.
Grahame Grieve (Sep 15 2020 at 22:57):
I'm not sure about changing the spec, but I can change the HAPI processor to be not so strict on request.
Grahame Grieve (Sep 15 2020 at 22:57):
I'm going to extend the tests for this
Grahame Grieve (Sep 16 2020 at 01:09):
ok so I did that and ran into an additional problem in testing for error handling, so I cleaned the error codes up. Here's my changes:
https://github.com/FHIR/fhir-test-cases/pull/74/files
Ewout Kramer (Sep 16 2020 at 08:20):
This of course returns no matches because there is no element called
valueString. I'm wondering if it would be reasonable for FHIRPath to allow for this syntax. Or perhaps even if the spec doesn't explicitly allow it, for the implementations to be a bit more lenient and accept it. Anecdotal experience certainly seems to suggest that people find the current way counterintuitive.
It would force implementations to have access to the type information for the resources and datatypes - mine does not yet. Without this type information, there's no way to know that "value" is an element name, and "String" a type. The current .value.ofType(String) does not have that disadvantage. If we would want to extend that principle to the use of FhirPath in discriminators and searchparameter definitions, this would also make those areas harder to implement. It's no free lunch, that's for sure.
Grahame Grieve (Sep 16 2020 at 09:48):
that's why I added it as a test mode.
Grahame Grieve (Sep 16 2020 at 09:48):
but I think your argument is incomplete - you can't not have knowledge to make it work properly
Paul Lynch (Sep 16 2020 at 13:19):
Ewout Kramer said:
It would force implementations to have access to the type information for the resources and datatypes
That is exactly the opposite of what I found, and I wonder why. In fhirpath.js, the JSON field in the resource being processed says "valueString", not "value", so in order to know that it should be "value", we have to pull in type information for resources. XML also says "valueString" in the tag, so I wonder how you are getting to "value" without that type information, and having gotten there, why is difficult to know it was once valueString?
Grahame Grieve (Sep 16 2020 at 23:00):
I agree with Paul there - for FHIR. But it's the opposite way around for, say, CDA. I know that most of you don't care about that ;-)
Grahame Grieve (Sep 16 2020 at 23:01):
(yet)
Ewout Kramer (Sep 17 2020 at 07:38):
Grahame Grieve said:
I agree with Paul there - for FHIR. But it's the opposite way around for, say, CDA. I know that most of you don't care about that ;-)
That's exactly it, @Paul Lynch - my FhirPath engine has no idea it's working with Fhir, so Fhir specific things like valueString (i.e. having the typename appended to the element name) etc have been abstracted away by the parsing layer. I then need type information to add it back - but that's also why this would be a backwards move for me.
Last updated: Apr 12 2022 at 19:14 UTC
