Skip to end of metadata
Go to start of metadata

Attendance can be found Here

Co-Chair and Key Participant information can be found on the Agenda found Here

Discussion items


TimeItemWhoNotes
09:00Project 1364 - UTGTed Klein

Pilot is not quite as far as hoped (but probably more than expected). Showed and explained workflow diagram. Tooling works both on Mac and Windows. Located in the Jira development environment.

Demonstrated creating a change proposal. Weighted voting is working. Will demonstrate more details in BOF session tonight. Asked to further explain weighted voting. 70% positive to approve, 70% negative to disapprove, in between goes to a resolution process. Oversight group votes have higher weight. "Super voter" (specified by name) votes have double weight.

New process will also pick up requests for needed updates to SNOMED CT and other external entities - coordinated with HTA. Initially replicates the existing manual process, but may be enhanced later. May eventually integrate with other SDO (LOINC, SNOMED, etc.) online submission tools.

Expect to have the publishing tools available soon. Hope to be able to pilot through the whole process in March Harmonization. Objective is to move all non-ballot-bound vocabulary across product families to UTG. Ballot-bound vocabulary has to flow into UTG. Grahame clarified that there are two types of ballot-bound vocabularies: (1) items like the FHIR list of resources and data types, much of it normative but also including some non-normative items, generated by tooling during publishing (2) other vocabulary is mastered by humans and ballot-bound (changed only by ballot), but can be mastered in UTG. Ted clarified that the ballot-bound material bypasses the UTG consensus and voting process. Grahame - irrespective of whether managed by harmonization or ballot this content should be mastered in UTG. Ted agrees.

Grahame wants to begin transition in May to UTG for editors. Grahame - when UTG is publishing and stable will remove the V2 and V3 vocabulary content from FHIR and do a technical correction to R4 to point to UTG. That will be true initially in R5.


IG Publisher for generating HL7 vocabularyTed Klein / Grahame GrieveGrahame - Initially defined a FHIR IG that published UTG content. Haven't done that yet for current release - Ted has done manually. Ted - objective is to use the same tooling and have the same look and feel (FHIR layout is familiar - includes the page for "Published Releases of HL7 Terminology" and similar tabs for Code System and Value Set).

terminology versioningTed Klein

Every product line has its own methodology for versioning the terminology artifacts (code systems, value sets, and sometimes codes). Consider semantic versioning. Lloyd thinks that may be excessive. Needs larger discussion. Update minor number whenever updating the current release. Major when publish a standard. Patches are used when needed.

Grahame - this use as described of updating the major version for each standard release isn't consistent with semantic versioning. Might just do it as date.patch (Lloyd suggested integer.patch). We are versioning collections - usually code system or value set, or the collection of all content (ie.g. in V3). Grahame - tooling will be through FHIR NPM package infrastructure, so it's obvious that the major version should be the FHIR version of the package. Questions and further discussion about how this will work.

Grahame - usually tell people that breaking change to a value set is a new value name, so major version is in url. Change to CLD is a minor version change. Patch is other changes. For code systems making grammatical, etc. changes is a patch. Adding codes, etc. is minor version change. Represent as minor.patch (major is implicit in the url).

We need to lay out the architecture for the versioning and further determine how this will all work together. Ted started a Confluence page on versioning. Will continue to discuss on Vocabulary calls.

Ted suggests that UTG should look like a "master set" of vocabulary that everyone draws on - similar to how it is done in SNOMED CT, which seems to be working. Need to figure out the versioning in the next several weeks so it can be implemented.

UTG will not be storing value set expansions in addition to the value sets. 2019 UTG release focuses on code systems and value set definitions. Will not take on issues of distributing value set expansions this year. FHIR has exemplar value set expansions. UTG may consider adding that later. Grahame - UTG downloaded package will not include expansions. Expansions will be generated separately (locally). Reuben - suggest UTG have on it roadmap a terminology server which can be used for generating the UTG value set expansions. Ted and Rob agree this is needed. Rob - we MUST have a terminology server that can generate these expansions. Grahame - we currently have a terminology server, tx.fhir.org. It will contain UTG content. So we don't need to do anything. It may go out for competitive bid at some time later. There are valid use cases (and we currently have them) for value sets for code systems that we can never host.



Action items

  • Type your task here, using "@" to assign to a user and "//" to select a due date
  • No labels