Stream: conformance
Topic: Element id for constrained choice type elements
Michel Rutten (Sep 28 2017 at 14:55):
Another question.
We've defined rules for generating a standard element id. For renamed choice type elements constrained to a single type, the convention is the generate an id that includes both the original and the new element name:
"{parent-path}.{original-element-name}:{new-element-name}"
For example: "Observation.value[x]:valueString"
The element id generator in the FHIR .NET API picks up the second part (after ":") from the sliceName property. So when the user constrains a choice type elements to a single type:
1. Forge determines the new element name, depending on the selected type
2. Forge updates the .path property to include the new element name
3. Forge initializes the .sliceName property with the new element name
4. Forge re-generates the element id from the new element name and sliceName
This actually introduces a sliceName value on an unsliced choice type element without a slice entry. Rick Geimer pointed out that this may be invalid...?
If FHIR does not allow assigning a slice name to an unsliced choice type element, then the element id generator would have to detect renamed choice type elements by inspecting ElementDefinition.Base.Path - which is generally unavailable in the differential...
Chris Grenz (Sep 28 2017 at 16:12):
Type choices are implicitly sliced by type with slices for each allowed type. In other words, it is NOT valid to directly slice value[x]. You may reslice one of the existing slices: Extension.value[x]:valueCoding/loinc-slice
Michel Rutten (Oct 02 2017 at 13:00):
Hi @Chris Grenz, thank you for chipping in. Do you mean that my current approach is invalid, i.e. it is NOT allowed to initialize the sliceName property for a renamed choice type element? So instead, I should explicitly leave sliceName empty and generate the correct element Id using different means.
Chris Grenz (Oct 02 2017 at 13:07):
valueString is already a slice of value[x]. A slice then would actually be a re-slice of valueString:
Extension.value[x]:valueString/mySlice
Michel Rutten (Oct 02 2017 at 13:11):
Following your interpretation, so if we consider valueString to be an (implicit) slice on value[x], then FHIR dictates we SHALL initialize the sliceName property, in this case to "valueString"?
In other words, my current logic is correct and I should report back to Rick that this approach is actually valid/mandatory?
Chris Grenz (Oct 02 2017 at 13:31):
I'd say to be consistent, the snapshot should include valueString as slice name for the type slice. This could not be modified in the differential (similar to the discriminator on Resource.extension)
Michel Rutten (Oct 02 2017 at 14:43):
Great, then I don't need to change my current logic! ;p
Thank you for your help. I'll inform Rick about our discussion.
Sean McIlvenna (Oct 02 2017 at 16:19):
Trying to follow this.. It doesn't entirely make sense to me. What is the approach we are concluding, to indicate in a profile that value[x] SHALl be valueString? (limiting the selection of value[x] to JUST valueString). There are two criteria that I can think would be considered:
1) what type is allowed by value[x]? (how do you limit the selection of type to one or just a few types?)
2) is value[x] required? (how do you indicate that value[x] is required, even if the options are limited to a smaller subset)?
Chris Grenz (Oct 02 2017 at 18:01):
@Sean McIlvenna valueString is a slice (an implicit type slice) of value[x]. In STU3 there's some ambiguity about this and that ambiguity will be resolved in R4. Some implementations in R3 interpreted the presence of valueString to be a constraint on value[x] limiting all instances to string. Some did not. Directly to your questions:
1) the type element of ElementDefinition on the value[x] declaration limits the valid types. To further constrain allowable types, restate the type block in a differential for the value[x] element.
2) making value[x] required means adding min=1 (or more) to the value[x] element.
Sean McIlvenna (Oct 02 2017 at 18:17):
So it sounds like for both of these scenarios, all that needs to exist is:
<element id="Observation.value[x]">
<min value="1" />
<type>
<code value="Quantity" />
</type>
<type>
<code value="string" />
</type>
</element>
Sean McIlvenna (Oct 02 2017 at 18:18):
It sounds like what you're saying is that slices are NOT needed/desired to represent this scenario...
Chris Grenz (Oct 02 2017 at 18:19):
Makes the value mandatory and of type String or Quantity. As stated, this will work in all validators.
Sean McIlvenna (Oct 02 2017 at 18:20):
So, I don't think this is the same way that @Michel Rutten is doing this... @Michel Rutten , can you confirm?
Michel Rutten (Oct 03 2017 at 10:31):
Hi @Sean McIlvenna, Forge supports both. If you constrain value[x] to a single type, then the element is renamed to e.g. valueString. But if you specify multiple type constraints, then the element retains the original name e.g. value[x].
Sean McIlvenna (Oct 03 2017 at 15:00):
@Michel Rutten , So when does Forge decide to create a slice out of the choice?
Michel Rutten (Oct 03 2017 at 15:10):
The user decides, by clicking on the "slice" button. Then Forge creates an actual slice entry and allows you to add slices. Forge detects when you slice a choice type element and automatically initializes the slicing discriminator for a type slice to { Type = "Type", Path = "$this" }. The user should make sure that all the slices have different type constraints, Forge does not validate this (yet).
Michel Rutten (Oct 03 2017 at 15:13):
Constraining a choice type element to a single type is considered an "implicit slice". This causes the element to be renamed, but it does not introduce an actual slice entry (in both differential and snapshot).
Michel Rutten (Oct 03 2017 at 15:18):
Note that if you constrain a slice of a choice type element to a single type, Forge maintains the original element name. Element renaming only applies if a choice type element is constrained to a single datatype (and not sliced).
Chris Grenz (Oct 03 2017 at 19:49):
Why would the element be "renamed" due to the presence of a type slice? It should just have a sliceName of the reserved name (valueString).
Last updated: Apr 12 2022 at 19:14 UTC
