Stream: implementers
Topic: necessity to mention BackboneElements
Georg Fette (Oct 09 2019 at 08:23):
When defining a custom profile as a new StructureDefinition, is it necessary to define the intermediate BackboneElements as explicit elements or can they be ommited and only their contained elements have to be listed ? Because the existence of the BackboneElements can be implicitely assumed, when there is a path to subelements.
Chris Moesel (Oct 09 2019 at 11:56):
You need to define it, because otherwise we don't know the cardinality (i.e., is it 0..1, 1..1, 0..*, etc). I also think we can't assume it is a BackboneElement, because it also could be a normal Element. I think the only difference is that BackboneElement allows modifierExtension -- so technically modelers could use either one depending on what they want to allow.
Michel Rutten (Oct 09 2019 at 12:03):
In a logical model, BackBoneElement nodes can introduce child elements. Element nodes contain a single value.
Michel Rutten (Oct 09 2019 at 12:04):
And yes, a logical model definition must explicitly introduce all parent elements. Only constraining profiles can be sparse.
Chris Moesel (Oct 09 2019 at 12:53):
In a logical model, BackBoneElement nodes can introduce child elements. Element nodes contain a single value.
@Michel Rutten -- I did not know that. Is that documented somewhere or is it a convention? I can't seem to find it in the docs, but I may be looking in the wrong place.
Michel Rutten (Oct 09 2019 at 13:01):
Good question... not sure if this is explicitly documented in the spec. But if you look at the profiles that define the FHIR core resources, you will notice the same pattern.
Michel Rutten (Oct 09 2019 at 13:03):
An ElementDefinition in a profile can either:
- Contain a primitive value => base
Element - Introduce child elements => base
BackboneElement - Reference an external type profile => base is the root element of the external profile
Last updated: Apr 12 2022 at 19:14 UTC
