Skip to end of metadata
Go to start of metadata

Attendees Present

Chair:  Paul Knapp
Scribe: Anne Wizauer


Calvin Beebe

Chris Chute
xLorraine Constable

Tony Julian

xPaul Knapp
xAustin Kreisler
xWayne Kubick
xThom Kuhn
xRik Smithies
xSandy Stuart

xAbdulMalik Shakir
xChristopher Schaut
xGrahame Grieve
xNancy Orvis
xChris Amorosa
xNancy Needs

  1. Agenda review
  2. Discussion Topics
    1. JIRA balloting
      1. DRAFT PRECEPT: In order to submit a specification for ballot, the work group must have a documented understanding of the roles and responsibilities of managing and reconciling a ballot.
    2. Communicating and enforcing precepts
    3. Precept development from STU Update guidance document


  1. Agenda review
  2. Discussion Topics
    1. Precept development from STU Update guidance document
      1. Reviewed document. Need to see if we need to make updates to make the document current.
        1. Basic premise is that, according to the GOM, once you get an STU published you can make changes without reballoting. But there is a perception that any change requires a ballot. 
        2. Need to look at the breadth of adoption and the scope of the change in order to make the decision if you can make an unballoted STU update. Reviewed guidance table.
        3. Lorraine: Should we also apply this to informative? Austin: There is no language in the GOM about using this process for others.
        4. Lorraine notes that we're applying this inconsistently. Recent US Core update, for example. Who decides what level of change is being undertaken? Currently the WG. Wayne: Currently the decider is the impact on the community.
        5. Discussion over breaking changes and resulting impact vs. guidance matrix. Lorraine: The last US Core had a huge/broad impact and we did it with a two week review. Calvin: What kind of community review took place before, during or after that update? Wayne: They did describe the process. We need to update what acceptable vetting processes are for a functional peer review.
        6. Calvin: Should there not be another STU ballot after the initial one, and we simply do peer-reviewed updates? Discussion over how that would work for FHIR and for large changes. 
        7. Chris: It seems more like a documentation problem than a policy problem. Also need to communicate to the government that things may change.
        8. Need to update the vetting processes. Document mentions wiki based comments - that's out of date. US Core likely used the peer review process. This document also doesn't mention length of review. Review method may need to adjust based on breadth of impact. There is also a difference between updating an IG vs. the base specification.
        9. Discussion over two week review period. If we're going to make it longer, there might as well be a ballot. The purpose was to decrease the burden.
        10. Discussion over draft for comment - HQ policy currently doesn't allow publication of the results for comment ballots. This process takes an existing STU, then you publish an STU update based on the comments collected. Perhaps we remove draft for comment option. 
        11. Paul: Is the issue that, when doing reviews, that more work is required in terms of articulating the scope of review and detailing the changes? Maybe it's just an application of the rules vs. a change to the rules.
        12. Lorraine: For US Core, using the fast two week review process didn't allow key implementation communities to provide input. 
        13. Calvin: Broad strokes are good. It's very monolithic standards-centric, in the sense that access to community changes is only published after consensus. FHIR has this ability to publish changes in the public space. Some of the tension we get may be because of our historic monolithic publication process vs. the FHIR approach. Chris: If we could only publish when a full ballot is done three times a year, people will continue working on the standard in a small group to evolve it. An ideal state would be that you can constantly update the current build with appropriate approvals, and you can always see how it's different from the last balloted version. Lorraine: There is a difference between exposing current work and formally publishing an approved standard.
        14. Austin: When C-CDA was first being assembled, it was done outside HL7 initially. There were public views of that document as it was evolving which may be an analog of what is going on with the FHIR continuous build. But once it came into HL7 that evaporated. Having a continuous build capability is how you move fast and engage the broader community in a more open fashion. Lorraine: Agreed, and we don't currently have the infrastructure to allow that. Work in progress should be more publicly available.
        15. Paul: We could make a precept that it is a requirement that work in progress be somewhere in an organized fashion that HL7 can manage. Calvin: We're missing the layer of community involvement ahead of the ballot process. Need to get community involvement earlier.
        16. Paul: What makes it difficult to do a quick thorough review is when you get surprised with material. Lorraine: And if there is a big implementation community, we need to make sure we consult them.
        17. Two week review period is fine for a small change and a small group. Larger changes with larger communities need to be balloted. Need to delineate the line/clarify the gray zone. If there is a question, you should go to ballot. 
        18. Chris: What if all changes were put under a two week review period, even large changes, allowing the current build to change rapidly. Then periodically when relevant there is a ballot that locks it into a new STU publication. Lorraine: A two week review for a big organizational implementer is not enough. Paul: We expect people to implement things that are stable vs. constantly in flux. There's regulation that require things that are stable. This only speaks to one aspect of the overarching space. Chris: Should STU ballots follow the 3 times a year cycle, or be permitted to happen whenever? Austin: There are real infrastructural problems involved in doing continuous balloting. STU update was meant to deal with that. Lorraine: We do need to use the update process more. Austin: We need to make it easier to use, more visible, and clarify the review process that everyone follows. Chris: What if the STU updates were the thing that is near ballot level, we think we're in consensus, and then there is a lower level where you make edits. Austin: Perhaps we make the length and thoroughness of the review with the level of change. Paul: The notice period is key.
        19. Chris: An ideal STU process would be that you can make edits quickly that are visible publicly; come to a consensus on when the community has reviewed it enough that it's implementable. Austin: When you say the whole community, it's different based on different standards. There isn't a mechanism for HL7 to show it to the whole community. Paul: The whole community to me is the planet. In FHIR this already exists because of the continuous build. Our other standards don't have that. Chris: V2 and CDA are sufficiently stable that this isn't a problem. It's FHIR IGs and Argonaut/accelerator projects. Paul: So are you saying there should be a place where people can go to view things in development that is publicly available? Chris agrees. Paul notes the differing requirements that HL7 has in terms of ANSI. Could come up with a place that has links to all of these external projects are being developed. 
        20. Austin: We could set up a space where WGs could post material on a publicly facing web page where people could go when there is a review period. Lorraine: There is a real demand for web based publishing. Calvin: Without open continuous build space, you put all the burden in the balloting process, which cuts down our speed and agility. Paul: Or you trade time for quality. Calvin: Acceleration only decreases quality if you don't have agility.
        21. Discussion over WGs keeping private copies of things. Calvin suggests if they have private copies then they have to go to STU ballot. Need a common place for people to go that is accessible to everyone.
    2. Break from 11:30-12:00 Eastern
    3. Precept development from STU Update guidance document, continued
      1. Calvin: There is a board-level initiative related to community involvement which may be a sounding board that we listen/talk to.
      2. Need to refresh the process/document, communicate to the community, and provide tooling
    4. UTG governance
      1. Lorraine asks Grahame if he has any thoughts around Vocabulary/UTG governance. Grahame: We have a number of management issues around HTA and UTG. No real governance issues as a whole. If there is a governance issue right now, it's figuring out how to manage and compartment out content that we develop for exemplar or demonstration purposes for the standard, vs stuff that we develop for content for actual use. What should the governance be around exemplar content. A number of examplar materials have been moved into UTG. Lorraine: The community needs to know what is exemplar vs. official guidance. Grahame: It's been suggested that we create a space that we put example material into that we don't put into UTG. Discussion over where the management of that lands. Grahame states FMG and TSC would manage most of it. 
      2. Grahame notes that affiliates are allowed to publish FHIR IGs with no oversight from HL7 itself around their process or publication framework. Some are doing a great job but others are struggling with providing the management to meet what we would regard as our governance expectations for HL7 itself. Quality and adherence to process is not uniform and in some cases is not sufficient. Lorraine: There's been discussion at TSC about letting affiliates use HL7 to ballot their material. Some are publishing with idiosyncratic processes and no formal review cycle. One precept Grahame has for a FHIR IG is that it should be clear on how to raise an issue for resolution.  Paul: We could say that the information should be transparent available, a page where you can get to that information for affiliates. Need to make the affiliate agreement clearer in terms of expectation. Lorraine: We could provide suggestions to update the affiliate agreement. Rik: The FHIR community process outlines some of this. Lorraine: We need to be clear on expectations and outline how they can use the international infrastructure. TSC, SGB, and International Council all likely have a role. 
    5. JIRA balloting
      1.  Concern from Lorraine is how we handle organizational member voting. The process of registering comments and formally elevating it to a ballot vote needs to be determined. How do we do reconciliation - do we reconcile a comment and that registers as a vote on the item? What about discovered items? We're not driving reconciliation reporting or ANSI auditing against the tracker items per se. On spreadsheets you would add the discovered item and it would become part of the reconciliation. Calvin: What if the discovered item is a substantive change? It's historically been left to the sponsoring WG's discretion. Any changes should be tracked back to a JIRA ticket. Paul: Not sure the found item process has ever been formalized. Need to make sure the tooling supports the required reporting. 
        1. Add to questions from 2020-09-09 SGB Agenda/Minutes
          1. What is the approach to supporting organizational voters and voting on behalf of someone else
            • Anne Wizauerto set up a separate Confluence page with JIRA balloting material and questions
        2. Need to develop a precept around ballot items vs. discovered items during reconciliation vs. other comments with respect to what becomes part of the reconciliation as far as prioritizing
      2. DRAFT PRECEPT: In order to submit a specification for ballot, the work group must have a documented understanding of the roles and responsibilities of managing and reconciling a ballot.
    6. Communicating and enforcing precepts
      1. Reviewed page where existing precepts will be captured. SGB Precepts
      2. Need to determine categories for precepts
    7. Eligibility to run for cochair
      1. A situation has arisen where a cochair was elected to a number of WGs without having attended WG calls or a WGM. Wayne reports that GOC is looking at it. Wayne has recommended a pre-qualification process for running. 
        1. Add to parking lot
    8. CDA Management Group refresh
      1. They would like to refresh their documents. They should approve and send to TSC.
      2. Lisa has some questions within the document that we should review and respond to. Add to future agenda.
    9. Future calls
      1. Cancel next week. 
    10. Virtual Meeting
      1. Group agrees that this virtual WGM was effective, definitely better than not meeting at all, but the preference would still be face to face.
  3. Adjourned at 1:30 pm Eastern


DescriptionDue dateAssigneeTask appears on
  • Paul Knapp to send documentation to the cochairs of HTA and Vocabulary noting that we've drafted precepts on external terminologies and highlight questions on their currency document.
Paul Knapp2019-11-06 SGB Agenda/Minutes
Paul Knapp2019-09-20 SGB WGM Agenda/Minutes
Paul Knapp2019-09-20 SGB WGM Agenda/Minutes
Austin Kreisler2019-09-20 SGB WGM Agenda/Minutes
Lorraine Constable2019-09-20 SGB WGM Agenda/Minutes
  • ACTION: Paul Knapp will work on a grid with types of change/degree of review
Paul Knapp2019-05-22 SGB Agenda/Minutes
  • ACTION: Need to create precepts on stable identifiers for value sets, concept maps, and code systems
2019-01-18 SGB WGM
  • ACTION: Review proposed updates to the GOM, then determine how/where to represent SGB
2019-01-18 SGB WGM
  • Add Calvin's document on continuous maintenance and the decision to the SGB site.

2018-11-14 SGB Agenda/Minutes