Skip to end of metadata
Go to start of metadata


TSC Saturday meeting for Sydney WGM

HL7 TSC Meeting Minutes 

Location: Room E5.2

Date: 2020-02-01
Time: 9:45 am






Facilitator: Austin KreislerNote taker(s): Anne Wizauer






NameAffiliationQ1Q2Q3Q4LunchQ5
Giorgio CangioliHL7 Affiliate Representative





Lorraine ConstableHL7 ARB Co-Chairxxxx

Jean DuteauHL7 Affiliate Representativexxxx

Chuck JaffeHL7 CEO (member ex officio w/o vote)





Tony JulianHL7 ARB Co-Chair
xxx

Paul KnappHL7 Infrastructure SD Co-Chairxxxx

Austin KreislerTSC ChairRegretsRRR

Wayne KubickHL7 CTO (TSC member ex officio w/vote)xxxx

Virginia LorenziHL7 Organizational Support SD Co-Chair





Rob McClureHL7 Infrastructure SD Co-Chairxxxx

Mary Kay McDanielAdministrative SD Co-Chairxxxx

Riki MerrickAdministrative SD Co-Chairxxxx

Melva PetersHL7 Clinical SD Co-Chairxxxx

David PykeHL7 Clinical SD Co-Chairxxxx

Sandra StuartHL7 Organizational Support SD Co-Chairxxxx

Walter SuarezHL7 Board Chair





Anne Wizauer (scribe, non-voting)HL7 HQxxxx

Grahame GrieveGuestxxxx

Scott RobertsonGuestxxxx

Lloyd McKenzieGuestxxxx

Alexander BartschkeGuestxx



Jason SteenGuestx




Ted KleinGuest
x




Quorum Requirements (Co-chair +5 with 2 SD Reps) 

Agenda Topics

Q1 - 9:00 to 11:15

TSC Management

  1. Roll Call and Introduction of visitors (including declaration of interests)
  2. Additions to, and acceptance of, agenda:
  3. Temperature Check - 40 minutes
  4. Task Force Updates - 20 minutes
    1. Accelerators - Austin
    2. Cochair Handbook - Sandy/Melva
    3. Supporting Implementers - Wayne/David
    4. Agile Standards - Austin
    5. GOM revisions - Melva
  5. GOM updates to naming convention - Jean

Q2 - 11:45 to 1:00

  1. GOM updates, continued (if needed)
    1. Completed last quarter
  2. Process Improvement
    1. How does PIC fit into our governance structure?
  3. Project management artifact list from Project Services - 15 minutes
    1. How do we go through this list and make decisions on it?
  4. UTG
    1. Impact on WG Health
    2. User interface
    3. TSC support of testing
    4. Other prerequisites for moving forward with pilot
    5. Co-chair Dinner messaging 

Q3 - 2:00 to 3:30

  1. Agile Process Project 

Q4 - 4:00 to 5:30

  1. Project Concept Form
  2. Consensus Review Process
    1. What is the role of steering divisions?
  3. JIRA Balloting
  4. Messages to WGs and Membership

Monday evening Agenda Topics

  1. ArB
  2. HTA
  3. Product Management Groups
    1. CDAMG
    2. FMG
    3. V2MG

Thursday lunch

  1. Schedule:
    1. Project management one-page document requested by CIC
    2. Process to identify what non-FHIR ballots (V2, V3) will have a need for the UTG process for this next cycle
    3. (January) Review TSC Mission and Charter

    4. (January) Review TSC Decision Making Practices

Minutes/Conclusions Reached:

Q1 - 9:00 to 11:15

TSC Management

  1. Roll Call and Introduction of visitors (including declaration of interests)
    1. Visitors listed above
  2. Additions to, and acceptance of, agenda
    1. Agenda accepted
  3. Temperature Check - 40 minutes
    1. Hold off until later
  4. Task Force Updates - 20 minutes
    1. Accelerators - Austin
      1. Has been looking at managing the workload on the WGs and education needs. Ken McCaslin has been working on providing materials. We have an initial list of resources to help get people on board. MK: When we share this stuff with accelerators, we need to share with the people working with them as liaisons. Wayne agrees. Lorraine: We need to figure out when that initial engagement point is where we start providing this education. The official point is when an SOU is signed. Do we tell WGs when the SOU is completed? Not currently. Wayne has a page that has accelerator information; Melva suggests it should have information on how to become an accelerator. MK: Need a clearer analysis before they come in on what they are doing and who they will be engaging with and evaluating the effect on the WGs involved. Wayne notes that now they must have a project plan, which is a new requirement. Lorraine: So we require a project plan, but  those aren't communicated to the WGs or even a TSC. Wayne: Need to figure out a communication plan for the WGs.
    2. Cochair Handbook - Sandy/Melva
      1. Was a group effort between Ken, Melva, Sandy, and Frieda. Will be formally rolled out this week. Will be the single source of truth as we get rid out of the old stuff. Lorraine asks about maintenance. Wayne notes that we need to clarify an update process. Sandy notes that it is on PIC's agenda.
    3. Supporting Implementers - Wayne/David
      1. MK states that we had discussed adding an implementer role to TSC but haven't finished that discussion. Wayne states it was an option we considered. We don't have as much FHIR representation here, for example. Dave Pyke has done some research on implementer support that he will present to the board on Wednesday.  The community is saying they want support in education and certification. Implementer community is defined as the people bringing the technology to the end user. Lorraine: We also need to figure out how to support the businesses. Paul; Should break into two parts - 1) what services need to exist within the ecosystem, and 2) which of those services does HL7 need to provide. There is still a huge market need for getting people on board with FHIR, which is the ROI positive need. We would work with the groups who are already doing it and HL7 would provide a point of consistency in curriculum and course material. Lorraine notes we've always had some HL7 training and then private market training. MK notes that we have big holes in the training we have and there are huge opportunities.  Jason notes that the tutorial aspect of this conference has really boosted the financials. More information will be forthcoming after the board presentation.
    4. Agile Standards - Austin
      1. Austin's updates are at the bottom of this pate. The task force has worked on categorizing standards and WGs will need to make initial evaluations of the standards they are responsible for. TSC will need to put forth some WG health measures to have the statuses of standards maintained going forward. There has been confusion around retired and withdrawn definitions. SGB has been working on life cycle issues and we need to synthesize that work. Need to have a common understanding of the definitions. 
      2. DIscussion over how this relates to STUs that have been expired. Grahame notes that release 1 of FHIR has been abandoned. R2 is done as a trial use standard and no technical corrections would be issued; however, the tooling is still being supported as there are many who continue to have it implemented with no current plans to update until the rules say they have to do so. Wayne: That would fit our stable definition. Each version is in a different state. Grahame: We have a standard that is not quite a product family that is on a rolling project that spits out static versions; to some degree we support the static version or take comments that will be applied to a future version. Reviewed definition of retired in Characteristics of Standards Categories
        1. Active: Grahame notes technical corrections are missing from active. Lorraine: We talked about a state transition diagram that could be helpful. Something that we've retired could come back as active, for example. We don't have a process to designate something as retired.
          1. Need to synthesize the work the Agile Task Force has done with the work SGB has done before moving forward.
            • Anne Wizauerto schedule joint meeting between Agile Standards Task Force, Product Management Groups, and SGB to review categories
    5. GOM revisions - Melva
      1. Has been working on reorganization and re-wording. New content is being added as well. Much of it has been simplifying the sentence structure. Lorraine; Is there a point where ARB should take a look at it again? Melva states once we talk about it in the GOC it can be sent to TSC/ARB for review. Wayne: There should be guidelines on how to add new sections. Lorraine; Perhaps we should just stop doing new, non-urgent updates until it's done.
  5. GOM updates to naming convention - Jean.
    1. Reviewed proposed document.
      1. Are we naming a thing or a class of things? Discussion over what should be in the name and what should be in the metadata.
      2. If we do classes of things vs. specific things, there will be confusion. There is the release number and the ballot number, which are different. 
      3. Need as simplified clean version that TSC and management groups can take a look at and approve. 
      4. Lorraine: Lynn should also be involved in this conversation.
      5. Rob; Having an alias could be a good way to solve this problem.
      6. Lloyd; We should have a short marketing name that is unique and put the rest in metadata.
      7. Paul; What about project names and trademarks? We need to add that issue in. CARIN and Gravity have requested that there is community visibility in the names. 
      8. Why is this in the GOM? The ER handles normative issues and non-normative go in the GOM. But there could be a different place that is less difficult to update. 
      9. Grahame asks how products fit in; to what degree does product management get to choose what ballot name they get to use. 
      10. Lorraine states that accelerator names should not be in value set names because they are going to go away. Rob: It might be reasonable to include CARIN, for example, in a value set name if that's what makes it unique. Scott notes that calling things by project names is becoming more common in HL7. When a project name is known it is significant. 
      11. Grahame: It's important to understand the community dynamics. If it's limited to a set of participants it's not a bad thing to use the project name. 
      12. Lloyd: It's a mistake to think the names should be descriptive. They are marketing names that don't have to be meaningful - they have to be unique, recognizable, appropriately group things that should be grouped. If people know what Gravity is then it helps them find what they're look for. Names should be short, snappy, easy to type, recognizable, and that people use in conversation. 
      13. Jean: Infoway has recognized the difference between names and metadata. Can find all the standards related to a number of pieces of metadata. 
      14. Lorraine: We're conflating marketing name with internal identifiers that we track things by. WE should differentiate how we manage things in the database and how we present then to the world.
      15. Wayne: We need to put together a short proposal to present to SGB, product management, TSC.

Q2 - 11:45 to 1:00

  1. GOC
    1. Jean asks who governs the GOC? Melva: It's defined in the GOM and it's an appointed committee, other than the TSC rep. Discussion over requirements for membership and whether responsibility should be transferred to HQ. Lorraine: We need to ensure that we don't have inordinate influence by an individual. Jean: There should be an overlap for the TSC rep to the GOC with a transition period for continuity. MK notes we need this for all groups including SDs.
      • Anne Wizauerto add continuity, training, succession planning to parking lot
  2. Process Improvement
    1. How does PIC fit into our governance structure?
      1. Wayne: Organizational Support SD is a bit unbalanced currently. What should be the role of PIC and other organizational support committees? There are overlaps with some of the new management and governance groups that didn't exist when PIC was formed. Paul: Perhaps PIC should operationalize the policies even if they don't develop them. Sandy: We tend to be a place to come for membership to voice issues with processes. Working on figuring out where they can help with moving things forward as we move to confluence and update our processes.
      2. Wayne: Not sure the organization understands the role of these groups within the organization. Need to make sure they have the capabilities and resources for what we need them to do. Sandy asks what issue we're trying to solve. Lorraine: Groups should be providing the voice of the membership and HQ does the work. Decisions should be made by the committees. Challenge is getting back there because trying to get work done in EST, for example, is difficult because the engagement isn't there. Wayne; In EST we tried to set up tooling liaisons again and it was unsuccessful. We cannot get engagement, for some reason. MK: We need to make the committees in existence do what they were intended to do in the first place. PIC worked for many years until we started going around them. Lorraine notes that in EST, they used to work closely with HQ on website redesign, etc. And then over time they stopped being even consulted. Sandy: In PIC this week we were going to discuss a socialization campaign throughout the year with e-news, WGM activities, etc. Wayne: The membership doesn't understand the purpose of these groups. 
      3. Lorraine: There is some overlap with PIC and the management groups and SGB. Should get clear on the boundaries of all these groups. Scott: PIC's role may be more important with the management groups.
      4. Wayne asks how much Publishing has to do with FHIR publishing? Grahame reports that we had three different publication stacks. Publishing was officially responsible for version 2 publishing. FHIR publishing turned into a thing of its own. Each group has been running their own publishing, but now things are changing. We're all heading towards some kind of FHIR-derived stack of publishing. Not sure where V2 publishing will end up.
      5. Lorraine: When CIMI started to look at publishing their material as a web spec, we met with Lynn and what was left of Publishing. As they go through and use their tooling to generate their web pages? It still seems to make sense that groups generate their material and hand it to Lynn to verify and upload. Jean: In publishing, the V3 side ran well because Woody was not a volunteer in terms of the time and effort he spent. Things like PIC and Publishing affect the lifeblood of the organization. 
      6. Ted: A new piece of publishing is going to be the publishing of terminology. 
      7. Lorraine; For publishing in particular the staff publishing director does the bulk of the work. The publishing WG was to protect staff from vagaries and represent the organization to the WGs. Paul: We need to separate the doing from the decision making. Staff may do the doing but the committees should make the decisions.
      8. Grahame: We have a staff deficit in publishing from a web standpoint. Need to determine the constraints and restrictions and understand what we're trying to achieve.
      9. MK notes how other organizations handle and fund these issues. She states that HL7 is very complex in terms of who owns what in the process.
      10. Overall we need clarification and communication to the organization on who is responsible for what.
  3. Project management artifact list from Project Services - 15 minutes
    1. How do we go through this list and make decisions on it?
      1. Reviewed list. 
      2. Wayne suggests adding these to 90 minutes calls.
      3. Need to evaluate what of these we need, what need to be updated, what can be moved to the cochair handbook
      4. Freida wanted to know who should be responsible for maintaining these artifacts
  4. UTG
    1. Co-chair Dinner messaging 
      1. Reviewed co-chair dinner slides.
      2. MK: People don't understand this is an application/software process that is replacing the old process, and that it is pushing back to the person who is making the request - that they have to adequately define their business need and it fits within the parameters of what we're doing with HL7. Ted: The whole notion of this is that the submitter of requests for changes puts their best guess in for what they think they need and send it out to the community for review. If it's accepted, it goes into the master HL7 terminology. 
      3. Critical need for educational materials and QA of the content
      4. Goal is to live for May
      5. Discussion over how WGs know where the material they need to review is, and how soon they need to review the content? Need to review as soon as possible and then review on an ongoing basis. Comes out as part of a continuous process. 
      6. Lorraine: Should add a submit feedback link somewhere obvious with a list of the people. Ted agrees and will add that. 
      7. Rob: This is making code sets and value sets visible. Need WGs to understand the importance of setting aside time at regular meetings to go and review what's on the site and compare the things you're working on for alignment. When things are found that aren't right, JIRA tickets should be submitted. Rob would like to see that this is the only place where we publish terminology content. TSC should come up with a transition process.
        • Anne Wizauer Add UTG and code sets to product management council agenda
      8. Discussion over naming issues. Ted will sit down with MK and Paul to discuss.
      9. Discussion over external content appearing in our published artifacts. The naming system won't solve the problem. Ted shows where the external code systems with agreements for redistribution are listed. Rob: We have to work to figure out how we make sure we can police the issue. 
      10. MK: We need to have a place to have this discussion for the people who are down in the weeds with this stuff. Is a Vocab/SGB/HTA issue. This is on the HTA agenda for Monday.
      11. Wayne: Need to specify and communicate the good behavior. Could be on the publication checklist, for example. People note on the PSS if they're  using external terminologies so we need to follow up then if there is an agreement.
    2. Impact on WG Health
      1. Should be defined when we roll it out - need to define compliance
    3. User interface
      1. Will be addressed during education
    4. TSC support of testing
      1. Riki has been involved - is additional TSC support needed? Ted reports they will need more support for the pilot test in March/April. 
    5. Other prerequisites for moving forward with pilot
      1. Rob: We need more people working on this who are paid who have specific expertise.
      2. Ted: Need people to help with scripting.
      3. PIC and EST should be involved.
  5. Temperature check: What are we doing right, what could we do better, and any personal issues affecting HL7 involvement
    1. Notable comments from discussion:
      1. Average members can't figure out what is going on, what to do, or how to do it.
      2. We get too caught up in administrivia
      3. Approval process is too heavy and we need to get it changed
      4. There is so much going on that it is difficult to stay involved
      5. We need to be better at communicating what is going on at the TSC and Board levels, at least to co-chairs
      6. TSC isn't getting enough information from the board on direction
      7. The good changes we're trying to make may be jeopardized by all the things coming at us
      8. Closure on things is lacking
      9. Need next generation to step up to leadership roles

Q3 - 2:00 to 3:30

  1. MK notes that business analysts need HL7 training and to be brought in to WGs.
  2. Agile Process Project 
    1. The board undertook an initiative to determine how we can make our processes less complex. Could we make adjustments to our processes for projects that don't care about ANSI normative status? 
    2. Gevity did some work to analyze and make recommendations on how to achieve that goal. Wayne presents their report, which has not been accepted as the direction. We should review what is there and present input to the board before Wayne presents it to the board on Wednesday.
    3. Lorraine; We need to still maintain quality and have an open community feedback process, even if it's not ANSI rules. 
    4. This scope covers things that are not going to go on the ANSI normative track. 
    5. Discussion over how this differs from the FHIR Community Process. This would be status in between ANSI and Community Process.
    6. Reviewed slides/findings
      1. Our idea of success is publishing a standard, but we have no way to measure implementer impact
      2. Things that have low implementer interest/importance and high interest/importance are given the same priority despite limited resources
      3. Appropriate governance bodies should prioritize all work relative to each other
      4. Would be project-based rather than WG-based; WGs don't sit over the top of projects. Domain SMEs would manage the projects. A cosponsor would have to provide a SME rather than just receiving updates.
      5. Ad-hoc project teams would be created for project delivery.
      6. 3 phases of agile delivery lifecycle: Align - Build - Maintain
      7. The build process would get earlier input/validation rather than completing everything at the last minute
      8. Discussion over continuous balloting and whether or not that would help with our issues. Scott reports that it's overwhelming in organizations that he is involved in and it leads to people not responding.
      9. Grahame: How do we get to a more flexible development path? Ballot is important and critical but not perfect for everything. Most of the community don't want to wait for ballot to comment. This is mostly to fix the trial use process.
      10. Lloyd: One big challenge with this model is that you can have a single person represent the domain. A large number of people from the domain should be reviewing. As soon as you start to do that, then the hurry up aspect of this goes away. 
      11. Summary: Applying select agile principles can improve processes. Need to accommodate lightweight publication with less onerous requirements in some cases. Need to offer flexibility and vary consensus for different types of communities. May initially pilot some of this for an alternative, streamlined process with entry criteria.
      12. Lloyd: In defining an alternate process for people who don't want normative, we need to figure out what they want instead. Should figure out what it is that people want to skip. The process is there to help meet objectives; need to know which things they are happy to do without. Jean: Who will this process be for? May end up being that no one needs this process. But we can use the work this group has done to help us determine that. 
      13. MK: In many instances there is nothing saying that an ANSI accredited guide is needed.
      14. Paul: There is no estimate here on how much time this would actually save. 

Q4 - 4:00 to 5:30

Architecture and Tooling:

  1. Project Concept Form
    1. Lorraine states that there are a few fixes to do but are looking for some people  who are willing to try it out. Point is to capture a project idea way before the level of the PSS. It would be reviewed and passed on to the appropriate WG.
    2. Who should see it and when? Reviewed business process at Business Model of Project Proposal to PSS
      1. Eventually the cochair list will see the proposed projects
    3. Change Project Proponent to "Proposed By"
    4. Move email under "Proposed By"
    5. Move "Project Description" under "Proposed By"
    6. Cross-Group Projects should be added
    7. Discussion over whether SGB, management groups should be included in the list.
    8. Does everyone have to fill these out? Wayne responds just new projects ideas. Not updates for current specs.
    9. Melva wonders if Pharmacy, for example, would have to fill one out for work they know they're going to do.
    10. Is there a penalty for not filling it out?
  2. Consensus Review Process
    1. Reviewed draft of PSS approval flow 
      1. The only two official approvals are sponsoring WG and TSC. All other groups may provide input.
      2. If there is no formal approval for management groups, US Realm, Steering Divisions, is the WG beholden to make updates based on requests from those groups?
    2. What is the role of steering divisions?
      1. If there is no formal approval process, what will steering divisions do?
      2. What should be the role of steering divisions beyond e-votes? Floyd suggested that the SD should take a look and make sure the appropriate people had reviewed the PSS.
      3. At the face to face meetings, SD would gather feedback to bring back to TSC.
      4. Lloyd: One thing they do is give new co-chairs some visibility and education on what's going on, provide a venue for deeper conversation than can happen at the co-chair dinner, temperature check function, etc. Keeps lines of communication open across WGs. 
      5. MK notes that the SD should look at it first instead of last. 
      6. Jean; If we take away PSS approval from SDs, they should become more of a communication venue. If we move to this consensus review, there is a greater chance that people will vote without looking at it.
      7. SDs should bring this up on Tuesday night
  3. JIRA Balloting
    1. Need an implementation and test plan
    2. Won't happen before San Antonio
    3. Probably will pilot in the summer before Baltimore
  4. Messages to WGs and Membership
    1. Opportunities are the Tuesday co-chair meeting and 16 minutes on Wednesday morning
    2. Nothing further than what we already discussed
  5. Adjourned at 5:03 pm
  • No labels

2 Comments

  1. Agile standards task force update.

    The taskforce asked SGB to identify what rules are needed for work groups to maintain the current status of standards (active, stable, retired). SGB is working the second iteration of that.

    The taskforce also identified that the TSC will need to put one or more workgroup health measures in place to have the statuses of standards maintained going forward.

    We also need have workgroups make their initial evaluations of the standards they are responsible for.

  2. Agile Process Project comments. What Wayne is presenting to the TSC today is based on multiple iterations between the consultants, Wayne and I and a number of reviewers. There are parts of the proposal that I support, such as creating a fast lane for standards development using Agile. There are other aspects that I don't agree with such as refactoring workgroups into domains of practice. One thing missed by the proposal is how do we actually create a streamlined, Agile standards process. One that doesn't carry the heavy weight ANSI normative balloting process. I think elements of the report will be useful in figuring out what that Agile standards process should look like. I do support moving forward with a pilot based on parts of the proposal, particularly around use of agile.