Page History

The base issue is that the datatype allows references in both directions. There is no ability to control which resource types make sense for a resource type. Difficult to control mustSupport, etc. 

This was originally just in the Decision Support resources, and it is popping up all over the place. Its not clear whether that is a good idea. 

The Decision Support workgroup has primary control. M&M has brought some issues to their attention. 

Has Vocabulary looked at this and evaluated it from an 80% rule perspective - all the resources make sense. 

Will 80% of implementers support the datatype for ConceptMap? 

Since this was added in the extension space, it is less of a concern, and might not be of any concern. However, if you use the extension, you have to support the full extension, you can't pick and choose. This is more of an issue for CDS, M&M is working with CDS on this. 

Nothing more to do.

This ticket has been applied. 

The material presented at the co-chair webinar was reviewed. Attached to the minutes below. (see section on FHIR Updates -Development and Balloting Roadmap
Terminology Expectations)

2022 04 07 - Co-Chair Webinar.pdf    (note this is the ppt that was shared at the co-chair webinar, and this session covered the topics and identified where changes need to be communicated - the material had not been vetted by vocab or TSMG)

• didn't distinguish between code system and code review/approval by TSMG
• declared that pre-FMM3 the code system URL MUST include the word "temporary"

Discussion:

• Should not force the use of temporary in the url when the code system is known
• Referenced internal identifier task force, 2 step process for code system definition in UTG/THO
  • Pro-forma adding the stub
  • Add the content (the concepts)
• Concern about having time to review
  • LM is concerned that the IG authors will not be able to decide whether code/code system selection is appropriate, and TSMG should review each and every code system
• Transition from testing an IG, piloting and actual production use can be painful
• Are we conflating 2 items that may be changed and might not be crystal clear ahead of time?
  • URL
  • Content
• The internal code system task force made the assumption that the default is that everything is shareable in the CodeSystem space. 
  • Once beyond a maturity level, it needs to move into THO
  • LM contends this would be FMM 3
• RH: usually people writing an IG have some idea of their terminology needs. The proposal was to request a url from THO. (the pro-forma proposal)
• LM: the process to request a CodeSystem in THO is not one that we can expect IG authors to use.
• TK: we defined a pro-forma process that is a simple workflow. Currently this has been implemented in UTG, CI build. And it creates the url anchored in THO. And it will appear in the Pending tab.
• MaryKay: she is managing 115 vocabulary tickets across 5-6 IGs - their guides will have to make changes - they are aligning their code systems and value sets. They also have code systems that are part of the base specification that are caught up in this issue - agrees with LM that there are some code systems that they just don't know what is going to happen. (for example PCT - regulation isn't complete - for those - the heads up across the community developing the guides is the best they can do). For others, when they know an industry standard can be used, its easier for implementers to get the code systems in THO. Right now they have to cross walk codes across versions of IGs.
  • Some of the code systems will end up being IG specific.
  • There needs to be a way to raise these issues across work groups/Accelerators - etc. 
• LM: we would end up with a pathway where if external, and you know what you need, use it day 1
  • if you're confident you need a code system, but you aren't sure of the codes, request a code system url in THO
  • define the code system content internally now, and then move to THO
  • if always IG specific, not appropriate to share, go to TSMG and get the blessing on the assertion
  • if just not sure, no idea, use the temporary phrase in the url 
• TK reminds us that Vocab tested to make sure the URL can be anchored in THO, and the content can be in the IG

• LM: still have a risk around implementers not knowing what they are doing. That risk won't go away with process improvements
• TK: mentions benefits of transparency, community review, reducing rework as a result of duplicate work (as occurred with Carin)
• LM: from a validation perspective, check to see if the code system is recognized, is there a CodeSystem instance in THO, (or maybe tx.fhir.org), or a NamingSystem in THO. Warnings if the url is in THO, but not the content (FMM 3 or above). No warning for temporary in the url if FMM < 3, error if temporary in url if FMM 3 or above (applies to external code systems)
• Will need to clearly define the interaction between THO and FMM. 

• JH: she continues to comment and recommend that content be in THO; provided links to best practices

Value Sets

• Discussion about whether they should be in THO
• RM: the issue is one of how aggressively we want to get in front of the process, and the statements made at the co-chair call were very strong
• LM's statements at the co-chair meeting were very strong, (e.g. must be immutable, and be complex) to add to THO
• RM: we should encourage people to put value sets in THO so they can be shared.
  • we have situations where the community would like to get a shared understanding  
  • it should be easy to add value sets into THO
  • this should not be discouraged
• LM: sees little value in putting a value set in THO - there will be too many to find a useful one, and one that is well curated
  • he doesn't see value in putting simple value sets in THO
• MaryKay
  • This may be implementation specific - for example across the claim data reporting IGs (Carin), and the PCT work, those value sets absolutely should be shared. There are other situations where it might not make sense for value sets to be in THO. 
  • When the funding ends after the IG is published, it can be painful to deal with the duplicate value sets
• TK: agrees with MaryKay
  • Stan Huff - real world experience found that in some spaces value sets are shared and should be shared, and in other cases they are almost never shared. Maybe the clinical value sets won't be shared, however its difficult to draw a line. 
  • Don't put any obstacles up for making a value set shareable
  • Change the messaging 
• DG: lots of sharing of value sets in the research space
• GG: what are the best practices to share value sets beyond them being in THO - we should invest some time in providing advice to the committee. 
• RM: some committees are creating shared libraries. He agrees UTG is a barrier, as is the lack of a terminology server. (GG mentions that tx.fhir.org is a terminology server). RM reminds him it is not the official terminology server offering up HL7 terminology. 
  • This disconnect is a concern. tx.fhir.org is the publishing terminology server. not a production terminology server. 
  • He is fine with us encouraging parts of HL7 to create shared libraries - use THO
• DG: mentions recent experience with value sets. Hopkins has the largest repository of observational data. They have found a great deal of utility in providing "vanilla" value sets. There are also commonly used assessment instruments for which there are associated value sets. She sees sharing value sets as useful. 
• JM: from the chat: Need published best-practice that express the desired best-practice. They should be full of loopholes for appropriate use. But I think there are many people/IGs that want to do the best-practice but have no idea what the best-practice is.
• MD:
  • it would be nice if value sets end up in THO, its not a SHALL, its an "it depends"
• LM: 
  • has some ideas, about maturity, comfort level, immutability, etc. 
• CC:
  • This should be a TSMG task to create the best practice documentation. Be careful about making statements about most, many, etc. with regards to value sets. 
• MD:
  • Would JH withdraw her negative ballot comments? 
• RM:
  • the likelihood is that shared libraries will be created so that value sets can be shared - this might be something to incorporate into THO
• LM:
  • moving value sets is easy, the value set url isn't exchanged
• DG:
  • here is an opportunity to bring the rigor of standards development, good vocabulary management to the science, there are some very simple things that we can do to make a big impact. For example - defining a value set for pregnancy status (see mention above). 

Final thoughts/Action items:

TK: do we have a final decision with making the pending code system tab real or not?

RM: we need a restatement of what we agreed to, voted on by FMG and TSMG. Jess will add this to the TSMG call Q4 Thursday.