FHIR Chat · SUSHI not setting coding.display values

Stream: shorthand

Topic: SUSHI not setting coding.display values

Noemi Deppenwiese (Jan 31 2020 at 15:09):

In my code, i have

* code ^patternCodeableConcept.text = "Days on Ventilator"
* code ^patternCodeableConcept.coding = LOINC#74201-5 "Days on Ventilator"

which is translated to

"patternCodeableConcept": {
          "text": "Days on Ventilator",
          "coding": [
            {
              "code": "74201-5",
              "system": "http://loinc.org"
            }
          ]
        },

So, the display value for the coding is not generated?

Chris Moesel (Jan 31 2020 at 15:38):

So this is one of the opinionated aspects of FHIR Shorthand / SUSHI. If we include the display in the pattern, then we are saying that in order for an instance to conform (and validate successfully) against a profile, then it must include that exact "display" value as well. Usually, the intent w/ codes is the require a match on system and code, but not to require a match on display. This is why we leave it out of the pattern.

Noemi Deppenwiese (Jan 31 2020 at 15:39):

Ok, thanks for the explaination!

Chris Moesel (Jan 31 2020 at 15:43):

That said, it is opinionated and I think you're not the first person to ask about it. This brings up a few points we should probably discuss as a community:

Should Shorthand make the author be explicit about whether you want to fix using fixed[x] or pattern[x]? Currently, we use pattern[x] for fixing things like CodeableConcept, Coding, and Quantity and fixed[x] for fixing primitives (e.g., code, string, integer, etc). But perhaps we should be putting that in the hands of authors. Perhaps = could mean fixed and ~ or =~ could mean patterned.
Is it right for us to assume you don't want display in the pattern (for the reasons above)? Or should the author be in total control and if they don't want a display, they just don't put a display in the fixed value?

Noemi Deppenwiese (Jan 31 2020 at 15:50):

Is it right for us to assume you don't want display in the pattern (for the reasons above)? Or should the author be in total control and if they don't want a display, they just don't put a display in the fixed value?

I would argue that there are cases when a profile might reasonable want a fixed display value. E.g. the FHIR resources are to be processed by another program that does not have access to a terminology service but requires a "text" to go with codings. Setting the cardinality to 1..1 might not suffice since there could be several display values for a code, e.g. translations.

Chris Moesel (Jan 31 2020 at 15:55):

I think that's a fair argument. @Mark Kramer -- perhaps the questions I pose above are something you can discuss w/ others at the Connectathon as well? It would be nice to get some community consensus on this.

Eric Haas (Feb 02 2020 at 23:26):

I too noticed the display was absent in the instance I created. I don't think its related to patterns.

Chris Moesel (Feb 03 2020 at 00:07):

Oh -- in the instance? Yeah, that's a problem then. It's probably because we have a lot of shared code between fixing values in profiles and setting values in instances. Skipping display in instances is not by-design.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · SUSHI not setting coding.display values · shorthand