Skip to end of metadata
Go to start of metadata

Meeting url: https://join.freeconferencecall.com/vocab

Date

Time

3:30PM EST (UTC-5).  Note that the clocks in the US have gone off of summer time!

Attendees

Planned Agenda Topics

  1. Roll call and Agenda check (Ted)
    Call commenced at 3:35 PM with quorum reached and good attendance. 
    No new items for agenda.

  2. Announcements (all)
    •  Harmonization meeting was held this past Tuesday December 3.   Approved proposals are in the process of being implemented.  QA release is scheduled for early next week.
    • We need to be certain about the required timeline for nominations for the cochairs whose terms end December 2020 (Heather, Carol, Reuben, and Carmela)

  3. Action Items Check  (Ted)
    Carmela completed some of her items; there appear to be a number of them that are actually competed and there meed to be reviewed.  We can circle back to review these if we have on today's call..  List of open tasks on main Confluence Page:.  Decided not to review the open action items on this call. 

  4. Sydney WGM Agenda Planning (Ted)
    Can be found here.   We moved a few items around and added topics to some of the slots.  
    1. We need to verify the CIMI quarter; if it will not happen then we need to use this quarter for FHIR Tracker items.   If we do have a full CIMI quarter, then we need to figure out where else we can find time for FHIR Tracker Items.
    2. We do have a room for the split quarter with EST oil Thursday Q3.
    3. We need to determine if there should be a UTG demo for interested parties (ONC or others) and when in Sydney.
    4. HTA making progress on template for dealing with external terminology organizations; work is underway with process for using it.  Will be discussed on HTA call this next Tuesday.


  5. UTG Update
    All information is posted on the UTG confluence pages.
    Focus on completing remaining development efforts to get a full functional system by Christmastime. 
    1. Code System polyhierarchy discussion
      Several WGMs ago, a decision was taken to change the representation of code systems having codes with more than one parent.   This was discussed at length, since the current FHIR design of the resource is to have the hierarchy represented in the tag structure itself.  In current FHIR, if a code has two parents, it is represented as if it had only one parent under one of them, and each of the others has a property "child" which lists the other children of that code that are not in the code's xml hierarchy.  Which parent has the actual code instance with all of its own properties is essentially random, and determined by the software that creates the resource.  Thus each parent has its children under it and also lists with a property their other children.   The UTG design that was originally decided was to represent it the inverse way; to have the codes in a system where the codes may have more than one parent to have a property 'subsumedBy' pointing to their parent.
      As FHIR has not implemented this, and assertions have been made that there is no advantage to doing it either way, we need to reaffirm a decision today in the WG whether we ask Grahame to change they way FHIR is doing it, along with the changes to the IGPublisher which generates the rendered tree structure, or to modify the UTG import to change to the way FHIR has been doing it.
      Change FHIR to the UTG Design
      Pros:  it seems more sensible that codes in a hierarchy point to their parents, rather than codes listing all of their children in those code systems with polyhierarchy
      Cons: hierarchy representation will be different between code systems with single hierarchy and those with polyhierarchy.  Big impact on existing FHIR servers
      Change UTG to match FHIR
      Pros:  the exceptional case of codes in multiple trees are the only places where the special property is used, and everything is done consistently; no impact on current FHIR material, current rendering in IGPublisher handles it properly already
      Cons: it will take some non-trivial development to implement ($$), first appearance of the code in the xml structure is random

      Motion to change UTG to follow the FHIR approach as outlined above.  No one else on the call was comfortable seconding the motion, motion is rejected.
      It was noted that our Normative FHIR spec says that doing it the FHRI way "SHOULD NOT" be done.  But this is not incorrect, and in fact it is the way the Australia terminology service, Michael's, Peter's and Apelon's all work currently.   Since that is how the FHIR resources have been published.  It is noted that folks are uncomfortable making a decision that seems to go against our own Best Practices recommendations simply because the inertia of having it done currently and for the past 3 years the other way is too hard and expensive to expect a change to be done in reasonable time and with reasonable resources.

      Rob suggests that we do it both ways;  the UTG resources do it the Best Practice way using 'subsumedBy' as current, and were ask Grahame to change IGPublisher to render it properly either way the underlying resource is structured.  Ted notes that we must have the final implementation done and debugged in less than 5 weeks for the January 20 TSC demo.

      Carol suggests that we document that Vocab WG recommends that we do it this way (UTG does the recommended practice) and ask Grahame to implement in some way (inline IGPublisher, or a preprocess transform in the pipeline in front of the launch of the ciBuild.   We communicate this to Grahame immediately and if it is a nonstarter the we revisit and make the final decision on next Tuesday's UTG call.
    2. In-depth TSC demo will be during the January 20 TSC conference call.  Everything as to be working and looking in its final states (but known that debugging will continue so it may be buggy) bu them.
    3. Active list of bugs and issues to be corrected in software (IGPublisher, Editor, TxServer, JIRA workflow, etc.) can be found here.  Some key ones are:
      1. Have a number of IGPublisher issues, including the internally generated html <href> links from the value set expansions are not pointing to the UTG content, but rather back to the FHIR R4 content.
      2. Display of code properties in the codes listing in Code Systems
      3. Still unknown the status of the 64 bit update for the tools
      4. Josh is actively working on finalizing the sync issues between GitHub and BitBucket; we have now a fully documented flow and state model and we think the update to the design will be bulletproof.
      5. UI and public facing name of the website and the publishing service for terminology under active discussion with the CTO and Marketing folks at HL7.
    4. Must determine any ONC demo for Sydney
    5. Need to begin discussions of IGs.

  6. Tracking Changes to VSD (Carmela)
    Changes to VSD have been identified as a result of the VSD-P project. We would like to track those changes somewhere. CC requested a new JIRA project from HL7. The request was not accepted. CC created a confluence page to track the changes, which is not an ideal solution. 

    Thread from email discussion relative to the rejection of creating the JIRA projects
    The intention is to have a Jira "Specification Feedback" tracker for each product family.  VSD would presumably fit into the 'other' category.  This will tie into HL7's plans to use Jira as the mechanism for all balloting.  Because of that, it's essential that all product families be driven by the same workflow, field configurations, security schemes, etc.  If that doesn't happen, the new balloting mechanism won't work.  The current plan is as follows:

    - shakeout and tweaking of existing FHIR Jira environment (1-2 months)
    - finalizing development and testing of "balloting in Jira" functionality (2-4 months)
    - add support for additional product families (likely prioritizing CDA and v2), including figuring out how to port existing feedback if possible (by end of next year)

    We're trying to *not* introduce new Jira projects for feedback on specifications because we don't want to have to migrate that content and don't want to confuse users when we delete any temporary trackers.  At the same time, there's certainly a need/desire to leverage Jira for this purpose.  In general, the feedback is "if you can wait, wait.  If you can't wait, we'd prefer if the solution wasn't Jira and be aware that you're going to have to figure out how to migrate whatever temporary solution you have *to* Jira once your product family Specification Feedback project is in place.


    There are folks especially in the international community that have already solicited comments on some HL7 specs (such as VSD in Canada Health Infoway) to hundreds of users.  Where can thee feedback be collected, other than in the email inboxes of the vocabulary cochairs?  What is the HL7 process for feedback about specifications that are published by HL7 from members of the comunity outside of the ballot pools and outside of ballot preparation HL7 groups?  How are issues in the HL7 products going to be tracked when outside of a ballot?   e.g. the things that gForge is now commonly used for.  Is this an SGB issue on governance of the evolution of the HL7 products?
  7. FHIR Tracker Items (Rob Hausam) 
    1. Updates and plans for ConceptMap block votes
      FHIR Concept Map Resource Block Votes

      Details from the tracker calls reviewed and documented on the November 7 call; notes can be found here
      Comprehensive list of tracker items can be found here

      Discussion has been ongoing about whether we need to implement what haas been voted on by the tracker group in the ciBuild before we get to the final end point, or just try to move quicker to get these items resolved and into the current build (about the concept map relationship codes).  Today Rob Hausam is asking the Vocabulary WG to offer an opinion on the two codes that are changing meaning ('broader' and 'narrower') whether we should use new codes with the new meaning, or change the meaning of the existing codes (this is to clarify the relationship between the source and target).  Note the this code system is new and not yet in use.   Rob H is uncomfortable with the same codes essentially have their meaning reversed, and there is desire to have the direction of the relationship in the code value themselves.   So the new codes would be 'broader than' and 'narrower than'.    This would involve changing all the new implementations that are starting to use these codes in conceptMap.   Carmela noted that this is different than the last discussion on the calls, and is different from what is documented in the ticket and requests that we have better transparency.  Rob notes that the demostrated new codes were not in the build it was just for implementation.   The group has expressed agreement with doing this and asked for it to be documented.

  8. Gender Harmony Project Update (Carol/Rob M) 
    Item tabled, out of time.

  9. Liaison Reports   out of time, item tabled

    a. ISO (Ted) - ISO TC215 US TAG call held today (Ted and Wayne in attendance); next ISO TC 215 meeting end of March in Washington DC (Arlington).   Fall 2020 meeting in India.

    b. LOINC (Ted/Rob H) - Next LOINC meeting will be in Indianapolis...

    c. SNOMED (Rob H/Reuben/Peter) - 



  10. New Business -
    No new items.

  11. Next call items - 
    1. Do the needed block votes on the FHIR tracker items.
       

Call adjourned at 5:03 pm. Next call in two weeks on December 19th, same call-in and screen share credentials. 

Action  items

  • Ted Kleincontact Karen about the dates for the cochair nominations.
  • Ted Klein reach out to Frank Oemig and Rob Snelick on topics for the joint CG quarters in Sydney
  • Carmela A. Couderc to send an email to Austin (TSC) and Paul (SGB) about the VSD issue tracking.
  •