Stream: IPS
Topic: MS at the resource level?
Isaac Vetter (Feb 07 2022 at 18:46):
A number of (maybe all?) IPS resource profiles place a MS flag at the resource level. For example, ImagingStudy (build, published STU1) --
image.png
Isaac Vetter (Feb 07 2022 at 18:46):
Does this mean that ImagingStudy must be supported according to the IG's definition of MS ?
Isaac Vetter (Feb 07 2022 at 18:46):
If so, how does this not contradict the division of required/recommended/optional as defined here: http://hl7.org/fhir/uv/ips/STU1/ipsStructure.html#list-of-profiles ?
Elliot Silver (Feb 07 2022 at 18:49):
There is a ticket prohibiting (or maybe warning) against MS at the root of any profile/extension. I think it's approved, maybe waiting to be applied for R5.
Rob Hausam (Feb 07 2022 at 18:55):
Good questions. The primary answer is that we are currently re-evaluating all of our use of mustSupport in the IG, and it's very likely (unless we find a specific reason to do otherwise) that those mustSupport declarations will be removed. Many of them them got there originally when the IG Publisher was generating a warning whenever there was any element in the differential that was not marked as mustSupport - we added a lot then to avoid those warnings (which the Publisher no longer generated), and until now we hadn't gone back to see which ones could/should be removed.
Isaac Vetter (Feb 07 2022 at 19:16):
So, Rob, is this the intended requirements for support of a FHIR IPS document: http://hl7.org/fhir/uv/ips/STU1/ipsStructure.html#list-of-profiles ?
Isaac Vetter (Feb 07 2022 at 20:32):
In addition to the resource-level MS, Composition also MS's about every resource/section type -- https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Composition-uv-ips.html. This also contradicts: http://hl7.org/fhir/uv/ips/STU1/ipsStructure.html#list-of-profiles.
Lloyd McKenzie (Feb 07 2022 at 21:26):
MS at the resource level means that, when the profile is referenced in something else that can reference the full resource (e.g. Bundle, Parameters, etc.), that the referencing element SHALL be MS=true. Given that that's a super bad idea to enforce, we agreed to say that wasn't something that's allowed.
Isaac Vetter (Feb 08 2022 at 19:36):
Thanks, Lloyd!
Rob Hausam (Feb 08 2022 at 22:00):
@Lloyd McKenzie I'm not sure that I followed that last comment entirely - or if I did follow it, why that would be true. Could you try restating it?
Lloyd McKenzie (Feb 08 2022 at 23:08):
When you declare MS=true at the root of a type (resource, data type, or extension definition), what that means is that when that type is referenced with the declared profile somewhere else, that the element referencing the type MUST be MS=true as well. (Same thing occurs with cardinality - except that in the case of extensions, sometimes we want it to. E.g. if you set the cardinality of the base element for an extension to be 0..1, then the differential that references it needs to be a valid constraint on that - i.e. 0..0 or 0..1)
Lloyd McKenzie (Feb 08 2022 at 23:09):
If you want someone to have to support a particular profile, that's handled using CapabilityStatement, not by declaring MS=true on the profile root.
Rob Hausam (Feb 08 2022 at 23:55):
@Lloyd McKenzie So, I think the corollary to the (first) statement that you made, given that interpretation, would be that with an element that is not specified as mustSupport=true, it would be non-conformant to attempt to reference a resource profile that is specified as mustSupport=true at the root level. Is that what you are saying? If so, I don't think that's the only possible interpretation that could be made. And I don't believe that the current FHIR validator enforces that interpretation. One thing that also wasn't entirely clear to me is if by "the element referencing the type" you mean that the element is specified as being of that profiled type, or if the element is a Reference to a resource of that profiled type (or possibly you meant both)? An example of the former is here. In this case Bundle.entry.resource is not declared as mustSupport (at the element level or in the slices), whereas the '...UvIps' profiles that are specified as the types of entry.resource are declared as mustSupport on the root element (all of them currently are, I believe). This hasn't seemed to cause any issues with validation. If it is stated somewhere in the FHIR specification that this is not allowed, that would be good to see.
Lloyd McKenzie (Feb 09 2022 at 00:01):
Nope. If mustSupport isn't declared, you're free to assert it to be true or false. However, if the profile root said MS=false, then a referencing element would also have to be MS=false.
Lloyd McKenzie (Feb 09 2022 at 00:02):
If you have a Bundle.entry where MS is not declared and it's referencing a profile where the root says MS=true, I'd expect the snapshot to show MS=true for the Bundle.entry. If the Bundle.entry explicitly said MS=false, then I'd expect an error.
Rob Hausam (Feb 09 2022 at 02:59):
Ok. The snapshot does show it that way, as mustSupport - and that makes sense (I'd never actually looked at that before). But with that, I'm still unclear as to the point you are trying to make here (emphasis mine):
When you declare MS=true at the root of a type (resource, data type, or extension definition), what that means is that when that type is referenced with the declared profile somewhere else, that the element referencing the type MUST be MS=true as well.
When you say the type MUST be MS=true, then that implies that the type also MUST NOT be MS=false or MS not declared - because those are the options. And the referencing element as MS not declared is the case we were looking at in my IPS Bundle example above. Seems contradictory. What am I missing?
Lloyd McKenzie (Feb 09 2022 at 04:01):
If it's MS=undeclared, it becomes MS=true. If it was MS=false, there'll be an error.
Rob Hausam (Feb 09 2022 at 04:02):
Ok. That's just not quite what you said in the original statement. Appreciate the clarification!
Rob Hausam (Feb 09 2022 at 04:13):
The other question (the one I'm the most interested in) is, regarding MS at the resource level, where you say "we agreed to say that wasn't something that's allowed' - where was it that we agreed and said that? I don't recall having come across that before - and the validator doesn't complain about it.
Lloyd McKenzie (Feb 09 2022 at 04:43):
There's a tracker item where we agreed to prohibit it. It's sitting among the 800+ yet to be applied...
Elliot Silver (Feb 09 2022 at 05:58):
J#34347. Although I don't know why it is currently in triage. I thought it had been approved. (@Lloyd McKenzie , am I reading it correctly that there are 1700 tracker items up for "block vote 1"?)
Rob Hausam (Feb 09 2022 at 10:39):
Oh, thanks for the reference, @Elliot Silver (and for submitting the issue initially). Now that it's clearer what it is that we actually want to say, I agree that the principle makes sense (for IPS and otherwise).
Lloyd McKenzie (Feb 09 2022 at 15:09):
@Elliot Silver I suspect your search wasn't WG-specific and included issues that were already resolved
Lloyd McKenzie (Feb 09 2022 at 15:09):
The Block Vote grouping isn't automatically resolved when someone resolves the issue
Lloyd McKenzie (Feb 09 2022 at 15:12):
We'd discussed the issue here: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Must.20support.20on.20resource.20root/near/261825057, but it hasn't come up on a call. It's slated for block vote Monday.
Last updated: Apr 12 2022 at 19:14 UTC
