Stream: conformance
Topic: Choice type element renaming
Michel Rutten (Sep 27 2017 at 13:32):
I have a question about element renaming.
FHIR states that if a profile constrains a polymorphic choice type element (e.g. "value[x]") to a single type, then the profile
SHOULD|SHALL rename the element by replacing the "[x]" suffix with the name of the selected datatype (e.g. "valueString").
Questions:
- Is it mandatory for a profile that constrains a choice type element to perform the renaming ("value[x]" => "valueString")? i.e. SHALL, not SHOULD?
- Is it mandatory for a derived profile that further constrains an choice type constraint to specify the new element name ("valueString")?
Note that if FHIR chooses to define element renaming as optional, then it becomes more difficult to match profile constraints to the base profile; if element renaming is not consistent throughout derived profiles, the snapshot generator logic may have to fall back to inspecting and comparing the actual element type constraints.
Example of layered choice type element constraints with inconsistent element renaming:
0) FHIR Core resource: Observation.value[x]
1) User base profile: Observation.valueString, type.code = "string"
2) User derived profile: Observation.value[x], type.code = "string", max = 1
From a tooling implementer perspective, I'd prefer if FHIR would define element renaming as mandatory, as this reduces implementation complexity. However considering we need to gracefully handle a large set of existing profiles that may not adhere to this rule, I guess tools will have to handle this anyway and my question is rather academic...?
Lloyd McKenzie (Sep 27 2017 at 15:10):
@Chris Grenz @Grahame Grieve ?
Eric Haas (Sep 27 2017 at 15:17):
I would expect once a valueString always a valueString - that is the intent of the profile so any profile derived from it should strictly adhere to that.
Michel Rutten (Sep 27 2017 at 15:17):
Yes, that's what I would expect. But is it guaranteed/mandatory?
Chris Grenz (Sep 27 2017 at 18:03):
In earlier versions this was a bit ambiguous. Now (I think) we've clarified and there's no optionality:
- value[x] constrains all types using this choice.
- valueString is a type slice of value[x] and only constrains string instances of value[x]
In terms of inheritance (profile to base), the paths must match. So, in @Michel Rutten 's example, 2) is a constraint of 0) and not 1).
Chris Grenz (Sep 27 2017 at 18:04):
Some things to note:
- In Michel's example, 1) is effectively a no-op since valueString is by definition a type slice of value[x] for string types.
- 2) would limit value[x] to only strings. 1) would not limit the available types
Chris Grenz (Sep 27 2017 at 18:07):
See GF#12259 for resolution on this topic.
Michel Rutten (Sep 28 2017 at 09:14):
Hi @Chris Grenz, thank you for the clarification.
Your proposal makes perfect sense. I seem to remember that we discussed this during a FHIR-I evening session and reached consensus that this is how
we want to proceed towards R4.
So I agree that Future R4 implementations should adhere to your description above. However I'm not sure if this already applies to STU3 implementations?
For our FHIR tools, we're trying to strike a balance between backwards and forwards compatibility. The tools should maintain to support existing profiles that users have created, published to Simplifier and taken into production.
We try to be forgiving when reading data (e.g. fix/auto-correct if possible) and strict when generating (i.e. conform to the spec). If I update the API snapshot generator to strictly follow your rules, then this could break some existing profiles with choice type element constraints.
Specifically this comment of yours: "2) would limit value[x] to only strings."
I understand the subtle difference and agree on this for R4. However I don't think that we can expect any STU3 FHIR user to be aware of this rule, as this wasn't clearly defined yet during STU3 publication. Therefore I'm quite reluctant to introduce this (new) interpretation in existing STU3 logic...
Chris Grenz (Sep 28 2017 at 12:41):
I'm not sure what STU3 users should/would expect in these situations. I always interpreted the standard in the R4 way and was surprised that Grahame has a different approach. In your example, by Grahame's logic, 1) limits the type to strings only and 2) would then be further constraining valueString to max=1.
@Grahame Grieve - what do you think Forge should do?
What's probably best would be to check the STU3 validators and see how they operate. And, look for STU3 official profiles and try to discern intent.
Grahame Grieve (Oct 03 2017 at 02:57):
we don't want needless variation. So it should be a SHALL - SHALL rename to valueString. and derived profiles SHALL use valueString. If they don't, the derivation is wrong.
Grahame Grieve (Oct 03 2017 at 02:58):
I don't know about R3, but the IG publisher is all R4, even when publishing old IGs, so we can just look ahead, I think
Michel Rutten (Oct 03 2017 at 10:33):
Thanks @Grahame Grieve,
Chris Grenz (Oct 03 2017 at 19:29):
To be crystal clear:
a) Extension.valueString is not a valid id.
b) The presence of Extension.value[x]:valueString alone does NOT constrain valid types for value[x].
Chris Grenz (Oct 03 2017 at 19:31):
If an element is defined with path: "Extension.valueString", it SHALL be interpreted as id Extension.value[x]:valueString in R4. Personally I'd recommend this interpretation in R3 as well.
Michel Rutten (Oct 04 2017 at 09:33):
Still a bit concerned about incompatible interpretation difference inbetween STU3 and R4.
Ewout always assumed that a choice type element constraint with a renamed path (valueString) effectively restricts the allowed type choices to that single type. This interpretation does not affect the behavior of the .NET snapshot generator for STU3, as it will happily merge any constraints it encounters, regadless of wether they are actually valid or not; that is up to the validator to determine. However it definitely affects the implementation of the .NET validator.
I think that the current STU3 .NET validator interprets a constraint on a renamed choice type element (valueString) to implicitly restrict the set of allowed type options to the specified single type.
It appears that this behavior is now different from the behavior of the IG publisher with R4 interpretation...?
Grahame Grieve (Oct 04 2017 at 10:13):
umm, what's the difference?
Michel Rutten (Oct 04 2017 at 11:17):
If I understand correctly:
-
STU3 (as currently implemented by .NET validator):
A constraint on renamed choice type element (e.g.valueString) is interpreted to limit the type choices. So the validator will reject all other types. -
R4 (as currently implemented by IG Publisher)
A constraint on renamed choice type element (e.g.valueString) is interpreted to further restrict that specific type. It does NOT limit the valid type options. So the validator will accept other types (introduced by the base profile).
Chris Grenz (Oct 05 2017 at 13:52):
I agree with your understanding @Michel Rutten . The R3 validators selected one possible interpretation which is now at odds with R4.
Grahame Grieve (Oct 05 2017 at 19:40):
hmm. I'll add a test for this. note, though, that the main validator, we ask people to use the R4 validator now
Michel Rutten (Oct 09 2017 at 08:45):
Thanks for the feedback. I'll discuss this with Ewout, as he is responsible for the implementation of the .NET validator.
Last updated: Apr 12 2022 at 19:14 UTC
