FHIR Chat · Paths for choice types · fhirpath

Stream: fhirpath

Topic: Paths for choice types

Michael Calderero (May 06 2019 at 10:48):

Given the following:

{
  "resourceType": "Observation",
  "valueQuantity": {
    "value": 26,
    "unit": "breaths/minute",
    "system": "http://unitsofmeasure.org",
    "code": "/min"
  }
}

The FHIR spec says I can use Observation.value or (Observation.value as Quantity) to refer to the value.

Question: Can we use Observation.valueQuantity as well?

Grahame Grieve (May 06 2019 at 10:54):

not in FHIRPath, no

Paul Lynch (May 06 2019 at 13:49):

fhirpath.js does not handle that yet, and still would use valueQuantity. The difficult part about ".value" is that fhirpath.js has no knowledge of FHIR types, so when it loads a JSON resource and sees the key "valueQuantity", it does not have a way to know that that should be changed to "value". In order to make that work, I think we will need to add some limited knowledge of the common polymorphic keys in FHIR.

Grahame Grieve (May 06 2019 at 13:51):

you are guaranteed that .value[x] will never have a sibling .valueXX so that there is any ambiguity

Grahame Grieve (May 06 2019 at 13:52):

so you shouldn't need any metadata insight to make that work

Paul Lynch (May 06 2019 at 13:56):

From fhirpath.js' perspective, "valueQuantity" has no more meaning than a key like "abc". I suppose if it knew a few basic FHIR types (Quanntity, Attachment, Reference), it could detect that "zzzQuantity" was meant to be a polymorphic value "zzz".

Grahame Grieve (May 06 2019 at 13:58):

yes. if you have a request for [N} and you don't find [N] but you do find [N]{T} where {T} is from the list below, then it's a match

Grahame Grieve (May 06 2019 at 13:58):

the list is:

Grahame Grieve (May 06 2019 at 13:59):

Address
Age
Annotation
Attachment
Base64Binary
Boolean
Canonical
Code
CodeableConcept
Coding
ContactDetail
ContactPoint
Contributor
Count
DataRequirement
Date
DateTime
Decimal
Distance
Dosage
Duration
Expression
HumanName
Id
Identifier
Instant
Integer
Markdown
Money
Oid
ParameterDefinition
Period
PositiveInt
Quantity
Range
Ratio
Reference
RelatedArtifact
SampledData
Signature
String
Time
Timing
TriggerDefinition
UnsignedInt
Uri
Url
UsageContext
Uuid

Grahame Grieve (May 06 2019 at 14:00):

that works across all versions

Paul Lynch (May 06 2019 at 14:05):

If FHIRPath is meant to be an language that is independent of FHIR, should it include so much knowledge of FHIR? I guess since FHIRPath is probably only used with FHIR, it is acceptable-- maybe it could include that type list as an override-able default.

Grahame Grieve (May 06 2019 at 14:11):

you are here asking a question about how the language binds to FHIR, not about the language itself. And so you get a FHIR specific answer

nicola (RIO/SS) (May 06 2019 at 20:48):

i still think postfix notation in fhir json is a mistake :) this is one of illustration

nicola (RIO/SS) (May 06 2019 at 20:49):

but yeah we can put some fhir-hacks to make it work

nicola (RIO/SS) (May 06 2019 at 20:51):

or can force always use x as Type => xType

Brian Postlethwaite (May 14 2019 at 18:37):

The rule to check the trailing text won't always work. As there are a few cases where this transform doesn't happen
e.g. http://build.fhir.org/medicationadministration.html#MedicationAdministration
the pair of instantiates properties. There are others, this was the first that I found.

Grahame Grieve (May 16 2019 at 22:25):

is it a problem?

Paul Lynch (May 17 2019 at 14:41):

@Grahame Grieve Yes, it is a problem in that it means that the light-weight solution you proposed for handling polymorphic fields would not work. In Brian's example, you would not want to replace "instantiatesCanonical" with "instantiates".

Grahame Grieve (May 17 2019 at 22:24):

well, why is that a problem? I think that is the intent here. It's on my list to get agreement to recast all of those as instantiates[x] : canonical | url

Paul Lynch (May 17 2019 at 22:25):

Oh-- in that case maybe it isn't a problem. @Brian Postlethwaite ?

Brian Postlethwaite (May 18 2019 at 00:00):

My point was the example I gave wasn't a choice type, so shouldn't be changing over to use just value. So the simple trailing type can't always be trimmed/assumed.
Even though in the future this specific case will be fixed to be a choice type.

Grahame Grieve (May 18 2019 at 00:00):

well, what's the harm in treating it as a choice type now?

Brian Postlethwaite (May 18 2019 at 00:01):

There were other cases, but I'll have to go find them.

Brian Postlethwaite (May 18 2019 at 00:01):

It's about knowing when to do it.

Brian Postlethwaite (May 18 2019 at 00:08):

It was also the point that I believe you were saying that you can't include the type in the field.

Grahame Grieve (May 18 2019 at 02:28):

hmm yes that's problematic. Might need some special case exemptions, I'm afraid.

Last updated: Apr 12 2022 at 19:14 UTC