2018-10-05 SGB WGM Agenda

back to Standards Governance Board main page

HL7 SGB Minutes Location: Lombard		Date: 2018-10-05 Time: 9:00 AM Eastern
Facilitator	Paul/Lorraine	Note taker(s)	Anne

Attendee	Name
x	Calvin Beebe
x	Lorraine Constable
	Russ Hamm
x	Tony Julian
x	Paul Knapp
	Ewout Kramer
Regrets	Austin Kreisler
x	Wayne Kubick
x	Thom Kuhn
	Ken McCaslin
x	Rik Smithies
x	Sandy Stuart
x	Ted Klein
Quorum: Chair + 4

Agenda

• Agenda review
• Discussion Topics
  • Value Set Governance
  • Continuous Maintenance in FHIR
  • SGB Communication Plan
  • Large architectures coming in:
    • Evaluate PSS process to potentially provide earlier visibility
    • How should a product family-type project be documented and reviewed - is PSS enough?
    • When it affects cross-organizational methodology, PFMGs need to have a review/say - potential precept
  • Updates that we do to newer versions of FHIR that are also applicable to older versions
  • Precepts We Need to Develop
• Parking Lot
  • Mapping coordination
  • Add link to Confluence page from ARB page
  • Review of product management life cycle spec to see if it talks about project and ballot scope
  • Review of MG responses to SGB query on substantive change
  • Need to make sure that SGB is accurately reflected in the GOM, and figure out what precepts should appear in the GOM
  • Review Mission and Charter
  • Drafting Shared Product Management Responsibilities
  • Technical Alignments Between Product Families
  • How groups are to interact with publishing, EST, Vocabulary, etc.
  • Precept on bringing in large projects
  • Vocabulary - review HTA material for precepts
  • Precept for adding new tools (include that WGs with a specific mandate must be involved, such as EST, Publishing, Vocabulary, etc.) - was this covered by the tooling precept we created in New Orleans?
  • BAM guidance on process for product adoption
  • Create PRECEPTS that require that it be articulated in the standards how the value sets specified within the standards respond to changes in regulation, licensing, time, etc.- to do in April/before Cologne
  • FHIR Product Director Position Description: we should 1) review further and draft feedback, then 2) map back the description to the role of FGB
  • Ownership of content
  • What precepts do we need to address PSS/profile approval processes of balloting and publishing potentially thousands of CIMI model?

Minutes

• Agenda review
  • Lorraine wants to add Argonaut diagnostic report development
• Discussion Topics
  • Value Set Governance
    • Ted here to discuss. Paul displays slides.
      • HL7 maintains and publishes terminology it authors, as well as non-HL7 terminology; code sets such as SNODENT, CDC race subset, NHSN value sets, etc., but mostly ‘headers.’
      • Each code system, value set, or table has an identifier – OIDs, mnemonics and table numbers, URIs. HL7 assigns these for its own stuff. Non-HL7 stuff have identifiers assigned by HL7.
      • Governance problems: Sometimes external orgs wake up and insist on assigning new identifiers for their stuff. CDC has done this. Sometimes they change their identifiers. Sometimes HL7 does this ourselves. The problem with URIs is that, because a URI is intended to be a human readable thing, organizations sometimes change things for a variety of reasons.
      • FHIR URIs: We would like these to be resolvable URLs, and UTG will do this for all of our stuff. All terminology should be published at terminology.hl7.org. We have a bunch of FHIR things with URIs as build.fhir.org and hl7.org/fhir. We are moving those things that have not been published in normative artifacts. What about those that have been published in normative artifacts? Have decided if it’s not in use we’ll change it.
      • How strong should we be in demanding stability and permanence in such identifiers? How demanding should we be in moving terminology to terminology.hl7.org in newly published products?
        • Grahame arrives
      • Ted is working with Grahame to move all the stuff they can as quickly as they can. Calvin: What’s the proportion of things you can do vs. what you can’t? Ted: There are significant numbers of things but only a small percentage of things with problems – around 380. But if they all have to be dealt with through discussions, it will take a long time. If things are cited in normative specs, the change might have to happen on a reaffirmation or recirculation. Not sure of the ANSI rules. Grahame: WE have a few value sets where URIs are effectively managed externally. We have other things that we haven’t moved yet because we don’t know how they’ll be managed going forward. Things that would matter were clearly UTG things, so we moved them to UTG. Then we have other things that we’re not sure about yet. Discussion over how we’ll support the external one. Ted: We’ll have to direct them in the editor to contact HTA to coordinate. Grahame: WE should be very demanding that anything in UTG has very stable identifiers. Calvin: So we want to do this where we can and there are some cases where we can’t. What is the process for things that have to be vetted? Paul: Either you’re creating a new set of identifiers for the things you manage, or a registered identifier for the things you don’t manage. Ted: in places where orgs already have an identifier, we use that one and point to it. Discussion over DICOM codes that are being temporarily hosted. Who should be the vetting group when we run into issues? It starts with Vocabulary, then product management group. Calvin: How about the project management group has to take a request to Vocabulary?
      • Ted brings up struggles in unifying vocabularies. Struggling with names of the code systems being the table number – the names lead them to the wrong place. Paul: Why are we stopping at the level of assigning a new concrete identifier for something. Why wouldn’t we have a terminology index referring to all the terminologies we use anywhere, whether we host it or not?
        • Grahame departs
      • Ted is setting that upon HL7.org. Should stop grandfathering things. Discussion over what is included in terminology.hl7.org. UTG is the stuff WE manage…everything else is external, including other HL7 organizations/affiliates.
      • Discussion over the guidance from this group. We want to be strong in demanding stability and permanence. We need a prescribed process for exceptions to be vetted and dealt with.
        • Ted departs
      • Calvin: We can make the strong statement that we want to have strong, stable permanent identifiers to those things that are noted in HL7 terminology. If an issue comes up it goes to the management group, then Vocab makes the final decision on any exceptions.
  • Argonaut diagnostic report development
    • Email from Elliot Silver. He reports that they are currently profiling FHIR DiagnosticReport for radiology, lab, and pathology uses under their clinical notes work item. They haven’t been communicating with WGs, and then they bring the work forward it will become a de facto part of US Core. We don’t seem to have any say with what Argnonaut is doing with this stuff. Not saying that it’s headed in a bad direction or “wrong,” just that they aren’t engaging the relevant WG. Calvin notes they can’t get into our product space without engaging with our process. Wayne: ONC would support keeping things within the HL7 environment. We just need to go back and re-evaluate how we engage with Argonaut. Thom notes the headway we’ve made with Da Vinci is a good model. US Core tends to be voted on in US Realm once it’s fully cooked.
      • ACTION: Wayne to reach out to the project leads to work it out and discuss with US Realm.
  • Continuous Maintenance in FHIR
    • Paul is still concerned about having different ideas over what continuous maintenance means. Need to notify ANSI about what we plan to do and declare a ballot frequency. Any changes that occur to the artifact between those are accumulated but not published. The consensus process is up for us to determine.
    • Reviewed Calvin’s document. We are only allowed by ANSI to use periodic maintenance or continuous maintenance. The only real difference is whether you have an ad hoc review cycle or a fixed review cycle. Under periodic we set a schedule. It’s a formality of prescribing that you’re going to do something on a regular schedule. If you set it up and say you’re going to do it every three years and you don’t, then you’re in trouble. Discussion over why we did it with the RIM – it was to relieve it from constant balloting. The reason FHIR core would like to have continuous maintenance is so they don’t get dragged into continuous balloting. Gives us the opportunity to build a protective barrier.
    • Need to come up with draft precepts and then have the management groups make recommendations to the TSC. FHIR will need to understand that the changes won’t be made continuously. Can’t just look at small scope changes. Two questions: If someone wants to recommend changes to any part of the standard, it sounds like it needs to be open for consideration by the consensus body. Tony: If you can’t publish chapter 2, 6 and 9 separately, how can you ballot resources separately. Paul: You must be willing to accept comments on any part of the document under this. The section states no portion of the standard shall be excluded from the revision process. Paul doesn’t recall having a scope limited ballot on the RIM, although we may have on the “raspberry patch.”
      • ACTION: Put together list of questions to take to Karen
        • Under continuous maintenance, can you limit the scope of the ballot when you go back to the review process?
        • Is the scope of the ballot determined by the organization and/or its committees, or must it be done by the voting body?
        • When leaving the document open to review, can the balloters and the committees still be guided by backwards compatibility rules within our methodology? Can methodology rules constrain it?
        • If we’ve declared continuous balloting, can we also do periodic balloting on scoped material?
        • Does continuous require review of requested changes only, or does it require a review of the proposed disposition-level requests? Reviewed examples in ANSI’s continuous maintenance document.
        • Could our designated management groups receive requests for changes, review them for inclusion, and put those forward in a consensus vote that is open? Paul suggest the domain committees review. So a designated committee will be available to render decisions on what content will be added in to the next cycle and then that material will be sent out to the consensus group. Paul: What we actually do is people submit stuff through the tracker, the committee considers and makes modifications, and then we ballot the product periodically. Maybe we document what we do and then make that the procedure. What is the downside with staying with periodic? Lorraine: The former understanding is it would make things move faster, but it doesn’t seem to be that way in practice. Could we drop in our process, run it past ANSI, and get their comments back?
          • ACTION: Paul to write up our current process for review
        • Thom: We need to know what FHIR really wants to accomplish with this, and if continuous maintenance would really address those. There may be another way to do it. Is the issue the publication schedule, or do they want a more efficient way of handling comments that come in? Wayne: If we just keep doing what we do, it fits.
          • ACTION: Talk with FMG regarding what they want to accomplish with continuous maintenance to see if it fits
  • SGB Communication Plan
    • Could set up a Confluence page with items we want to highlight for people. Decision to complete that by January.
      • ACTION: Anne to work with Josh to set up page.
  • Large architectures coming in:
    • Evaluate PSS process to potentially provide earlier visibility
    • How should a product family-type project be documented and reviewed - is PSS enough?
    • When it affects cross-organizational methodology, PFMGs need to have a review/say - potential precept
      • For now we have completed this item. Wayne notes that TSC still needs to implement phase 1 of the BAM, but it isn’t an SGB responsibility.
  • Updates that we do to newer versions of FHIR that are also applicable to older versions
  • Precepts We Need to Develop
  • Mapping coordination
    • Discussion over the numerous mapping projects. It has all the characteristics of a cross product family, although it’s just an infrastructural activity. The problem is we don’t have good representations for the mappings that we do. Who owns the problem? Thom brings up the CIMPL FHIR map that came out of CDS this week. There’s something popping up every minute. Nobody owns it, just mushrooms popping up. Perhaps it’s a PLA question on who should own it. Do these things constitute ballotable goods? Need to separate between the definition of the good and the use of the good, and the tooling decisions. Calvin: Do we have a precept about that? Wayne: There are a proliferation of tools that aren’t known or added to the inventory. Need a decision making process so we don’t end up with dozens of tools that do almost the same thing. Need to come up with a set of precepts to give to the management teams. The mandate of EST is to work with staff to manage these things, and some falls into the CTO’s bailiwick. SGB needs to develop precepts to act as the fences. Lorraine notes we added a checkbox for developing tooling to the PSS, which could be a trigger to send to EST.
    • Drafted guidelines and precepts on draft precepts page.
      • ACTION: Carry forward the TSC proposed actions and ask for review of the precepts on an upcoming call
        • Lorraine and Tony depart
  • Add link to ARB Confluence page with SGB content to SGB page
    • ACTION: Anne to look for content to link
  • Review of product management life cycle spec to see if it talks about project and ballot scope
    • TSC should be adding on the ballot timing changes.
      • ACTION: Anne to dig through TSC minutes to see if it was approved.
      • ACTION: Add to TSC agenda to ask if it has been disseminated for action
    • Calvin: Where in the organization do we limit the scope of content? Need a due process. We can say no, but people should have the opportunity to object. Domain committees need to feel empowered and safe within the area of their expertise in the overall process. Need to know there are people to go to when a deadlock needs to be solved. Need a clearly defined process.
• Next week’s call cancelled.
  • Review of MG responses to SGB query on substantive change
  • Need to make sure that SGB is accurately reflected in the GOM, and figure out what precepts should appear in the GOM
  • Review Mission and Charter
  • Drafting Shared Product Management Responsibilities
  • Technical Alignments Between Product Families
  • How groups are to interact with publishing, EST, Vocabulary, etc.
  • Precept on bringing in large projects
  • Vocabulary - review HTA material for precepts
  • Precept for adding new tools (include that WGs with a specific mandate must be involved, such as EST, Publishing, Vocabulary, etc.) - was this covered by the tooling precept we created in New Orleans?
  • BAM guidance on process for product adoption
  • Create PRECEPTS that require that it be articulated in the standards how the value sets specified within the standards respond to changes in regulation, licensing, time, etc.- to do in April/before Cologne
  • FHIR Product Director Position Description: we should 1) review further and draft feedback, then 2) map back the description to the role of FGB
  • Ownership of content
  • What precepts do we need to address PSS/profile approval processes of balloting and publishing potentially thousands of CIMI model?

Meeting Outcomes

Actions

Next Meeting/Preliminary Agenda Items 2018-10-17 SGB Conference Call

© 2018 Health Level Seven® International. All rights reserved