FHIR Chat · call on now

Stream: fmg

Topic: call on now

David Hay (Aug 19 2020 at 20:06):

(there was a confusion as the call was initially cancelled then re-instated...)

Lloyd McKenzie (Aug 26 2020 at 20:02):

Call on now

Josh Mandel (Aug 26 2020 at 21:37):

Thanks for the discussion on today's FMG call, re: release planning. I appreciate the candid exploration of possibilities. I certainly don't mean to hold us up or be overly reactionary -- and it's through this kind of discussion and debate that I'm able to iron out my own understanding and articulate my position. Sometimes I have to try out arguments to understand where they work and where they fall down :-)

Lloyd McKenzie (Sep 02 2020 at 20:03):

Call on now

Josh Mandel (Sep 02 2020 at 20:06):

I'm running late -- am I needed for quorum?

Lloyd McKenzie (Sep 02 2020 at 20:09):

Josh Mandel (Sep 02 2020 at 20:46):

Can someone readmit me to the Zoom?

Josh Mandel (Sep 02 2020 at 20:47):

(Also, is it possible to turn off lobby mode for the future overall, or for FMG members at least?)

John Moehrke (Sep 16 2020 at 20:03):

call on

Josh Mandel (Sep 16 2020 at 20:38):

Did I break up on the call just now? My point was to say, in clarification:

The details of how "Must Support" works, and the precise semantics and capabilities are still a work in progress. As such, there may be confusion between editorial intent and structured representations. We encourage the designers of formal testing procedures to take editorial intent into account when designing conformance tests.

Josh Mandel (Sep 16 2020 at 20:57):

Thanks Hans!

Grahame Grieve (Sep 16 2020 at 21:47):

Discussion with Wayne | Austin about this, @Josh Mandel - it's procedurally comfortable for us to issue an 'errata', even if this is just advising of lack of clarity in the existing specification. We don't have to do it this way, but if the language FMG are working on can be phrased this way, that would be good

Josh Mandel (Sep 17 2020 at 20:50):

Here's some proposed wording @Hans Buitendijk in place of the bold blue text we discussed yesterday:

As the FHIR specification has matured and worldwide adoption has grown, we've seen strong demand for the precise, computable expression of conformance requirements. This area of the specification -- and especially the precise semantics for describing which data elements a FHIR implementation "must support" -- should be viewed as a work in progress. After reviewing how FHIR's "must support" flag is being used in implementation guides today, we [FMG?] recognize that in many cases the intent of a specification's editor does not align precisely with the formal implications of the specification's data profiles. We anticipate that the FHIR R4 publication will require technical corrections for clarity and perhaps to provide additional capabilities for expressing more nuanced "must support" requirements. After these corrections, implementation guide authors could update their IGs accordingly. In the meantime, we recommend that any formal testing procedures should not automatically treat the "must support" flag as applying to the entire hierarchy of data below a flagged element; rather, testing procedures should aim to reflect the editorial intent behind these profiles.

John Moehrke (Sep 17 2020 at 23:01):

well politically said.

Hans Buitendijk (Sep 17 2020 at 23:09):

@Josh Mandel : Thank you! I made some further modifications to clarify:

As the FHIR specification has matured and worldwide adoption has grown, we've seen strong demand for the precise, computable expression of conformance requirements. This area of the specification -- and especially the precise semantics for describing which data elements a FHIR implementation "must support" -- should be viewed as a work in progress. After reviewing how FHIR's "must support" flag is being used in profiles today, we [FMG?] recognize that in many cases the intent of a implementation guide/profile's authors is not fully reflected in the application of the "must support" flag and other essential narrative leading to different and unintended interpretations. As examples, we note that various profiles have used slicing to be more specific, others have used clear narratives, others did not specify any further leaving that to implementers or subsequently further constrained profiles, while many have still ambiguous and conflicting language that lead to varying interpretations, thus leaving much to the implementer to imply or assume.

Updates to both the FHIR Core specification and to profiles will be needed to better align use of "must support" flags and narratives for the various FHIR elements (attributes, backbone elements, data type elements, reference and target choice list elements, value set elements) with the intent of the implementation guide/profile authors. Already, discussions and proposals on the ability to use "must support" on the various elements of an attribute have started and we expect other methodological and tooling aspects to be addressed as well to fully enable implementation guide/profile authors to more precisely express their more nuanced intents. After these updates are made available, implementation guide/profile authors should update their IGs accordingly.

In the meantime, considering that the underlying intent of the "must support" flag in the FHIR Core specification was not to assume a "must support" to be automatically applied to all its elements if unless there was specific guidance for each of the elements to provide more varied and flexible "meaningful" ways that the profile authors could use describing their intent, we recommend that any formal testing procedures should not automatically treat the "must support" flag by applying it the entire hierarchy of data below a flagged element; rather, testing procedures should aim to reflect the editorial intent behind these profiles, and in the absence thereof or having conflicting interpretations consider that the implementer has flexibility to choose which elements it can support.

Hans Buitendijk (Sep 18 2020 at 13:53):

@John Moehrke , @Lloyd McKenzie , @Josh Mandel : considering the update I provided further, not in sync with Josh yet on clarity that is needed so suggest you review the latest.

John Moehrke (Sep 18 2020 at 14:22):

I did not find any problem with your expanded text. I do however think we are marching in the wrong direction. I don't think the problem is in the FHIR Core, it clearly indicates that it applies to the element. I think the problem is more in US-Core where they have defined mustSupport to be something that causes the conflict. It seems US-Core is the one 'implying' that mustSupport is something closer to mandatory.

backbone elements seem strange to me to be marked mustSupport. I would be happy if that was defined in FHIR core as explicitly not allowed or as meaningless. But I guess an IG might be able to define something. Maybe I am just not thinking of a useful example.
In IHE we use mustSupport only the same way we have used R2 in the past, if you have the data you must send it, and a recipient can't complain if data comes in that element. With that definition there is little misunderstanding. We don't demand that you send all flavors of the element. We don't demand that you must persist what is received. Where a persisting requirement is needed, it is added to the element, not implied in mustSupport.
That said, a profile can only apply mustSupport to an element, complex datatypes can NOT further be refined. So I can mark an element of type Attachment as mustSupport, but I can't profile the elements within Attachment. (This is a problem MHD has had with DocumentReference). Did I hear there is an extension fix for this?
I thus think the only thing the FHIR core can say is that the mustSupport definition defined within the IG applies to the 'element'. Thus the IG must be more clear about what that mustSupport means within that element and especially with complex datatypes.

Hans Buitendijk (Sep 18 2020 at 14:27):

@John Moehrke : This is a two-way topic: FHIR Core and US Core, so I would not consider this thread the wrong direction, rather that it is incomplete without the US Core discussion which is a different thread. That is being pursued already with Cross-Project Group/US Core as well so they are not just focusing on next version, but also provide similar guidance as we are doing here for FHIR Core. Both clarifications are needed: what did FHIR Core allow/intent/working to enable, what does US Core consider intent until their next version is in place to avoid variant expectations that have not been reconciled.

Lloyd McKenzie (Sep 18 2020 at 14:33):

mustSupport on backbone elements is totally sensible. If Patient.contact is mustSupport, then you're expected to handle the contacts of the patients. If not, you're not. Backbone and data type elements work exactly the same way.

Recipients can't complain about the inclusion of any element that isn't max=0. The behavior of mustSupport is going to vary by use-case. If the focus is decision support, then you care about inclusion of the value in the assessment. If the use-case is storage, then that's going to be part of mustSupport. One of the challenges for U.S. Core is that it has two different scopes - US Baseline (which should be cautious about declaring mustSupport anywhere, and where the meaning is going to be quite loose) and meaningful use regulations related to EHRs - where setting expectation on storage is wholely reasonable

Complex data types can absolutely be further refined. Profiles do this all the time - and it's important to do

Lloyd McKenzie (Sep 18 2020 at 14:34):

I have IGs where I walk into data types purely to assert mustSupport of components

John Moehrke (Sep 18 2020 at 17:34):

Lloyd McKenzie said:

I have IGs where I walk into data types purely to assert mustSupport of components

well, I did say that I thought there was a way.. so, how?

Lloyd McKenzie (Sep 18 2020 at 17:41):

Same way you walk into data types to constrain cardinality or vocabulary bindings or anything else. Just declare the relevant path in your profile. E.g. Patient.contact.name.first

John Moehrke (Sep 18 2020 at 17:49):

duh, and I have done that. I need a vacation...

Hans Buitendijk (Sep 18 2020 at 18:25):

Are we o.k. with the latest text from an FMG perspective that I posted? Then that needs to start to flow to FHIR-I/MnM/(Conformance)/TSC. Separately a discussion needs to progress with CPG/US Core. I already am engaged there to progress that topic and needed the FMG direction reasonably solid to then put the rest in place to clarify how to interpret MustSupport in US Core until the next version is available.

Josh Mandel (Sep 21 2020 at 12:37):

I prefer the shorter and less specific text that I proposed, but I won't hold this up if others are on board with what Hans is suggesting.

Brett Marquard (Sep 21 2020 at 13:08):

I agree, it's lengthy. This seems to be the key piece to testers:

should not automatically treat the "must support" flag by applying it the entire hierarchy of data below a flagged element

Next question after this is approved is which elements did the authors intend systems support. For US Core, I am certain @Eric Haas/I/other US Core Participants didn't intend systems support only one (i.e. Observation.valueString)

Hans Buitendijk (Sep 21 2020 at 13:50):

I agree with the essence and key piece. The reason I prefer the longer text is to provide better context to the interpreters that took a different view to understand the problem and challenges. So open to ensure the essence stands out. We've seen that less words have lead to a wrong interpretation, and from prior IG used for certification testing, assertions, and surveillance, absence of clear tooling/syntax to describe what's optional, required, required but can be empty, etc., or where the condition is not computable, require more words to explain what the real intent is.

Lloyd McKenzie (Sep 21 2020 at 14:39):

I'm ok with either

Brett Marquard (Sep 21 2020 at 14:40):

Where/when will this be discussed set?

Lloyd McKenzie (Sep 21 2020 at 14:40):

Presume the FMG session on Thur. (2 Eastern)

Brett Marquard (Sep 21 2020 at 14:52):

@Hans Buitendijk Would you be willing to post where you expect to present/discuss new must support language? It seem like this may be covered in more than one work group!

Hans Buitendijk (Sep 21 2020 at 15:59):

@Brett Marquard : Absolutely. Only way to have something to shape. May share it with you first though to make sure we covered all bases perspectives as components of the write-up.

Eric Haas (Sep 21 2020 at 17:29):

why can't FMG limit this to a single workgroup? Is terribly inefficient and frankly a waste of a lot of people's time to split over 3-4 WGs

Lloyd McKenzie (Sep 21 2020 at 17:45):

FMG has no ability to keep people from talking about stuff. MnM has authority over methodology changes and FMG has authority over technical corrections.

Hans Buitendijk (Sep 22 2020 at 14:17):

After input/discussion with Josh and Brett, a latest version is here on a confluence page: https://confluence.hl7.org/pages/viewpage.action?pageId=91989782#MustSupportClarifications-DRAFT. The amount of wording somewhere between where Josh and I were heading respectively and Brett's input helped get us somewhere inbetween that might work for everybody.

Hans Buitendijk (Sep 22 2020 at 19:44):

@Josh Mandel , @Lloyd McKenzie : What is a good time to review the latest draft with FHIR-I to ensure they are in agreement with the summary? While I have the sense that other than wordsmithing you are o.k., should we further review with FHIR-I?

Josh Mandel (Sep 22 2020 at 20:33):

I thought we were drafting language for FMG or to support a letter from Wayne. I may have misunderstood the process though ;-)

Hans Buitendijk (Sep 22 2020 at 21:17):

Correct, so the language linked represents the proposed language that includes FMG's perspective discussed so far with examples from a US Core perspective to help clarify that then can be proposed to TSC/Wayne to be formalized. Just what is in the Draft section, not what is above as that is old material where we started in FMG. We also talked about needing input from other groups as well, particularly MnM and FHIR-I from a FHIR Core perspective, and CPG/US Core from a profile perspective to make sure we don't over/under state and that US Core examples that clarify where the interpretation variances have come up, before forwarding it to TSC to then finalize with Wayne.