Stream: ig publishing requirements
Topic: Notes for IG requirements
Lloyd McKenzie (May 10 2019 at 03:38):
https://docs.google.com/document/d/1cVSxI3cUHDiuAMgRiXJZtXUlWiqbLcmRz_-AyehhCDE
Grahame Grieve (May 10 2019 at 09:40):
we will have to figure out which of these things are publication requirement, and which are just decisions about how we're going to do things.
Grahame Grieve (May 10 2019 at 09:41):
but there is a way for Simplifier to collapse the difference - @Ewout Kramer and I spoke about that at this meeting
Brian Postlethwaite (Jun 25 2021 at 03:43):
With the invariants section, could we have a version that ignores the "core" ones?
something like I've done with this IG here:
https://fhir.medicationknowledge.com.au/dev/StructureDefinition-mysl-patient.html
image.png
Brian Postlethwaite (Jun 25 2021 at 03:43):
It then means you can see any locally defined constraints without being bombarded by all the 1000 core ones.
(and the note underneath that they all still apply)
Brian Postlethwaite (Jun 25 2021 at 03:44):
I have a post processing step on my local IG building process that "prunes" out these specific ones from the table.
Grahame Grieve (Jun 25 2021 at 03:59):
how do you decide which ones?
Brian Postlethwaite (Jun 25 2021 at 04:00):
My routine explicitly picks those in the note and strips those out - just that set from core
Interested if others have any thoughts too.
Grahame Grieve (Jun 25 2021 at 04:10):
you just want the invariants on the diff, right?
Brian Postlethwaite (Jun 25 2021 at 04:30):
In this case it would cover it yes, and I think we should definitely have a fragment for that (and I probably would have just used it if it was there already)
Brian Postlethwaite (Jun 25 2021 at 04:31):
It's just those real core ele-1 and ext-2 ones across EVERYTHING make what you need to see impossible.
Grahame Grieve (Jun 25 2021 at 04:36):
so the next release will also generate an {x}-inv-diff as well as an {x}-inv file, and the inv-diff file will be generated from the differential
Brian Postlethwaite (Jun 25 2021 at 05:00):
The current code already produces the {x}-inv file right?
Grahame Grieve (Jun 25 2021 at 05:24):
yes
Elliot Silver (Jun 25 2021 at 06:16):
Would it be helpful to include text that says “Additional constraints may be defined in <base>.”?
Brian Postlethwaite (Jun 25 2021 at 06:18):
You could put that text into your template that includes the relevant fragment (in the appropriate language :wink:).
Jose Costa Teixeira (Jun 25 2021 at 06:36):
Is any of this a candidate for the base template or other templates?
Lloyd McKenzie (Jun 25 2021 at 13:11):
The proposal in the template is to move the invariants into the differential, snapshot and mustSupport/implement view. Differential would show only the invariants that had changed. Snapshot would show everything. mustSupport/implement would show the invariants that pertained to the elements that were mustSupport, mandatory or that implementers otherwise need to worry about.
Brian Postlethwaite (Jun 25 2021 at 23:27):
I still Think the "everything" should exclude ext-2 and ele-1, they just pollute the view too much.
Brian Postlethwaite (Jun 25 2021 at 23:28):
Maybe the complete invariants should be a tab of its own, as that's going to be very long.
Lloyd McKenzie (Jun 25 2021 at 23:31):
The other thing we're going to do is we're going to group the invariants - so ext-2 will be a single row in the table - listing all the elements it applies to. That should make it much less visually overwhelming.
Brian Postlethwaite (Jun 25 2021 at 23:35):
Apart from the 2 above, do we have any examples where you'd see more than 1 value?
Eric Haas (Jun 25 2021 at 23:43):
same for bindings too right?
Lloyd McKenzie (Jun 26 2021 at 02:30):
Any constraint that applys to Element or BackboneElement would hold - and any StructureDefinition could theoretically introduce those. (And future versions of core might introduce some too.)
Last updated: Apr 12 2022 at 19:14 UTC
