FHIR Chat · Warning - Technical Correction · conformance

Stream: conformance

Topic: Warning - Technical Correction

Grahame Grieve (Aug 15 2019 at 10:46):

GF#22493 is a very long piece of string. It's causing all sorts of issues for me. So warning: it will break many tools, I think, when I release the R4 technical correction

Grahame Grieve (Aug 15 2019 at 12:02):

btw, if you want to try it out, build the R4Final brnach

Grahame Grieve (Aug 15 2019 at 12:06):

but... I have a problem with GF#22670. The problem is, it makes me realise that our approach is wrong - we should have specified the type as http://something-system/String etc, rather than using extensions (when we changed it from code to uri).

Grahame Grieve (Aug 15 2019 at 12:07):

and I really don't like that disposition, let alone making it as a technical correction. I feel that in this case, we've bent over backwards to justify what is a wrong decision

Grahame Grieve (Aug 15 2019 at 12:10):

what if we changed from this:

      <type>
        <code>
          <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-json-type">
            <valueString value="string"/>
          </extension>
          <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-xml-type">
            <valueString value="xsd:string"/>
          </extension>
          <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-rdf-type">
            <valueString value="xsd:string"/>
          </extension>
        </code>
      </type>

Grahame Grieve (Aug 15 2019 at 12:11):

to

      <type>
        <code value="https://www.w3.org/XML/Schema#string"/>
      </type>

Grahame Grieve (Aug 15 2019 at 12:12):

as far as I can see, this is not documented anywhere in the normative content, so it's a change we can make. Having just reviewed all 380 places this element is referenced in the java code base, I know I can make the change, and I'd prefer it to the current approach.

Grahame Grieve (Aug 15 2019 at 12:12):

and I think that it would lead to a different disposition of what extensible means - one that is sensible

Grahame Grieve (Aug 15 2019 at 12:15):

@Lloyd McKenzie @Ewout Kramer @Michel Rutten @Josh Mandel @Rick Geimer @Oliver Egger @Chris Grenz your attention please

Grahame Grieve (Aug 15 2019 at 12:15):

though I guess this would represent blowing up the proposed technical correction schedule

Grahame Grieve (Aug 15 2019 at 12:17):

hmm, let's be clearer:

Grahame Grieve (Aug 15 2019 at 12:18):

This part of the disposition

any extension is present that conveys an alternative concept inexpressable by the ValueSet

I don't like that this is what extensible means.

Grahame Grieve (Aug 15 2019 at 12:19):

And I note that this:

CodeableConcept.text present with no Codings,

This is not the standing advice, and it's taking a position on an open issue that's been a hot topic for MnM and Vocab.

Rob Hausam (Aug 15 2019 at 13:46):

@Grahame Grieve So what exactly do you prefer for those last two points on what extensible means and CodeableConcepts with only text?

Josh Mandel (Aug 15 2019 at 18:24):

I agree, Grahame on handling URI extensible by using properly namespaced URIs rather than extensions. I'm pretty sure we would have said this in our resolution if we thought it was "allowed" in the context of a technical correction.

Josh Mandel (Aug 15 2019 at 18:26):

On the "CodeableConcept.text present with no Codings" piece, I don't think we intended to take a position on a hot topic issue; probably best to redact that component, but would be good to hear from @Lloyd McKenzie (since I seem to recall he had a strong perspective on that bit).

Grahame Grieve (Aug 15 2019 at 18:38):

@Rob Hausam I think that extensible is about the concept encoding. I don't think that anticipates replacement with extensions.

Grahame Grieve (Aug 15 2019 at 18:39):

I don't think we intended to take a position on a hot topic issue

Indeed, I think that's a problem in a technical correction. I'd like to take no position at all in R4 on this, and leave it to R5

Grahame Grieve (Aug 16 2019 at 01:10):

@Bryn Rhodes see above. Should this

    <type>
        <code value="https://www.w3.org/XML/Schema#string"/>
      </type>

should be this?

    <type>
        <code value="http://hl7.org/fhirpath/String"/>
      </type>

That one is ok, but there's no URI type in FHIRPath, and I need that....

Bryn Rhodes (Aug 16 2019 at 14:01):

I think this makes a lot of sense. Is URI the only one?

Bryn Rhodes (Aug 16 2019 at 14:33):

The XML representation talks about base64Binary, token, nonNegativeInteger, and positiveInteger.

Bryn Rhodes (Aug 16 2019 at 14:33):

But would those necessarily need to be reflected in the type like this?

Grahame Grieve (Aug 16 2019 at 20:23):

I guess we'd need boolean, integer, decimal, String, at least. Uri and base64Binary are giving me pause

Lloyd McKenzie (Aug 19 2019 at 01:54):

I'm fine with going to a URI for string. On the question of extensible, the key considerations are as follows:
- a required binding means you must have a coding from the bound value set if the element is present. Neither the presence of text nor the presence of extensions gets around that requirement
- with an extensible binding, we've said that you need to have a code from the bound value set if one applies. If not, you can send a code from outside the value set and/or text. We haven't, however, said anything about extensions. I think the same principle would apply as for text or codes outside the value set and that we should make that clarification. That's all that the original resolution was trying to say. (@Grahame Grieve )

Grahame Grieve (Aug 19 2019 at 03:36):

I’m not sure that the wording was neutral for a technical correction

Ewout Kramer (Aug 19 2019 at 09:07):

    <type>
        <code value="http://hl7.org/fhirpath/String"/>
      </type>

Yes, I had reached the same conclusion, but actually because I was thinking about GF#22774 - this presses the point that we need to be clear that the value property of the FHIR primitives map to a fixed set of primitives shared by FHIR, FhirPath, CQL and the mapping language. We have these types (in the "System" namespace) - shall we not map to those? Is this what we mean with fhirpath/String? Since they are also used in CQL (and I think the mapping language), we should not chose a name limited to "fhirpath".

Michel Rutten (Aug 19 2019 at 09:27):

I like the proposed change. Representation is more compact, more readable/less noisy, easier to process.

Grahame Grieve (Aug 19 2019 at 09:48):

ok, thanks. I'll work towards that. The open question is what the namespace should be, but I'll hard code that in a constant so we can decide later

Michel Rutten (Aug 19 2019 at 09:56):

Cool. As @Ewout Kramer mentions, we should try to align this with fhirpath, FHIR mapping language and CQL.

Grahame Grieve (Aug 19 2019 at 09:57):

right. Since they all build on FHIRPath lexically and typically, that's why I proposed the fhirpath namespace

Bryn Rhodes (Aug 19 2019 at 18:31):

Agree that the fhirpath namespace makes sense for that reason. In the CQL spec, we currently use urn:hl7-org:elm-types:r1 in the system model info, but happy to align on http://hl7.org/fhirpath as the namespace.

Bryn Rhodes (Aug 19 2019 at 19:56):

Here's the definitions for implicit/explicit conversions in CQL: https://cql.hl7.org/03-developersguide.html#conversion

Bryn Rhodes (Aug 19 2019 at 19:57):

And in the FHIRPath page of the FHIR spec, we describe implicit support for primitive types: http://hl7.org/fhir/fhirpath.html#types

Ewout Kramer (Aug 19 2019 at 20:36):

I was going to say that I think I prefer http://hl7.org/fhir/StructureDefinition/System.String, but then again, since this is at the bottom of the turtle stack, and it's not really a reference to anything, I would not mind 'urn:....' to clearly flag this anomaly. And although I am not coming from an ELM background, I am now following the ELM terms internally in my API, so I should be fine with urn:hl7-org:elm-types:r1 ;-)

Grahame Grieve (Aug 19 2019 at 20:37):

presumably that one would be followed by #[type] ? but I would prefer something that has a hope of resolving...

Ewout Kramer (Aug 19 2019 at 20:51):

Resolve to what? A html page which lists the primitives?

Grahame Grieve (Aug 19 2019 at 20:57):

something....?

Michel Rutten (Aug 19 2019 at 21:00):

An html page that explains about the system types, their usage and how they differ from FHIR primitive types.

Grahame Grieve (Aug 19 2019 at 21:16):

well, maybe not that far...

Bryn Rhodes (Aug 19 2019 at 22:00):

http://hl7.org/fhirpath/types/System.String

Grahame Grieve (Aug 19 2019 at 22:02):

that doesn't resolve, does it? can we make it resolve? And what do I do with the uri type? (the string variants)

Bryn Rhodes (Aug 19 2019 at 23:19):

It doesn't resolve right now, but we could make it resolve

Bryn Rhodes (Aug 19 2019 at 23:19):

Create a page for each type and auto-resolve the html

Bryn Rhodes (Aug 19 2019 at 23:22):

For the string variants, I think we would need to introduce new base types to cover them.

Grahame Grieve (Aug 19 2019 at 23:50):

I’m concerned that this is the tail wagging the dog. Do we have a use for these types in fhirpath per se?

Bryn Rhodes (Aug 20 2019 at 01:08):

Not currently no. Same with CQL, though there have been a few times I wished for a URI type. Nothing a higher-level model couldn't introduce though.

Bryn Rhodes (Aug 20 2019 at 01:11):

Is there a reason the value element of the FHIR.uri type can't be just a string?

Grahame Grieve (Aug 20 2019 at 04:41):

No, in fact, you’re right. I should go about this differently so that I don’t need to use uri at that level

Grahame Grieve (Aug 20 2019 at 06:23):

so our change here impacts on sdf-19:

url.startsWith('http://hl7.org/fhir/StructureDefinition') implies (differential.element.type.code.all(hasValue() implies matches('^[a-zA-Z0-9]+$')) and snapshot.element.type.code.all(hasValue() implies matches('^[a-zA-Z0-9]+$')))

Grahame Grieve (Aug 20 2019 at 06:24):

should I take it as read that we approve changing this to say:

Grahame Grieve (Aug 20 2019 at 06:26):

differential.element.type.code.all(hasValue() implies (matches('^[a-zA-Z0-9]+$') or matches('^http:\/\/hl7\.org\/fhirpath\/System\.[A-Z][a-z]+$'))) and snapshot.element.type.code.all(hasValue() implies (matches('^[a-zA-Z0-9]+$') or matches('^^http:\/\/hl7\.org\/fhirpath\/System\.[A-Z][a-z]+$'))) ?

Bryn Rhodes (Aug 20 2019 at 07:08):

Is the extra circumflex in the last regex a typo?

Bryn Rhodes (Aug 20 2019 at 07:09):

And does it matter that this is more restrictive than the previous sdf-19 in that it applies to all StructureDefinitions, not just FHIR-defined StructureDefinitions?

Michel Rutten (Aug 20 2019 at 08:33):

Does the new invariant allow sufficient flexibility for logical models?

Grahame Grieve (Aug 20 2019 at 20:58):

I cut off the first bit; the scope can't change. And the new bit doesn't change how logical models work.

Grahame Grieve (Aug 22 2019 at 20:32):

@Bryn Rhodes date types are a problem with using FHIRPath types for the special elements; the FHIRPath date types do not have the precision flexibility that the FHIR types do

Bryn Rhodes (Aug 23 2019 at 14:54):

Do they not? FHIRPath date types support partial date/time values, from year down to second/millisecond, just like FHIR and CQL

Grahame Grieve (Aug 23 2019 at 20:11):

really? where is that stated?

Chris Moesel (Aug 23 2019 at 21:02):

In the 1.0 spec, it's implied in parts that talk about "partial date/time values" and made somewhat explicit here (although it's less explicit for the time part): http://hl7.org/fhirpath/#datetime

In the last ballot, the description and examples of DateTime show it can be partial: http://hl7.org/fhirpath/2019May/index.html#datetime

In both cases, the formal grammar makes it clear (well, clear for people who understand ANTLR4 grammars anyway):

DATETIME
        : '@'
            [0-9][0-9][0-9][0-9] // year
            (
                '-'[0-9][0-9] // month
                (
                    '-'[0-9][0-9] // day
                    (
                        'T' TIMEFORMAT
                    )?
                 )?
             )?
             'Z'? // UTC specifier
        ;

TIME
        : '@' 'T' TIMEFORMAT
        ;

fragment TIMEFORMAT
        :
            [0-9][0-9] (':'[0-9][0-9] (':'[0-9][0-9] ('.'[0-9]+)?)?)?
            ('Z' | ('+' | '-') [0-9][0-9]':'[0-9][0-9])? // timezone

Grahame Grieve (Aug 23 2019 at 21:03):

actually, it is clear. I must have looked at the wrong version. thx

Grahame Grieve (Aug 27 2019 at 00:40):

ok, this is now all published on build.fhir.org for people to review

Ewout Kramer (Sep 02 2019 at 13:12):

Why do we still need:

 <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fhir-type">
          <valueCode value="string"/>
        </extension>

on these nodes?

Ewout Kramer (Sep 02 2019 at 13:16):

And I think using "fhirpath" in that path on something that already existed in ELM/CQL for a long time is an anachronism which I do not like. Does the "main" definition from System.String come from the CQL documentation or the FhirPath documentation? If CQL also starts referring to this as "fhirpath" primitives, won't that be confusing?

Grahame Grieve (Sep 02 2019 at 19:31):

I still need to know the implied FHIR type of the element. The underlying system type is not differentiated enough.

Grahame Grieve (Sep 02 2019 at 19:31):

I don't understand the other point

Last updated: Apr 12 2022 at 19:14 UTC