Stream: implementers
Topic: Why no root label/code/requirements?
Alexander Henket (Jan 07 2021 at 10:05):
FHIR R4 StructureDefinition invariant sdf-9 says "In any snapshot or differential, no label, code or requirements on an element without a "." in the path (e.g. the first element)"
What's the rationale behind this? I'm constructing a logical model of a functional concept that has a SNOMED CT concept representing it. So why can I not state the SNOMED CT concept on the base?
Lloyd McKenzie (Jan 07 2021 at 15:45):
Metadata about the resource/model as a whole should go on the StructureDefinition, not on the root element.
Alexander Henket (Jan 08 2021 at 12:07):
I could agree for label and requirements, but code constitutes a binding suitable on the root element, not as metadata on the structuredefinition? In any case there does not seem to be a true counterpart for code in the StructureDefinition, other than element itself.
Lloyd McKenzie (Jan 08 2021 at 14:24):
The constraint came from https://jira.hl7.org/browse/FHIR-6040. At that point, StructureDefinition.keyword used to be called StructureDefinition.code. I agree that with the evolved name and definition of that element, it doesn't overlap with ElementDefinition.code. However, at this point, I don't think we can relax the constraint. What we could do is add a StructureDefinition.code - likely as an extension - that mirrors what's in Questionnaire.
Chris Grenz (Mar 20 2021 at 16:27):
@Alexander Henket Did you file an issue on this? Not being able to add a code on the root of a datatype profile means there's no way to for a type profile to apply a code to an SD element in a reusable way. Using SD.keyword (or an extension) means the code doesn't naturally inherit onto the profiled element.
Does "normative" mean we can't relax a constraint?
Lloyd McKenzie (Mar 20 2021 at 18:49):
We can relax a constraint conditionally based on a new element, but I don't think we can relax the constraint overall. @Grahame Grieve ?
Alexander Henket (Mar 21 2021 at 19:27):
Looking back in the issues @Chris Grenz I don’t believe I did. It’s still bothering me though so I hope we don’t have to be backward compatible with something that does not really work as intended
Chris Grenz (Nov 09 2021 at 20:13):
Just realized there's an internal conflict in the spec. In http://hl7.org/fhir/R4/elementdefinition.html#interpretation code is "optional" on the first element. Label (another sdf-9 restriction) is even recommended!
Chris Grenz (Nov 09 2021 at 20:15):
@Grahame Grieve - any comment on the normative change question from Lloyd? Can we remove a constraint from StructureDefinition?
Last updated: Apr 12 2022 at 19:14 UTC
