Skip to end of metadata
Go to start of metadata
HL7 TSC FMG Meeting Minutes 

(voice and screen)

Date: 2020-06-24
Time: 4:00 PM U.S. Eastern
Chair:Note taker(s): Anne W.
Quorum = chair + 4yes/no
Co chairsxDavid HayxLloyd McKenzie
Wayne Kubick, CTO
xHans BuitendijkxBrian Postlethwaite
Paul KnappxAnne W., scribe

Josh Mandel
John MoehrkexBrian PechxFreida Hall
xGrahame Grieve

xBrian Phinney

xBrian Pech

xDidi Davis

xFloyd Eisenberg

xDavid DeRoode

xLynn Laakso

xYolanda Villanova

xMichelle Barry



  • Roll Call
    • Visitors here for review items.
  • Agenda Check
    • Application of our rules around IGs to specs that are not necessarily IGs and what are the boundaries around what is an IG and what is not
  • Minutes from 2020-06-10 FMG Agenda/Minutes
    • MOTION to approve: Hans/Brian Pech
    • VOTE: All in favor
  • Action items
    • Reviewed
  • Review Items
    • Ask-At-Order Entry Guidance PSS
      • Freida here to present the project. There was a question that came up yesterday on US Realm on whether or not it is an implementation guide.
      • Aims to provide guidance on the ask at order entry questions.
      • Hans: Guidance is meant to apply to how to do it in V2 and FHIR so it can be done either place. Technically not an implementation guide, but not sure how to mark it. It's about how we value particular elements for AOE in light of the specification. Lloyd: It could be expressed as a profile, as a bunch of slices or a bunch of invariants that say you're allowed overall set of codes is these, and if your code is A then your datatype needs to be B, etc.  It could be an implementation guide because you could use that format to do what you're trying to do. Could mark it FHIR Implementation Guide and FHIR Profile for the time being. Floyd asks if they'll provide examples? Freida confirms.
      • Discussion over whether it should be informative or STU. Lloyd suggests it would qualify as STU. Hans will approach OO to make sure the group is comfortable moving it to STU to Normative.
        • MOTION to approve: Hans/Brian Pech
        • VOTE: All in favor
    • STU Extension Request for QI-Core Implementation Guide: STU 3.2 (v3.2.0 for FHIR 3.0.1)
      • Floyd here to represent the request. There won't be any update to the material, they're just extending it the STU 3 version.
      • Lloyd wonders if FMG needs to review STU extensions. Perhaps it's just a reporting item as opposed to approval. 
        • MOTION to approve: Brian Pech/Hans
        • VOTE: All in favor
          • Anne Wizauerto add question of management group review of STU Extensions to TSC agenda
    • STU Publication Request for Vital Records Mortality and Morbidity Reporting FHIR IG
      • Missing link to content
      • Missing IG proposal
        • Anne Wizauer to ask project lead for the link to the CI build and IG proposal for Vital Records Mortality and Morbidity Reporting FHIR IG
    • Dental Data Exchange IG Proposal
      • David Deroode here to represent the proposal. 
      • Short description should be revamped to present tense for the registry listing.
      • Long description should be revamped from a description of the project to a detailed description of if the IG would fit an implementer's set of requirements. What implementers is it targeted at, what problems does it solve, who should use it and for what purpose?
      • David updates; group reviews
        • MOTION to approve: Paul/Hans
        • VOTE: All in favor
    • Updated DEQM IG Proposal
      • Content location should remain the same as it was
        • MOTION to approve with the recommended change: Hans/Grahame
        • VOTE: All in favor
    • STU Publication Request for CDISC Lab Semantics in FHIR
  • Discussion Topics
    • Timelines for the next release of FHIR
      • Grahame suggested having an STU ballot and publication. However having an R4a presented many difficulties. We could simply take what we would normally do as our first draft and say that it's an STU ballot for at least some portion of it, the subset we've identified as worth STUing. Then we could rubber stamp the STU part of those new resources and it wouldn't affect our regular development cycle. Lloyd: That just gives you an STU ballot but not an official release, tooling support, or implementer support. Grahame: There would be an STU publication but it would be an extra version to be supported. Lloyd: So we'd go to STU ballot in January, call it R5? Grahame: It would be more like an R4b. Lloyd: Everything that has changed since R4, then, will have to be in scope for that ballot. 
      • Paul arrives
      • Lloyd: If we're going to put out a new release of FHIR, if there are changes to content that was STU, those changes have to go through the STU ballot process. If there are changes to normative, it has to go through the normative process. Paul: With normative, yes. STU has to go through the STU review process but doesn't necessarily call for a ballot. Lloyd: So some of it could be an unballoted STU update. Grahame: My intention was to use the ballot process and indicate specific sections as STU and the rest as work in progress.
      • Lloyd: The objective is to put out a ballot, limited scope, in January, and publish in March or April; then proceed to do another ballot that would be a more full ballot including normative. We can finesse changes to STU content to be an STU update, but don't think we can do that for normative. 
      • Lynn arrives. Lloyd: Can we publish an official version of FHIR where resources that are STU or normative in R4, but in R4b marked as draft because we don't subject them to ballot? Lynn: Are there changes to those that are already marked as normative? Paul: Yes, in this version they would be in process or draft. Lynn: So certain things would be in scope, and certain things would be out of scope. Lloyd: For the ballot, and for the publication. But whoever implements 4b will have to pay attention to the changes that we didn't ballot. One possibility is that the implementer community refuses to touch the version. Paul: If you want to have a version that all hangs together, you've got to ballot that. 
      • Grahame: We're certainly not going to be balloting breaking changes to normative content from what is normative in R4. You could have breaking changes from the R4 to 5 to content that was never normative. Paul: Are there changes to normative content in the current build? Grahame says no - there is content that is candidate normative content that hasn't been balloted normative yet, but is noted as normative because it will be balloted normative next. 
      • Lloyd: There are changes that we can make that aren't breaking but are substantive in normative content; if we publish with those and then yank them out, that doesn't take away the pain from anyone who implements those things. Grahame; We're the only ones who have no choice but to support it and don't have a choice.
      • Paul: We need to think about what's allowable in terms of change. Would suggest no normative change. Lloyd: The challenge is there are normative changes allowed in normal releases going through formal ballot. The challenge is if we're going to occasionally do these incremental special releases and pretend that the normative stuff isn't normative, we don't have control over what changes are in that set unless we roll stuff back which is painful and difficult to ensure we got it right. Paul: We can't make changes and pretend it didn't happen. Grahame: The interim publication would include an override on the build so nothing at all is marked normative. Paul: So there's no assurance that what you've got in there is the normative from before? Lloyd: If we just publish whatever changes happen to be there, that will be what you must implement in R4b. You can't implement the R4 stuff for some and the R4b stuff for others.
        • Grahame and Lloyd will write up a proposal for R4b and circulate for comment
    • Carry forward:
      • Application of our rules around IGs to specs that are not necessarily IGs and what are the boundaries around what is an IG and what is not
  • Adjourned at 5:34 pm Eastern