Stream: conformance
Topic: type profiles (#9791)
Chris Grenz (Jun 07 2016 at 14:31):
Stream to discuss GF#9791.
Chris Grenz (Jun 07 2016 at 14:44):
To recap the FHIR-I call:
When applying a type profile to an element (setting elementdefinition.type.profile), one of these scenarios applies:
1. New @profile discriminated slicing - Effectively defining a new element specialization.
2. New slice discriminated by other elements (not @profile) and constrained by @profile.
3. Type profile added to existing slice.
4. Type profile added to un-sliced element.
In all scenarios, for element definition elements that aggregate (constraint, mapping, alias), both the element base and the type profile must be represented, and de-duplication should be applied (since mappings on the base types will be inherited from both the element and type profile lineages).
For elements with only 1 value that are calculable (min, max, maxLength, minValue[x], etc), both must be considered.
For elements with only 1 value that cannot be programmatically merged (label, short, comments, etc), which lineage should be used?
For 1, it was unanimous that all elementdefinition (ED) elements should be based on the type profile.
For 2, general sentiment was that the type profile should be used. Common use cases here are extensions since they are discriminated by url and constrained by type profile. However, since the type profile is not the defining aspect of the slice (it's not the discriminator), there is some question.
For 3, I think this would be treated like 4 since it's not defining anything new but rather constraining something existing.
For 4, the base element would be used since the type is not re-defining, only constraining.
Lloyd McKenzie (Jun 08 2016 at 02:48):
Agree on all counts
Michel Rutten (Jun 08 2016 at 09:00):
Very interesting discussion! As it happens, I was just looking at how to merge mappings on (unsliced) elements with a profiled type. Then Ewout informed me about the current discussion. If the community can reach concensus on these advanced merging rules, then I can try and implement them piece by piece in Forge, to determine if/how it works.
Michel Rutten (Jun 08 2016 at 09:05):
For example, The Observation resource profile also defines element mappings on Observation.identifier, e.g. a v2 mapping to "OBX.21". The Identifier datatype profile also defines element mappings on the "identifier" root element, e.g. v2 mapping to "CX / El". So does the Observation.identifier element definition (implicitly) inherit these additional mappings from the Identifier profile? In other words, when expanding the snapshot, do I need to merge the mappings from the element definition in the Observation resource profile with the mappings from the element definition in the Identifier datatype profile?
Chris Grenz (Jun 08 2016 at 13:43):
Yes?
Michel Rutten (Jun 08 2016 at 13:46):
OK, thx ;p
Chris Grenz (Jun 08 2016 at 13:47):
A mapping (or alias, or constraint) on a base type gets propagated *all over*.
Chris Grenz (Jun 08 2016 at 13:48):
I'm not sure that the implications of annotating one of the types or Element or Resource was always fully appreciated. Or maybe it was and that was always intended.
Chris Grenz (Jun 08 2016 at 13:48):
The rim n/a mapping is going to be on lots and lots of elements.
Michel Rutten (Jun 08 2016 at 13:54):
I was just wondering if it makes any sense to have different mappings on an element for the same system, as in the Observation.identifier example I mentioned, which would aggregate two different v2 mappings to both "OBX.21" and also to "CX / El". I can image how multiple mappings express information on a different abstraction/specialization level, but since I am no mapping expert I can't really tell. Thanks for the feedback.
Michel Rutten (Jun 08 2016 at 13:57):
Also I guess, since profile and element mappings always are implicitly inherited (from multiple levels...), that it makes no sense for Forge to let the user edit any of the inherited mapping components. The rules state that the profile inherits all the original mappings anyway. So maybe Forge should render inherited profile mapping components in the UI as read-only? i.e. the user can only extend the collection, but not edit any of the implicitly inherited collection items.
Chris Grenz (Jun 08 2016 at 13:58):
Yes, for any of the "aggregable" elements (mapping, constraint, alias) you can only add.
Michel Rutten (Jun 08 2016 at 14:04):
@Chris Grenz That makes sense. I'll try to implement the correct behavior in Forge. Thanks a lot for clearing this up!
Last updated: Apr 12 2022 at 19:14 UTC
