Attendance can be found Here
Co-Chair and Key Participant information can be found on the Agenda found Here
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 6:00 | Carol setting the stage | Carol | Lots of agenda items. |
UTG General Updates (10):
| Ted | UTG is functioning as if it were live and rolled out. 40 people are registered as submitters. Build issues are impeding progress. Documentation updates in progresss. New content creation - developers should start using UTG for non-core terminology (e.g. Code Systems or Value SEts that are IG specific) CDA content being added as it is required for CDA builds. Ongoing issues are being discussed on Zulip. https://chat.fhir.org/#narrow/stream/194616-terminology-.2F.20utg/topic/Release.202.2E0.2E0.20planning Go live to be announced at the next co-chair webinar | |
| Carol/Ted/Reuben | UTG plans to implement CodeSystem & NamingSystem resource instances for all Code Systems. Note a Code System might be a "stub" for non-identifier information - descriptive information. All non-stub CodeSystem resources for external Code Systems at least the key information as documented by HTA. Timing? Grahame Grieve (GG): For CodeSystems with just identifiers and descriptions - will we still have CodeSystem resources. Yes TK: we have one very old example of a CodeSystem that has an identifier only. Rob McClure (RM): we should move past this old example and not design around it. GG: what is Vocab asking. TK: if there are CodeSystems with only an identifier and descriptive metadata, Reuben Daniels (RD): we would simplify all of our lives if we have a motion to remove all the old, low quality, not used (see dross below) artifacts and not spend time trying to manage them. TK: One example is Medispan Diagnostic Codes. He is concerned that this might cause problems with implementers. Julie James (JJ): Medispan is a US code system and is used - not used in Europe. She agrees with getting rid of the infamous dross. TK: How do we know? RD: we don't need an algorithm, we can create a list and publish it (between 100 and 200). Put a note on Zulip and the listserve. Carol Macumber (CM): how did you identify them RD: some CodeSystem do not have a human readable name, nor an identifier,e tc. CM: please add the criteria to the communication. TK: Moves that Reuben create and publish this list including a deadline. The communication will include the action to be taken with the CodeSystems in question and the criteria by which they were placed on the list. JJ: HTA will review. RM: Define "remove" - Lloyd McKenzie (LM): he doesn't think that removing the CodeSystems Moves that Reuben create and publish a list of CodeSystems and any referenced ValueSets to be removed from UTG, including a deadline for community review. The communication will include the action to be taken with the CodeSystems in question and the criteria by which they were placed on the list. The communication will include Zulip, FHIR-I, HTA and Vocab listservs. Moved by: Carmela Couderc, Seconded by Lloyd McKenzie Vote: Abstain: 0 Against: 0 For: 20 REMAINING ISSUES Some information will be in flux as HTA is gathering information. GG: Proposes that we create an extension to indicate whether the CodeSystem metadata is fully defined. Assumes we will still publish CodeSystem definition stubs for LOINC and SNOMED CT. He will create a new JIRA FHIR-28612 - Getting issue details... STATUS to define the proposed extension with similar semantics to the CodeSystem.content element but targeted at the Code System metadata . RD: how would this extension be different than the content element. GG: content addresses the concepts; this extension would address metadata TK: is the juice worth the squeeze? should we do something else RM: Should this also apply to ValueSets? GG: lets try with CodeSystems and determine if we need it for ValueSets TIMING: | |
| See section above - especially motion with regards to community and HTA review. | ||
| Rob M. | The MIF has codes from NUCC defined in value sets and the codes are no longer valid. Most of the codes could be algorithmically replaced with newer codes. All the value sets were noted as deprecated in MIF, and some were also retired. 2 scenarios
Should these value sets be dropped out of UTG? The motion above should remove the NUCC value sets in question. However there are other artifacts where there is an issue. | |
| Retired != deprecated Retired = do not create any new artifacts referencing this artifact, it is not maintained or intended to be used as the target of an expansion Deprecated = GG: If the value set is no longer active, an expansion should not be attempted. As a general rule, the validation could be updated so that a retired value set with references in the Compose to concepts no longer in the CodeSystem becomes a warning. RM: version level value set retirement must be addressed. GG: agree The IG publisher can only publish one version of a given resource because of how identifiers are managed. However making the changes proposed above will move the needle. CC: please confirm the definition of retired. GG: definition of retired = the resource has been withdrawn or superseded and is no longer to be used (from the FHIR spec) No longer to be used? What does this mean? RM: what did deprecated mean in V3 MIF? LM: He thinks it meant withdrawn, you shouldn't use it but you can - its a warning that its currently active but on its way to being retired. RM: do we need deprecated? based on the discussion it sounds like we don't transfer deprecated V3 items to FHIR. LM/GG: there is an extension for noting a ValueSet as deprecated. (any artifact can be noted as deprecated) TK: this is good information to communicate to users. UTG will create separate tabs for deprecated and retired. Those notions should carry forward. Deprecated is a kind of active. Vocab policy: Policy on use of Retired or Legacy HL7 Code Systems | ||
| 6:50 |
| Ted | Summary of general issue - thanks Jessica Bota Due to a timing issue, the FHIR resources for the R5 preview site were updated with their versions after the R4.0.1 versions were imported We need a solution for the versioning issue with the imported FHIR code systems rooted at terminology.hl7.org -they were all 4.2.0 when imported, the R5 preview set then to 4.4.0 whether or not they changed, and we have an adopted and approved Vocabulary WG policy on CS versioning which this also violates. We need to solve this and apply the solution for the 2.0.0 release ********************* This ticket was entered by Bryn Rhodes. This is the first CodeSystem change for one that was imported from FHIR into UTG. The version needs to be confirmed/set. The only change was a clarification and a grammatical consistency update to a concept definition. GG: in general he would like to set the version for all Code Systems based on ballot status, etc. This would require a manual review. If the version numbers are reset, it could cause problems. This is risky as it might overwrite changes that have been applied. Difference between versions of artifacts in fhir.org and terminology.hl7.org? All imported artifacts were set to 4.2.0 when imported. This is the only value set that was changed in UTG that was not done in the FHIR CI build. GG: will write a tool to determine how many instances of each value set has been published and then will reset the versions in UTG and will manage the one value set manually. |
| 7:00 | Discussion and review of the HTA/Vocab single repo for external CS info made yesterday
| Transition to Rob M chairing | RD: The goal is that terminology.hl7.org will be the source for all CodeSystem, Value Set, Naming System and Concept Map information. All other existing pages will redirect the user to terminology.hl7.org. This will be a lot of work, but the work needs to start and be complete as soon as possible. LM: this would not be all information? guidance for using terminology in FHIR? RD: correct, some things would remain where they are - especially guidance TK: does FHIR-I concur with this so planning can begin? V2 management group, V3 management group are also involved. GG: In the FHIR specification terminologies page, there is a long list of Code Systems. (build.fhir.org/terminologies-systems.html) The links to "Using xxxx with FHIR" would remain on this page. Users will be re-directed to UTG. Some discussion about what to leave on the current FHIR page. TK: if we leave some code systems on the current FHIR page will be still have things in >1 place? GG: there is a challenge where the current page lists groups of code systems, not a single code system TK: lets move forward and work out the 90% RM: single repository, UTG process, clean up existing page, address the outliers RH: will the "Using CodeSystemX" pages remain in the core spec? Why is that the direction? There is no reason they need to be tied to the FHIR spec. Why not just link to them and have them as part of UTG. RD: those pages represent the effective collaboration of HL7 FHIR and the external terminology. He would like to see standalone IGs published by both organizations. He is leaning towards leaving them in the FHIR spec for now because they would be balloted. GG: the details of what is in those pages are important for implementation and are outside of what was considered within the scope of UTG. The SNOMED page in particular has proven to be very valuable. If UTG were to expand to include this information, lots to think about .... RM: we can't resolve this now but it will be considered while moving forward. Lenel James (LJ): representing folks who use this list. He supports GG in saying the uri should stay here. Having it in multiple places helps people find it somewhere. Need to transition - leave cookie crumbs. RD: he is proposing a single authoritative source. part of the reason we have the problems we have is because we have not declared a source as authoritative JJ: if people need guidance, then the cookie crumbs should be a link to the authoritative source rather than a copy of information Mary Kay Daniels: (MKD) Amen. Please confirm which tabs we're talking about - it should be the existing External tab only. Why does "External" in FHIR is not external. Some day she would like to be enlightened. CM: confirmed that all previous discussions have been constrained to the existing External tab only. LM: the urls are exposed in every value set that references a code system, and the expansions and renderings, including example instances. Once the publication happens they are locked. He claims implementers will look at the examples - they will not go to the web pages. It is too burdensome to implementers to follow a link to a web page. The publication process will access the urls from UTG so they should be correct. The publication process might not be checking the information on the existing page. RM: there is still a note on terminologies-systems.html about UMLS - there should be a ticket in to address this - GG: Moves that the ticket FHIR-27805 be approved and applied FHIR-27805 - Getting issue details... STATUS by following the suggested action. RH: Seconds Vote: For: 17 Against: 0 Abstain: 0 MD: will all this discussion and decisions fix her problem - what to tell implementers creating new CodeSystems under pressure. They are going to let the IGs go and then a project will redo all the terminology artifacts? Vocab: harmonize the code systems for MD's project and follow the UTG process. (note - these were balloted, knowing the terminology wasn't there, tickets were entered, everyone has created their own code systems, each guide moved forward independently. GG: HTA has the authority to create urls for external code systems - for all HL7 IGs for affiliates. This might be a process issue. LM: what is the maturity level of the IG? the expectation is that you will move to the right external terminologies by level 2. Engaging HTA early in the process is key. It may make sense to publish with a code system that is clearly noted as planned to be replaced. RM: maturity level is the key RM: MK do you have a sense of how many code systems there are and how mature the IGs are? MK: NUBC revenue codes - they have gotten in hot water with AHA. We have an SOU. They have the spreadsheet in their hands, she has no idea how long it will take AHA to review the information. Carin, PDeX, CDeX are some examples. RM: a few code systems that are widely used MK: yes - for example CPT4 modifiers. We cannot make the stewards move faster. One guide is for legislation for Jan 1, 2021. It will be stuck. RM: he senses that MK's situation, immediate need, perhaps needs some further discussion regarding managing the publication process that does not put HL7 at risk. Where do we find the time slot to further discuss? GG: MK's issues are complex - copyright, content, etc. The attendees are trying to figure out how to help this project. We need a time slot. Time slot discussion: Vocab is free between 1:30 and 3:30 EDT Friday. Or before 10:00 am. 1:30 works for financial management. Carol can attend for HTA. CM will add the session officially. Vocab will host FHIR-I and FM - focused on publishing changes to. GG: requests that MD create a succinct issues list. RH: he is joining MD's call tomorrow |
| |||
| |||
| Rob H. | Add on to the call scheduled for 1:30 Friday September 25. | |
| Ted | Ran out of time, this will move to a Zulip thread. | |
| Fragments | |||
| |||
|
Action items
- Reuben DanielsWGM 9/2020 Act on this motion: Moves that Reuben create and publish a list of CodeSystems and any referenced ValueSets to be removed from UTG, including a deadline for community review. The communication will include the action to be taken with the CodeSystems in question and the criteria by which they were placed on the list. The communication will include Zulip, FHIR-I, HTA and Vocag listservs.