FHIR Chat · Subtyping of primitive fhir values · implementers

Stream: implementers

Topic: Subtyping of primitive fhir values


view this post on Zulip 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.

view this post on Zulip Lloyd McKenzie (Jul 13 2020 at 17:54):

@Grahame Grieve @Bryn Rhodes

view this post on Zulip 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.

view this post on Zulip Grahame Grieve (Jul 13 2020 at 19:11):

for FHIRPath, for FHIR release 4,

  • some_canonical.is(uri) = true
  • some_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

view this post on Zulip Lloyd McKenzie (Jul 13 2020 at 19:20):

Do we need to clarify any of that behavior in the spec?

view this post on Zulip 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 strings. Presumably those string operations ought to work on uris, but the way that's supposed to work is unclear.

view this post on Zulip Grahame Grieve (Jul 13 2020 at 19:52):

I'll think about it

view this post on Zulip 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.

view this post on Zulip Grahame Grieve (Jul 13 2020 at 20:47):

that table looks correct compared to the table in the spec

view this post on Zulip Alexander Kiel (Sep 25 2020 at 15:10):

The conversation table can be found here: https://www.hl7.org/fhir/fhirpath.html#types

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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