FHIR Chat · How to constrain the coding.display to preferred value(s)? · implementers

Stream: implementers

Topic: How to constrain the coding.display to preferred value(s)?

David Simons (Oct 07 2021 at 18:42):

Since codesystems often allow for alternate display strings for a given code, using fixedString on display is too constraining... so I am trying defaultValueString instead: (bottom of snippet)

  <differential>
    <element id="Observation.code.coding">
      <path value="Observation.code.coding" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="code" />
        </discriminator>
        <rules value="open" />
      </slicing>
    </element>
    <element id="Observation.code.coding:loincCoding">
      <path value="Observation.code.coding" />
      <sliceName value="loincCoding" />
      <min value="1" />
      <max value="1" />
    </element>
    <element id="Observation.code.coding:loincCoding.system">
      <path value="Observation.code.coding.system" />
      <fixedUri value="http://loinc.org" />
    </element>
    <element id="Observation.code.coding:loincCoding.code">
      <path value="Observation.code.coding.code" />
      <fixedCode value="47092-2" />
    </element>
    <element id="Observation.code.coding:loincCoding.display">
      <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-translatable">
        <valueBoolean value="true" />
      </extension>
      <path value="Observation.code.coding.display" />
      <defaultValueString value="Natriuretic peptide B [Moles/volume] in Serum or Plasma" />          *** fixedString replaced by defaultValueString
    </element>

however in R4, this is giving an error: sdf-21 Default values can only be specified on specializations, because our derivation is typically a constraint, nor a specialization.

**what is the rationale for sdf-21, and more importantly the recommended way to specify one or multiple preferred display string(s)?
**
my last resort is to leave the display out, fully, but I prefer to give guidance on the preference.

Lloyd McKenzie (Oct 07 2021 at 19:15):

Generally you don't constrain 'display' at all - you allow that to be handled by terminologyServices. "default" values aren't allowed to be set except in logical models.

David Simons (Oct 08 2021 at 07:31):

Thank you Lloyd - yeah - I will look into doing it via the ValueSet binding, and underlying CodeSystem indeed, incl. translations and designations. Not trivial :) Terminology Services - to find and validate the display for a code - may not always be available design-time.

Lloyd McKenzie (Oct 08 2021 at 16:27):

True - but if you're going to do anything with display names, the most you can realistically do is spit out a warning if it varies from the collection of names known to the terminology server. You can't specify defaults (for display or anything else) and you don't want to specify a fixed value. If you don't have a terminology server to check it, then your alternative is to leave it wide open. (Which essentially it is anyhow because you can always have a language translation or a narrow value set that overrides the display name with something context-specific. Validation is, at most, a warning.)

David Simons (Jan 10 2022 at 12:50):

Is there any way to include a human-readable comment/hint (derived from the display text) along with the system::code constraints, about what the code is about? (when removing the display constraint, this is no longer obvious to a human, looking at the profile alone)

image.png

There's a few options - which one would be recommended?
image.png

I'm leaning toward label and comment, to explain the fixedCode.

Lloyd McKenzie (Jan 10 2022 at 15:40):

'label' is what you use to prompt a human to fill in the element - which isn't something I'd expect if the Coding is already fixed/expected to follow a pattern. If you're declaring a pattern that asserts a particular code and you want to document what the code actually means, ElementDefinition.comment is probably the best place for that.

David Simons (Jan 10 2022 at 16:01):

Thank you - ElementDefinitions.comment it is :)

David Simons (Jan 10 2022 at 20:23):

Of course - this will not be validated since it is human readable. At least, I don't think there is a way to do so, readily.

image.png

Lloyd McKenzie (Jan 11 2022 at 04:27):

If you want to mandate a particular display value, you can include it in the pattern. If you want to constrain to one of a small set, you can bind a required value set to the display element. If you want to spit out a warning if it's not part of a small set, you can provide an extensible binding or a warning or best practice invariant.

David Simons (Jan 11 2022 at 08:27):

yeah, a defaultString (recommended) next to a fixedString (mandatory) option would have been useful here - to avoid valuesets and bindings - but then we're back to the beginning of the thread :)
Thank you Lloyd!

Lloyd McKenzie (Jan 11 2022 at 15:01):

defaults aren't allowed in FHIR (logical models only). However a default and a fixed value on the same element would never make sense as fixed says "this must appear on the wire" and default says "if nothing is specified, presume this".

Last updated: Apr 12 2022 at 19:14 UTC