Stream: argonaut
Topic: Must-support on child properties on a parent that is not MS
Cooper Thompson (Nov 22 2021 at 20:29):
For SDOH Screening, Observation.component is NOT tagged as MS, but Observation.component.code is MS. What does that mean? The narrative implies that component results are must-support, but if that is true, why is it not flagged with MS?
Also, do we think Observation.component should be MS? I get Observation.value, but without knowing what screenings are relevant, how can we know if Observation.component is even necessary?
Eric Haas (Nov 24 2021 at 00:51):
For SDOH Screening, Observation.component is NOT tagged as MS, but Observation.component.code is MS. What does that mean?
I thought we had guidance on that, but we don't which make me think we don't do that anywhere else, but I need to see if there are any other places we do that.
Also, do we think Observation.component should be MS? I get Observation.value, but without knowing what screenings are relevant, how can we know if Observation.component is even necessary?
Good question -Need to follow up on the above question first , but I think it should be so that the use cases handles more complex questions - we took this profile from the SDOH guide and simplified it a bit. Then you can make a ballot comment so we can hash it out.
John Moehrke (Nov 24 2021 at 12:49):
I have asked why a backbone element needs to be marked MS. Seems if an element is MS that should be enough, as one can't have that element without the backbone element that it lives within. (similar for summary) -- I don't think MnM has given us good guidance.
Lloyd McKenzie (Nov 24 2021 at 14:51):
If a parent isn't marked as MS, the children being MS only comes into play if you choose to support the parent. (Sort of works like cardinality - a mandatory child is only mandatory if the parent is present.)
Yunwei Wang (Nov 24 2021 at 14:53):
I found this ticket: https://jira.hl7.org/browse/FHIR-28607 which states:
If a child is MS and the parent isn't, then if you support the parent you must support the child, but there's no expectation that you must support the parent.
But this is still confusing. "if you support the parent", what does that mean?
John Moehrke (Nov 24 2021 at 15:02):
I think this presumes a specific definition of "support", which is not defined.
John Moehrke (Nov 24 2021 at 15:03):
I think I do follow the argument that it is much like cardinality, except that is a very different vector.
John Moehrke (Nov 24 2021 at 15:05):
if the element is populated, it does make the backbone element appear... thus, this is what I expected out of MS on an element without egregious MS on the backbone element.
John Moehrke (Nov 24 2021 at 15:06):
if we really must have egregious marking of the backbone elements, then we really need FHIR-Core build and IG builds to warn when this is not the case. (Yes, I have FHIR core resources with this problem)
David Pyke (Nov 24 2021 at 15:46):
Maybe I've got a deep misunderstanding but the problem is that marking the parent should be unnecessary. If you've forced support to a child element, and a parent is a backbone (without a value), then you only care that the child element is supported. What could Must Support of a backbone element entail?
Yunwei Wang (Nov 24 2021 at 16:40):
There is difference for validation. Assume a server has 100 Observation resources and none of them has Observation.component. When both component and component.code are MS, then we can say that this server fails to demonstrate supporting both element. When only component.code is MS, then we don't know if this server supports component.code or not.
John Moehrke (Nov 24 2021 at 17:28):
I am willing to follow MnM guidance, but today it is unclear if egregious MS marking of backbone elements is necessary.... similarly if egregious _summary marking of backbone elements is necessary. --- And if egregious marking are necessary, then we really need the build tooling to warn when egregious marking is missing.
Eric Haas (Nov 24 2021 at 18:41):
@Cooper Thompson I checked and this is the only place in US Core I can find. So (ignoring the above histrionics ;-)), we will change component to MS and you are free to comment during the ballot. Thanks for catching this!
Eric Haas (Nov 24 2021 at 18:48):
FYI ... it looks like the SDOH guide just pulled component from their screening survey observation. :rolling_eyes:
Isaac Vetter (Nov 24 2021 at 19:38):
Eric, why change component to MS right now? There's no justification for being stricter than Gravity, and there's a reasonable argument that component (support for "multi-select" answers) is unnecessary. Why not leave as is, or remove MS from code?
Eric Haas (Nov 24 2021 at 20:07):
Make a ballot comment. We are not making any more substantive changes - all qa from now on in.
Eric Haas (Nov 24 2021 at 20:12):
disregard my earlier comments SDOH does have component ... I must have been looking at the wrong version :rolling_eyes:
Brett Marquard (Nov 24 2021 at 20:14):
This has happened to me before also on gravity -- I think a few teams were generating guides in the early days before moving to single branch.
Lloyd McKenzie (Nov 24 2021 at 22:46):
Pretend that every implementer creates their own profile that documents exactly what they do and don't support. If they mark the backbone element as supported (MS=true) and a profile marks children of that backbone element as MS=true, then in order to comply with the profile, they'd also have to mark those elements as MS=true. On the other hand, if they indicate that they don't support the backbone element, then the MS on the children never comes into play.
Lloyd McKenzie (Nov 24 2021 at 22:47):
If an IG wants to force support for children of a backbone element, then they must also force support for the backbone element itself.
Isaac Vetter (Nov 26 2021 at 18:33):
Fyi - https://jira.hl7.org/browse/FHIR-34384; some of the metadata for the issue is incorrect because, I think the package-list.json isn't accurate, because the IG content isn't yet complete b/c the content complete deadline isn't until the end of next week.
Brett Marquard (Nov 29 2021 at 14:56):
We may need a call on this one... @Eric Haas and I will chat today and get back to this stream
Brett Marquard (Nov 29 2021 at 22:08):
@Isaac Vetter This is a tough one, we want to align with Gravity and they aren't putting a MS on Component right now...our options:
- Remove MS on Component, add a section to Conformance Expectations on what it means when children are 'MS'
- Keep MS on Component on down. (current US Core build)
- Remove all MS from Component on down
@Robert Dieterle and @Daniel Vreeman - Have you considered the implications of not marking Component MS on the SDOHCC Observation Screening Response Profile?
Brett Marquard (Nov 29 2021 at 22:11):
We are happy to revisit this entire profile during ballot - MS and beyond.
Robert Dieterle (Nov 30 2021 at 16:21):
we are adding MS to the Component for SDOHCC Observation Screening Response profile in the STU 2 version (Jan 22 ballot)
Isaac Vetter (Nov 30 2021 at 16:53):
Thanks, Bob, this profile, right? (Hasn't been updated yet). Given that Gravity is using US Core's definition of MS, do you happen to know why systems should be mandated to be capable of recording multiple answers for a screening question in a single Observation?
Daniel Vreeman (Nov 30 2021 at 21:31):
@Brett Marquard - Good point. We discussed at our Gravity IG team meeting today and think it makes sense to add Must Support at the level of Component, so we'll be doing that in our upcoming spec.
Eric Haas (Nov 30 2021 at 22:14):
Isaac Vetter said:
Thanks, Bob, this profile, right? (Hasn't been updated yet). Given that Gravity is using US Core's definition of MS, do you happen to know why systems should be mandated to be capable of recording multiple answers for a screening question in a single Observation?
This is a key question and I hope we get plenty implementation feedback and can land on an answer.
Isaac Vetter (Nov 30 2021 at 22:48):
Hey @Daniel Vreeman - what was the justification why systems should be mandated to be capable of recording multiple answers for a screening question in a single Observation?
Daniel Vreeman (Dec 01 2021 at 11:27):
@Isaac Vetter - The rationale was that many of the "benchmark" screening assessments used nationally, like PRAPARE (LN:93025-5 ) and the Accountable Health Communities tool (LN:96777-8), have multiselect answers for individual questions. The SDOHCC IG specifically included the example of a PRAPARE question with multiselect (using the Component structure) as an example for the SDOHCC Observation Screening Response profile. Multiple answers to a single question is one of the identified use cases for the Observation.component structure.
Cooper Thompson (Dec 01 2021 at 14:12):
It seems like the "must support" need for the profiles is really tied to the specific questionnaires/questions. USCDIv2 doesn't mandate any specific assessments, so while it might be common for folks to use those standard assessments, it seems odd to have requirements a profile that are ultimately independent of USCDIv2 (though I get that US Core isn't just USCDIv2).
Brett Marquard (Dec 01 2021 at 20:11):
Thanks @Daniel Vreeman - Do we have examples of systems (Servers + Clients) that have tested this approach?
Brett Marquard (Dec 01 2021 at 20:16):
This got minimal discussion time in the US Core design sessions this fall -- we pulled in based on the Gravity design.
Last updated: Apr 12 2022 at 19:14 UTC
