Stream: IG creation
Topic: Derived profile snapshot missing upstream invariants
Rob Eastwood (Sep 09 2019 at 22:23):
Not sure if this is the most suitable stream.
Have noticed that a derived profile, derived from another profile, does not show the first profile's invariants in the 2nd profile's snapshot table. They are in the generated structure definition xml snapshot, just not rendered in the table. To demonstrate:
The HL7 AU R4 AU Base Organization Profile has a number of identifier slices most of which have invariants to control the quality of the identifier values. For example, the invariant inv-hpio-0 on the HPI-O slice.
A profile derived from the above profile, the HL7 AU Australian Organisation Directory Entry Profile includes a few constraints as demonstrated by its differential table view (noting that the identifier slice with the above invariant only has a must support). The differential of course does not display the invariant inv-hpio-0, but neither does the snapshot table, which was unexpected. However, the invariant is found in the generated snapshot and is shown on the detailed descriptions page.
This may be by design, but having searched in zulip, I could find nothing related. A few colleagues are of the view that this is a feature of the snapshot table to keep it simpler. So raising to clarify.
Also note that I have experienced the same rendering with other derived profiles, generated via the IG publisher v0.9.69.
Richard Townley-O'Neill (Sep 26 2019 at 04:39):
@Grahame Grieve Is supressing inherited invariants in Snapshot Tables a feature of the IG Publisher?
Is there a switch to turn supression off?
Lloyd McKenzie (Sep 27 2019 at 15:09):
It shouldn't be a feature unless it's warnings or "best practice" messages - and even then, it should be handled on an invariant by invariant baais
Richard Townley-O'Neill (Oct 08 2019 at 03:23):
I think that the snapshot view produced by ig publisher should show invariants inherited from other profiles.
The snapshot shows all inherited elements, their bindings and cardinalities etc. so I am surprised that the inherited invariants are not also displayed.
Richard Townley-O'Neill (Oct 08 2019 at 03:23):
@Grahame Grieve
Grahame Grieve (Oct 08 2019 at 03:24):
because every element ever has invariants, and displaying them was overwhelming.
Richard Townley-O'Neill (Oct 08 2019 at 04:44):
I have just noticed that the StructureDefinition of the R4 build of ClinicalDocument has 13 constraints while the current build of ClinicalDocument has 67. The R4 one includes ele-1 for only a few elements, while the newer one has ele-1 on very many elements.
I assume that the newer one is correct.
Displaying ele-1 on every element would be overwhelming.
Richard Townley-O'Neill (Oct 08 2019 at 04:55):
#24911 raised to clarify in docco that inherited constraints are not displayed in the snapshot tab.
Michel Rutten (Oct 08 2019 at 12:25):
Note that the SnapshotGenerator implementation in the FHIR .NET API includes all element constraints inherited from base profile & type profiles into the generated snapshot. Almost all elements inherit Invariant ele-1 from base class Element and the generated snapshot reflects that.
Michel Rutten (Oct 08 2019 at 12:27):
The validator actually needs all these invariants, so the snapshot must contain them. For display purposes, rendering logic could hide some "noisy" constraints, depending on the intended target audience.
Brian Postlethwaite (Jan 30 2020 at 03:37):
The profiles in my IG don't have snapshots, so it's the IG Publisher creating them, and I'm now seeing ele-1 etc for every element...
Brian Postlethwaite (Jan 30 2020 at 03:41):
https://mysl-hl7-sydney.azurewebsites.net/ig/StructureDefinition-mysl-patient.html
Grahame Grieve (Jan 30 2020 at 04:42):
that's a change I made months go as part of reconcilation with the dotnet snapshot generator
Grahame Grieve (Jan 30 2020 at 04:42):
I don't like it, and neither do others
Brian Postlethwaite (Jan 30 2020 at 04:57):
Something I could contribute to in the publisher?
Brian Postlethwaite (Jan 30 2020 at 04:59):
I hadn't fussed over it as I hadn't had any self defined ones in the profiles I'd been putting together, now they are lost in the sea of ele-1s
Grahame Grieve (Jan 30 2020 at 05:15):
hmm they shouldn't appear in the rendering like that
Grahame Grieve (Jan 30 2020 at 05:16):
what xhtml fragment are you including for that
Brian Postlethwaite (Jan 30 2020 at 05:18):
{% include {{[type]}}-{{[id]}}-inv.xhtml %}
Brian Postlethwaite (Jan 30 2020 at 05:27):
Just peeking in another that was built recently, looks the same.
http://build.fhir.org/ig/HL7/fhir-mCODE-ig/branches/master/StructureDefinition-CancerPatient.html
Grahame Grieve (Jan 30 2020 at 06:12):
ok. from next release, the parameter show-inherited-invariants in either the json or the ig will control whether these inherited constraints appear. show-inherited-default value is true (default is no change)
Brian Postlethwaite (Jan 30 2020 at 23:06):
Thanks, works like a charm.
Brian Postlethwaite (Jan 30 2020 at 23:07):
For those that want to see, here's an example
https://mysl-hl7-sydney.azurewebsites.net/ig/StructureDefinition-mysl-consent.html
Last updated: Apr 12 2022 at 19:14 UTC
