Stream: conformance
Topic: Extension value[x] element syntax
Sean McIlvenna (Jan 08 2019 at 23:05):
Can someone confirm the syntax for defining an extension's value[x] element?
Currently, I am using:
<element id="Extension.value[x]">
<path value="Extension.value[x]" />
<type code="CodeableConcept" />
<type code="Coding" />
</element>
However, reading the spec, I'm not sure that's correct. It mentions that the id and path should be different depending on the type. It also mentions that I should enumerate each of the types that are allowed in different elements with unique id's and path's. I've ALSO seen examples where the value uses slicing to indicate what the correct type is (with a sliceName).
So, now I'm not sure what the correct syntax is for an extension's value. Can someone show the correct syntax for an extension with a value limited to a single type, as well as an extension with a value allowing multiple types (but not all types)?
Sean McIlvenna (Jan 09 2019 at 23:35):
Looking at how Forge handles this... I see two different behaviors depending on whether a single type is allowed, or multiple types are allowed.
WIth a single type, this is produced:
<element id="Extension.value[x]:valueCodeableConcept">
<path value="Extension.valueCodeableConcept"/>
<sliceName value="valueCodeableConcept"/>
<type>
<code value="CodeableConcept"/>
</type>
</element>
With multiple types being allowed, this is produced:
<element id="Extension.value[x]">
<path value="Extension.value[x]"/>
<type>
<code value="code"/>
</type>
<type>
<code value="CodeableConcept"/>
</type>
<type>
<code value="Coding"/>
</type>
</element>
Rob Hausam (Jan 11 2019 at 22:27):
I'm interested in the details of this, too - for the IPS IG.
Sean McIlvenna (Jan 12 2019 at 15:15):
Maybe during the connectathon we can get a couple people together to answer this
Grahame Grieve (Jan 12 2019 at 16:29):
this looks like an evening subject this week to me
Sean McIlvenna (Jan 12 2019 at 19:43):
Sure
Sean McIlvenna (Jan 12 2019 at 19:50):
When and where?
Sean McIlvenna (Jan 12 2019 at 20:20):
@Grahame Grieve
Grahame Grieve (Jan 12 2019 at 20:41):
not decided yet. i'll advise
Michel Rutten (Jan 14 2019 at 12:35):
Note that R4 introduces new behavior for choice type constraints. The Forge example above describes the behavior as defined by STU3.
In STU3, choice types are renamed if (and only if) constrained to a single type. To constrain a choice type that allows multiple type options, STU3 requires an explicit slice (on type) and disallows element renaming. Forge enforces this behavior.
In R4, a profile is allowed to introduce multiple type-specific constraints on a choice type element, using renamed elements. Such constraints apply to the specified type only, and a profile can specify multiple of those for different type options. For example, an R4 profile can introduce both valueString and valueBoolean constraints on a value[x] element (w/o requiring explicit slice introduction).
At least, that's my current understanding - please correct me if I'm wrong.
Rick Geimer (Jan 16 2019 at 03:27):
Per discussion Tuesday night at the WGM, the rules are defined here:
http://hl7.org/fhir/elementdefinition.html#typesx
Rick Geimer (Jan 16 2019 at 03:28):
But we will file a tracker to add examples with explanatory text for this.
Last updated: Apr 12 2022 at 19:14 UTC
