Stream: implementers
Topic: Subtyping of primitive fhir values
Justin Pombrio (Jul 13 2020 at 17:51):
What are the practical consequences meant to be, of subtyping for primitive values?
For example, one place you'd expect it to be relevant is when setting elements in a map file. canonical
and url
are both subtypes of uri
. Under an ordinary subtyping system, this would mean that if a field has type uri
and you set it equal to a url
, that would be fine, because url
is a subtype of uri
. But if the field had type canonical
and you set it equal to a url
, that would be an error, because url
is not a subtype of canonical
. Looking at the "datatypes version maps", there is both a "canonical2uri" and "uri2canonical" group, which suggests that without those groups, neither conversion would be allowed? http://hl7.org/fhir/datatypes-version-maps.html
Another place it could come up is the is
operator in fhirpath. Should some_canonical.is(uri)
be true? How about some_canonical.is(url)
? Or some_uri.is(canonical)
?
I didn't find any page that talks about this, but if there is one and I missed it feel free to just point me in that direction.
Lloyd McKenzie (Jul 13 2020 at 17:54):
@Grahame Grieve @Bryn Rhodes
Grahame Grieve (Jul 13 2020 at 19:06):
in general, FHIR elements are final - you can't use sub-types in place of the types. It's possible that I overlooked some of the ramifications of sub-typing in the map files because I don't usually think about it for elements.
Grahame Grieve (Jul 13 2020 at 19:11):
for FHIRPath, for FHIR release 4,
some_canonical.is(uri)
= truesome_canonical.is(url)
= false;some_uri.is(canonical)?
= .... that depends, but false if uri refers to the type, or uri refers to a FHIR element type, but maybe true in some other circumstances
Lloyd McKenzie (Jul 13 2020 at 19:20):
Do we need to clarify any of that behavior in the spec?
Justin Pombrio (Jul 13 2020 at 19:45):
Thanks Grahame, that makes sense. So subtyping in fhirpath but not in fhir.
Do we need to clarify any of that behavior in the spec?
I don't think there's anything in the mapping language that talks about when it's legal to map one primitive to another. That would be useful to clarify. The fhirpath spec is pretty clear, though. For is
and related operators it says "... or a subclass thereof".
There's a separate question of how fhir types are supposed to map to fhirpath types, which as far as I know is unspecified. For example, fhirpath has no operations on the uri
type, only on string
s. Presumably those string
operations ought to work on uri
s, but the way that's supposed to work is unclear.
Grahame Grieve (Jul 13 2020 at 19:52):
I'll think about it
Justin Pombrio (Jul 13 2020 at 20:34):
FWIW, our implementation maps fhir types to fhirpath types according to the following table:
"boolean" => boolean
"string" | "code" | "markdown" | "id" | "uri" | "canonical" | "oid" | "uuid" => string
"integer" | "unsignedInt" | "positiveInt" => integer
"decimal" => decimal
"date" | "dateTime" => dateTime
"time" => time
Though there are a couple places we do this and they might not be totally consistent.
Grahame Grieve (Jul 13 2020 at 20:47):
that table looks correct compared to the table in the spec
Alexander Kiel (Sep 25 2020 at 15:10):
The conversation table can be found here: https://www.hl7.org/fhir/fhirpath.html#types
Gino Canessa (Sep 25 2020 at 15:16):
So, question... I see the page with that table is Normative - how do additions get handled? e.g., in R5 there's a new integer64 datatype, which should probably have a mapping.
Grahame Grieve (Sep 25 2020 at 15:21):
well, needs to be a task, and then we agree to add it, and it gets added. not quite sure what you are asking
Gino Canessa (Sep 25 2020 at 15:23):
Didn't know if it was the standard 'open a Jira', it was 'covered' by adding the datatype, or anything else.
Grahame Grieve (Sep 25 2020 at 15:24):
open a jira. it will be straight forward because it's not really a big decision, it's something I missed, but still needs approval by committee
Gino Canessa (Sep 25 2020 at 15:28):
Yep, opening two.. one for the page there (FHIR-I) and one for FHIRpath itself, since it specifies integer as 32-bit and doesn't have a 64-bit one.
Gino Canessa (Sep 25 2020 at 15:41):
Created FHIR#28615 for FHIRPath (though forgot to set workgroup to ITS - it doesn't appear to allow adding that later) and FHIR#28616 for FHIR-I FHIRPath info (with a note that it likely depends on resolution of 28615, since there needs to be a name for the FHIRPath type).
Last updated: Apr 12 2022 at 19:14 UTC