FHIR Chat · Accumulating Must-Support guidance · IG creation

Stream: IG creation

Topic: Accumulating Must-Support guidance

---

Josh Mandel (Sep 01 2021 at 16:44):

In profile views, it should be possible to render the red letter "S" with (funtionally) a set of links to all the Must-Support guidance that applies -- i.e., in an IG that accumulates Must-Support guidance on top of its base profiles, or layers Must-Support guidance on top of not-Must-Support elements in the base profile.

There are some missing pieces we'd need to make this possible -- @Grahame Grieve have you thought about this? Is it worth outlining an "ideal UX" here?

(See https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/.E2.9C.94.20Differential.20table.20bug.20.28or.20.2E.2E.2E.20bug.20in.20my.20brain.29.3F for context.)

Lloyd McKenzie (Sep 01 2021 at 16:56):

The issue is that if you reference a US core profile in a downstream IG, all of the mustSupport rules of the downstream IG apply, even though that won't be surfaced in the links.

Gino Canessa (Sep 01 2021 at 17:22):

(consolidating some comments from the other thread)

Lloyd McKenzie said:

They might think they're doing that, but they're not. IGs inherit the mustSupport rules from their parent and any mustSupport rules they introduce in their IG apply to all elements, whether listed in their differential or not.
i.e. all US-core AND pathology must-support rules apply to all mustSupport elements in all profiles used by the IG.

Is that implementable?

US Core explicitly limits some claims to what is contained in US Core (e.g., ...SHALL be capable of populating all data elements as part of the query results as specified by the US Core Server Capability Statement.). How would a downstream IG add something to that Capability Statement?

Similarly, if an IG's purpose is to cover things not included in US Core, claims about things like missing data (established in US Core) would be unresolvable.

I would also be curious if IG authors are crafting their rules around things like 'Must Supports I don't define here'. My assumption has been that I'm defining rules for things I'm covering in my IG - if there's another layer, above or below, it defines what it is interested in. If I don't touch an element in any way, how would my rules apply to it?

I'll also say this more than somewhat terrifying as someone who is authoring an infrastructure-level IG, knowing that other IGs will be layered on top of it. It means I need to redefine my Must Support in such a way that it is exceedingly lightweight and penalty-free for other IGs to add to.

Josh Mandel (Sep 01 2021 at 17:25):

if you reference a US core profile in a downstream IG, all of the mustSupport rules of the downstream IG apply,

Wait, I'm not sure I follow. I would have thought both of these are true:

• If US Core marks Patient.name as Must-Support, and the downstream IG has nothing additional to say about this, then only the US Core definitions should apply

• If US Core marks Patient.name as Must-Support, and the downstream IG adds its own Must-Support definition of "need to have specific support for displaying all names together in the UI" (or whatever.. just some extra constraint), then both the US Core requirements and the downstream requirements apply

... but I think @Lloyd McKenzie's saying "no, the Must-Support flag should always be interpreted as rolling up all the Must-Support definitions from the root of the inheritance tree down to the current IG, so you only ever need to point to definitions in the current IG"

Lloyd McKenzie (Sep 01 2021 at 17:26):

If the downstream IG makes additional generic rules about US Core and the downstream IG leverages us-core-Patient, then the additional generic mustSupport rules apply to that IG's use of us-core-Patient - and thus the Patient.name.

Lloyd McKenzie (Sep 01 2021 at 17:27):

E.g. If a downstream IG says "clients must display mustSupport data", that expectation would apply to all profiles used by the IG, even if inherited without modification.

Josh Mandel (Sep 01 2021 at 17:27):

OK -- so there's no additional semantics associated with including Patient.name in the downstream IG's differential, if it's already Must-Support in the base?

Lloyd McKenzie (Sep 01 2021 at 17:28):

Right. It just means the author happened to repeat it in the differential with no cosntraints.

Lloyd McKenzie (Sep 01 2021 at 17:28):

Or maybe they added a usage note that's just not visible in the table.

Lloyd McKenzie (Sep 01 2021 at 17:29):

Inclusion in the differential doesn't impact mustSupport behavior.

Josh Mandel (Sep 01 2021 at 17:32):

So your recommendation is: every IG should provide Must-Support guidance that manually links out to the M-S guidance from every base IG it depends on? Or, how else are developers expected to discover all the obligations that apply?

David Pyke (Sep 01 2021 at 17:33):

It would be good if the MS Flag could be a link to a specific spot in the IG that outlines the MS requirements.

Gino Canessa (Sep 01 2021 at 17:34):

This isn't sinking in for me, so please bear with me =). If we have two IG's (A and B) that each have their own definitions of Must Support, there's a set of possibilities for where an element is 'tagged' with Must Support: A, B, or both A and B.

• if an element is only tagged in A, I would expect the MS rules from A to apply.
• if an element is only tagged in B, I would expect the MS rules from B to apply.
• if an element is tagged in both, I would expect the MS rules from both to apply.

I don't believe it's actually possible to differentiate between these states today - which is (for me) the issue I'm seeing.. I don't believe IG authors are taking into account that their Must Support rules are going to apply to any element that an IG based on them tags as MS.
(edit: based on knowing that I haven't.. and a lack of confidence that it's possible to define a useful set of rules that includes elements I'm not using)

David Pyke (Sep 01 2021 at 17:40):

You can't, as of now, differentiate automagically, only in the prose. We need to have a way to computationally differentiate what MS means in a profile or element.

John Moehrke (Sep 01 2021 at 17:45):

the reader can navigate to A from B and see the difference... ugly, but it is possible to do what Gino is outlining

David Pyke (Sep 01 2021 at 17:56):

It's possible, just really manual. We should move on from that.

John Moehrke (Sep 01 2021 at 18:08):

not saying it couldn't be better. just disagreeign that it is impossible

Gino Canessa (Sep 01 2021 at 18:17):

Fair - I was thinking 'possible looking at the structure definition from the top profile'.

Jose Costa Teixeira (Sep 01 2021 at 18:22):

Not sure if it's the same thing, but this reminded me of an idea from an IHE colleague - when we have a constraint (not only a MS), it is interesting to see where is that constraint added. National level? IHE level? project level?

Grahame Grieve (Sep 01 2021 at 19:21):

we've talked before about a terminology for must-support, why something is must-support. I could certainly do that technically, but we're made zero progress in coming up with such a terminology.

Josh Mandel (Sep 01 2021 at 19:30):

Terminology aside, there is today a stack of (narrative) M-S guidance that accumulates whenever profiles inherit from other profiles. What do you think about surfacing this stack to end-users so they can navigate it?

Grahame Grieve (Sep 01 2021 at 19:32):

I think that's true in concept, but I don't think it's as tidy as that in practice

Grahame Grieve (Sep 01 2021 at 19:33):

do you have an example where it is?

Lloyd McKenzie (Sep 01 2021 at 19:44):

There's no ability to tag mustSupport in more than one place. Once set, it remains set. The rules that apply depend on what IG its used in. All of the rules for the current IG as well as any inherited IGs apply.

What we could do is require that the mustSupport rules be explicitly declare either on IGs or on profiles, so that we could aggregate all that apply and put them someplace you could link to. However, that gets messy because some child IGs might choose to restate parent rules (with any constraints added) rather than expecting readers to read both - so rendering parent + child would give redundancy and cause confusion. Also, if there are multiple parents, there could be overlap. I suppose we could say that "if you're going to specify mustSupport rules for an IG, you must integrate all parents". Then the IG could be published with text that says "The mustSupport rules when using any profiles referenced by this IG are as follows.... These rules comply with and further refine the rules defined in parent IGs here, here and here". However, you still couldn't have your inherited and non-redefined profiles point to that because they won't know about the derived IG.

Jose Costa Teixeira (Sep 01 2021 at 19:45):

Grahame Grieve said:

we've talked before about a terminology for must-support, why something is must-support. I could certainly do that technically, but we're made zero progress in coming up with such a terminology.

I know @Frank Oemig was interested. I think that is a valuable addition

Lloyd McKenzie (Sep 01 2021 at 19:47):

I'm doubtful that we'll ever have a terminology that can say all the things designers will want to be able to say.

Grahame Grieve (Sep 01 2021 at 19:53):

but that's the wrong question. The right question is 'could we have a terminology that will say useful things for the readers of an IG"?

Jose Costa Teixeira (Sep 01 2021 at 19:55):

I think there are a few flavours of MS that we can come up with. And it wouldn't have to be a required binding, right?

Gino Canessa (Sep 01 2021 at 20:42):

If we could clarify something, I'd appreciate it. It feels like there are different resolution policies being discussed. If we have two IGs: Subscriptions Backport IG (A) and IG That Uses Subscriptions in R4 (B).

I am reading Lloyd's position as all MS rules apply to any MS element in a chain. E.g.:

• Whatever rules I put for MS in A will apply to all elements that are MS in B, even if they are not flagged MS in A.
• Any MS rules defined in B are 'applied' to MS elements defined in A.

This is fairly different from what I described earlier, that MS rules are relevant to elements tagged as MS in that IG (regardless of ability to computably discover that information).

Is this defined, or are are we all resolving it way we 'think it should be'? If this is documented, where?

Lloyd McKenzie (Sep 01 2021 at 21:23):

You're reflecting my position correctly. With the added note that 'tagging' of MS isn't IG-specific. Once it's declared, it's declared. It can't be "re-declared" in a child IG.

Richard Townley-O'Neill (Sep 02 2021 at 02:12):

Is this right?

• The MS tag is just a tag. It is not the only way to indicate that an element must be supported, just the most obvious.
• Identifying an element as must support can also be done by text ,which can be in the SD (e.g. in SD.description) or elsewhere in the IG.
• Defining the meaning of must support can be done in the SD (e.g. in SD.description) or elsewhere in the IG.
• All of that (flag and text) gets inherited by derived profiles.

Grahame Grieve (Sep 02 2021 at 02:13):

if you say it's must support you are expected to flag it. So if it's not flagged, you should be able assume there's no text that says how it is somewhere

Lloyd McKenzie (Sep 02 2021 at 03:09):

What can happen though is that usage notes on a single element can alter (or if within the same IG), override the generic must support guidance.

Frank Oemig (Sep 02 2021 at 07:49):

This is my point. In principle it can vary for each MS because it depends where and how you declare the scope.
My proposal was to start with a structured extension to capture all possibilities with in an IG. The code systems can be somehow arbitrary so not really following good practices. Eg., 1=print, 2=show etc., eventually using the sentences from the IG.
That way it would be possible to get it in a machine readable format first, and not hidden somewhere. Once we have that we can think about how we can improve it.
(This is optional for those who think in that direction, so not a breaking change.)

Gino Canessa (Sep 02 2021 at 17:19):

This feels like an odd default to me - is it documented somewhere? (I phrase it as 'default' because if you can change the behavior of MS by explicitly defining it for an element, then it's just the default propagation rule.)

Based on my current understanding, I have two specific questions:

1) In the Subscriptions Backport IG we don't have a DAR alternative for MS - our MS means that it must be present. If someone builds an IG on top of it that has MS means present or DAR, the two rules are incompatible.

In the scenario where the IG is profiling Subscription to specifically add that type of support to an element, that makes sense - use the 'newer' rule. But, does it apply to all elements in the Backport IG now? What if they are not trying to override the MS from Subscriptions, but just adding that behavior for some other element in the resource; what is the behavior then?

2) If an IG includes both Subscriptions Backport and US Core, which rules apply? Is it based on the chain for each resource, or is it applied to everything in the IG (since MS rules are in an IG)? For example, DaVinci PCDE references US Core, HRex, PDex, PAS, and Subscriptions Backport. Do I look at the MS definition chain for each resource individually, or for the IG as a whole?

If there's documentation I can use to resolve these types of questions, please just let me know. Otherwise, I'm happy to file a ticket for adding/clarifying, though I'd appreciate a link to the existing documentation either way - I've come up short for this. Thanks!

Lloyd McKenzie (Sep 02 2021 at 17:31):

1. Da Vinci ran into this same issue. We settled on the notion that - for Da-Vinci defined profiles, DAR is only allowed for mandatory elements if explicitly defined in the profile. We wanted to do that everywhere, but created an exception for profiles inherited from US Core because we couldn't override their rules. In short, an IG's MS rules can't break the behavior for anything they import, but can add additional rules, and can set different rules for stuff that's not imported.
2. The rules for US core apply to the US core stuff. The rules for backport apply to the backport stuff. The new IG needs to define the expectations for stuff defined in the new IG - including possibly setting additional expectations on the imported stuff.

Lloyd McKenzie (Sep 02 2021 at 17:32):

Note - the above are my opinions/understandings. We haven't documented such expectations anywhere that I'm aware.

John Moehrke (Sep 02 2021 at 19:50):

forgive me... what is "DAR"?

Josh Mandel (Sep 02 2021 at 19:52):

"Data Absent Reason" :(

Elliot Silver (Sep 03 2021 at 15:25):

It seems to me that the issue here is not the lack of a terminology for classification of MS elements, but varied understanding of how must support works with inherited IGs. Perhaps there is a need to make inherited MS requirements more visible, but I'd say that's secondary to a better understanding of MS and inheritance.

For that matter, I'm not sure we have a good definition of what an "inherited" IG is -- If I declare a dependency on an IG have I inherited the entire IG? Can I bring in just a profile, or extension, or valueset without brining in all the other parts I don't need?) What does dependency on multiple IGs mean? (This also ties into a discussion on #IPS about whether adding a summary operation to the IG imposes a burden on systems that merely consume or create IPS documents.)

Josh Mandel (Sep 03 2021 at 16:24):

It seems to me that the issue here is not the lack of a terminology for classification of MS elements, but varied understanding of how must support works with inherited IGs.

Yes.

I'm not sure we have a good definition of what an "inherited" IG is -- If I declare a dependency on an IG have I inherited the entire IG?

My reading is, at least with respect to Must-Support: IGs don't really "depend on" other IGs, so much as StructureDefinitions inherit from other StructureDefinitions. All inherited requirements are accumulated this way, through a chain of SD.base relationships. (Of course, we do look at all these SD inheritance relationships and roll them up to create a nice list of IGs that that we "depend on" so we can fetch artifacts, provide documentation links, etc -- but the actual conformance requirements for Must-Support are attached to specific FHIR Elements in specific profiles, not to IGs.)

Lloyd McKenzie (Sep 03 2021 at 17:40):

My interpretation of what happens is as follows:

• When mustSupport is defined, it impacts everything defined in that IG and is inherited - for those artifacts - in any downstream IG that subsequently uses those artifacts. The rules include those defined on the IG as a whole, those defined on the profile and those defined on individual elements.
• Constraints can be defined in such away that they can be overridden in the context of an IG. E.g. "Unless otherwise specified at the profile or element level, mustSupport means X". However, they can't be overridden within a referencing IG. If an implementer of a base IG would have had certain expectations, those expectations hold wherever the artifact is referenced
• If an IG defines its own must support rules and declares a dependency on other IGs, any resource it references from those IGs retain their original mustSupport rules and also incur the mustSupport rules of the referencing IG unless the wording declares otherwise
• The mustSupport rules for an IG can choose to reference rules defined in other IGs but, otherwise, rules defined in dependency IGs are not automatically presumed to apply to net new profiles defined in the referencing IG.

---

Last updated: Apr 12 2022 at 19:14 UTC