2022-11-29 US Realm Agenda/Minutes

Attendees:

Agenda

Administrivia

• Agenda review
• Review notes from 2022-11-08 US Realm Steering Committee Agenda/Minutes

Discussion topics:

• MCC Variance Requests for US Core: 

  https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/Variance.20Request.20MCC.20Observations

Minutes

HL7 Antitrust Policy: Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Administrivia

• Agenda review
  • No additions
• Review notes from 2022-11-08 US Realm Steering Committee Agenda/Minutes
  • Accepted via general consent

Discussion topics:

• C-CDA Companion Guide has been submitted for ballot
• MCC Variance Requests for US Core: 

  https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/Variance.20Request.20MCC.20Observations

  • Gay is developing a guide that is derived from US Core 5.0.1. The QA in the publisher looks at the continuous integration build and gives us warnings that we're not deriving from US Core when in fact we are. We want the IG developers to know what's coming up in US Core and the implications, but it would be nice if it would look both at the version you're deriving from and the upcoming work, and give you information about the CI compare as opposed to giving you a warning.
  • Brett: Even if it's new versions of the guide that are under development, it would be good for guides to know they exist and they're coming so they can build something conformant to it or not. May need to figure out how to make the publisher more friendly to these situations.
  • Dan: IN guides that declare a dependence on a particular version of US Core, we're going to have to wrestle with that for a long time. There is rational reason why people have decided to lock in to a particular version of US Core, so it seems like only doing the comparison to the CI build is probably not the right thing. If we could find a way to be more precise about that it would be good. 
  • Steve: It would help with our general philosophy from a US Realm perspective to give advance warning that they're potentially deviating form a future build of US Core. Do they have to come in and ask for a deviation from a build that isn't yet final?
  • Brett: We could inform them they may have an inconsistency, but what's the requirement to do something about that? 
  • Steve: Some of this is timing. Maybe there are a couple different windows where we solidify the future version and at that point we treat it like other versions that require permission for deviation. 
  • Rob: The publisher should check conformance against a published version of a guide. You can't do a comparison against a CI build.
  • Brett: The publisher is comparing to the CI build. Rob: That's a problem. Brett: Maybe we need to add a dial. Rob: We have to have points in time so we identify a stable thing. Brett: Notifying that something is changing is a useful thing. Maybe when you're developing a guide you claim conformance to a certain version, and for anything that you're not building in US Core you get a warning. Maybe things that are in the continuous build you get a note that you are or may be inconsistent.
  • Rob: We should demand that conformance is only claimed against a published version. You declare which version you're compliant against, and then you get warnings if not. In addition we could provide information against a future version, i.e., the CI build. 
  • Brett notes this situation only really comes up a couple of times a year before balloting. After ballot and publication it's stable for 6 months. 
  • Rob: This whole idea of versioning in FHIR is a moving target.
  • Emma: From an implementation standpoint, are we saying implementers should implement all versions of US Core? Rob: The first initial answer is yes. If you start using 5.0 stuff that isn't in 3.0 in implementations of SDOH, for example, you're potentially not conformant because of breaking changes. 
  • Emma: How does inferno play into all of this? Brett: Inferno today provides testing versions for 3.1.1, 4.0.0, 5.0.1. The only requirement is that folks deploy 3.1.1, which is the stable version. It's tough though when guides make dependencies on newer versions of US Core, and it gets hairy when we break compatibility between versions. In 6.0.0 we did update a lot of things and there may be a few pieces that are incompatible. 
  • Emma: IG writers, when you're writing your IGs and the tool is giving you errors and warnings based on versions, be mindful of implementations, what's implemented, what the use cases are. 
  • Brett summarizes: Warnings from the FHIR publisher are appropriate for the version of US core that the IG declares dependence on. It would be helpful if the publisher could informationally inform the editor of potential profiles in the future that the editor may want to conform to - this would not be a warning or stop them from proceeding. 
  • Bryn: I agree with the warnings from the declared version. Informational warnings from published higher versions I agree with. What is the benefit of CI build warnings? Why would we just not ignore those? Those are all in flux and don't matter until you get to build. Things change too rapidly and you could be sent down a rabbit hole for no reason. Should wait at least until ballot publication.
  • Gay, Brett, and Dan will talk to Grahame about what is possible to address this issue.