Stream: IG creation
Topic: Tooling Differences that cause problems
Lisa Nelson (Nov 07 2019 at 13:26):
Summary of technical issue:
We found there are structure differences between Forge and Trifolia when displaying the element in the differential view.
In Trifolia, the root element is required in order to display in the differential view. For example, the bodysite element below is present in the Trifolia xml output of the StructureDefinition differential view information:
<element id="Observation.bodySite">
<path value="Observation.bodySite"/>
</element>
<element id="Observation.bodySite.coding">
<path value="Observation.bodySite.coding"/>
<min value="1"/>
<max value="1"/>
</element>
<element id="Observation.bodySite.coding.system">
<path value="Observation.bodySite.coding.system"/>
<min value="1"/>
<fixedUri value="http://snomed.info/sct"/>
</element>
<element id="Observation.bodySite.coding.code">
<path value="Observation.bodySite.coding.code"/>
<min value="1"/>
<binding>
<strength value="required"/>
<valueSet value="http://www.ama-ihmi.org/fhir/ValueSet/AMA-IHMI-valueSet-body-structure-1-instance"/>
</binding>
</element>
<element id="Observation.bodySite.coding.display">
<path value="Observation.bodySite.coding.display"/>
<min value="1"/>
</element>
The element Observation.bodySite is in the list of element in Trifolia, but it is missing in the corresponding StructureDefinition resource generated by Forge. Forge doesn't require a root element to be in the list in order to display in the differential view.
Forge says:
The Forge team reports that the way they are expressing the structure is permitted by the spec.
Lantana says:
They are following the guideline in the spec, citing that the spec implies that the parent element must be asserted:
See https://www.hl7.org/fhir/profiling.html#using
Where it indicates "A structure definition contains a linear list of element definitions. The inherent nested structure of the elements is derived from the path value of each element. For instance, a sequence of the element paths like this:"
Further-more, it indicates "The structure is coherent - children are never implied, and the path statements are always in order. The element list is a linear list rather than being explicitly nested because element definitions are frequently re-used in multiple places within a single definition, and this re-use is easier with a flat structure."
We, the FHIR Accelerator team at Gravity, are stuck between our tooling vendor’s. We need to work with the Forge team and Trifolia team to collaborate and address this inconsistency. If the intention is for SturctureDefinition resources to be interoperable between systems, it seems like being explicit in the inclusion of all structural elements would be better approach.
Any advice on how to get this resolved? We are blocked by this issue.
Lisa
Lloyd McKenzie (Nov 07 2019 at 15:33):
The structure definition is coherent, but that doesn't mean that the differential can't be sparse. The intention is that differentials can be sparse. The HL7 tool suite struggled with this for years, but now supports it properly (we believe - thanks @Grahame Grieve :) ). Needing to list ancestor elements to constrain a child doesn't add value, just overhead and isn't algorithmicly required. So Trifolia should also support sparse differentials. It's certainly going to start seeing those in IGs it will need to constrain (e.g. US Core).
Ward Weistra (Nov 07 2019 at 15:53):
@Rick Geimer @Sean McIlvenna Is this something you can resolve on the Trifolia side to help Gravity proceed?
Sean McIlvenna (Nov 07 2019 at 16:59):
@Ward Weistra , I have this on my list of todo in the next couple weeks.
Sean McIlvenna (Nov 07 2019 at 16:59):
It was just brought to my attention a couple days ago
Sean McIlvenna (Nov 07 2019 at 16:59):
I think we can address this, but it will take a bit of time to figure out
Ward Weistra (Nov 07 2019 at 17:30):
Thanks @Sean McIlvenna, that's great to hear.
@Lisa Nelson Is this going to work with your timeline for Gravity?
Grahame Grieve (Nov 07 2019 at 19:48):
@Lisa Nelson note this text from the next section:
(note that this means that a differential profile can be sparse and only mention the elements that are changed, without having to list the full structure. This rule includes the root element - it is not needed in a sparse differential)
Lisa Nelson (Nov 07 2019 at 21:08):
@Ward Weistra I think our workaround is a manual adjustment prior to importing the artifact generated by Forge. Not ideal, but it will be our approach until @Sean McIlvenna has time to get this addressed in Trifolia. Thanks to all for getting this cleared up.
Mirjam Baltus (Nov 07 2019 at 22:49):
@Corey Smith: Please take a look at this discussion, since I'm not sure my emails have reached you successfully, and this answers your questions.
Michel Rutten (Nov 08 2019 at 11:41):
FYI The first step of the SnapshotGenerator in the .NET API library is to complete the differential by adding missing parent elements. Such a preprocessing step is trivial to implement and simplifies downstream logic.
Last updated: Apr 12 2022 at 19:14 UTC
