Stream: fhir/infrastructure-wg
Topic: Constraining out element properties in a differential
Lloyd McKenzie (Feb 14 2022 at 21:50):
On today's FHIR-I call, we spent a good chunk of time discussing FHIR#20385, which proposes a mechanism to allow certain element properties (or property repetitions) to be removed from the snapshot by setting flags in the differential. The specific elements to be controlled are StructureDefinition.mapping and ElementDefinition.code, comment, requirements, alias, example, and mapping. Further discussion to take place here.
Jose Costa Teixeira (Feb 15 2022 at 07:44):
taking mappings as example: would the flag be "remove all mappings" or would we have a way to say "remove all mappings that meet this condition"? Or would we apply the flag to each mapping we want to remove?
Lloyd McKenzie (Feb 15 2022 at 15:19):
Proposal is 3 options - remove all mappings, remove all mappings with a particular id (e.g. all v2, all CDA, etc.) or remove a specific mapping from a specific element. (Mapping is the only one where you can remove all with a particular id, as the other candidates for removal don't share an id across elements.)
Ward Weistra (Mar 01 2022 at 13:22):
Forge currently has a setting whether to inherit the mapping definitions in the profile metadata (not diff/snapshot) from a parent profile: image.png
Other than that these extensions will have impact on the snapshot generator and rendering engine. @Marten Smits, what are your thoughts?
Marten Smits (Mar 01 2022 at 13:33):
I'd prefer not to mess with snapshot generation functionality but adding extensions with flags like: "don't display" to the snapshot (using the differential).
Rendering tooling like in simplifier and the IG Publisher can then handle the display of those elements.
Messing with snapshot generation functionality is a terrible idea in my opinion, it's already too complicated as it is
Lloyd McKenzie (Mar 01 2022 at 14:51):
This is definitely not about "don't display", it's about "remove entirely" - we don't want the mappings, comments, examples, etc. to be in the differential at all - because they're "wrong" in the constrained context. I understand that snapshot generation is miserable, but would the proposed approach be that hard to implement?
Marten Smits (Mar 02 2022 at 09:23):
The snapshot generator is hard to maintain as a whole. Maybe this approach is not that complicated (I would have to take a deep dive into that code again) but this introduces new behaviour and mechanisms to an already complicated piece of software, which I thought was "normative" by now, or at least, it should be.
Removal of certain aspects of an ElementDefinition from the base currently only happens for ElementDefiinition.type I think, by always adding the entire list of types to the differential. Why not use that same approach for .code .mapping, .alias, and .example? Propably because it'll break already existing profiles?
I don't see the use case for comment and requirements entirely, they can just be overwritten by the differential now.
Btw, would this proposal be for all snapshot generation? Or only for R4B+?
Lloyd McKenzie (Mar 02 2022 at 17:17):
Snapshot generation is a 'process'. It doesn't get to be 'normative' :) StructureDefinition can't have breaking changes, but it can absolutely have new capabilities introduced. And the issue is that the absence of this new capability results in models that don't make sense. Seeing "alternate names" of 'Vital Signs" on a profile for a hemoglobin is a problem. So is seeing guidance about the use of 'Timing' or 'Period' in the Observation.effective comment when the profile has constrained the element to only use 'date'. Similar problems exist elsewhere. The solution to data elements that are outright wrong isn't "keep them and don't display them", it's "allow them to be removed".
There's no funky inheritance or slicing or other weirdness we have to worry about here. You simply run the snapshot process and, at the end, if there's an extension present that says 'wipe this', then you wipe it.
Marten Smits (Mar 03 2022 at 13:09):
I agree that this is "broken" in the current snapshots and I fully understand the use case.
I just think we need to be careful when it comes to altering snapshot generation logic. Especially since alterations may cause snapshots that users who are currently working on profiles or want to publish a new version (modelers/profilers) don't expect. This is not the case in the current use case since users actively have to add these extensions to trigger the removal, so I can agree to this.
Question I still have: where will this new feature be documented? And will it apply to all FHIR versions?
Last updated: Apr 12 2022 at 19:14 UTC
