Attendee type:

M - TSMG Member

O -Observer / Guest

Attendance:

P - present

A - Apologies

X - (Apologies with Proxy)

Name

Affiliation

Administration

• TSMG appointments for 2023
  • Slate needs to be developed
    • Expiring members and willingness to stand again (y/n)
      • Davera - yes
      • Sylvia - ?
      • Rob M - no
      • Peter - no
      • Michael - yes
      • Roel - yes
  • Term feedback from TSC
    • Proposed that terms are limited to a maximum of two (2) two year terms or a total of four(4) years. 
    • Applies to current members?
    • What happens if a slate cannot be filled, would current members be provided an exception if they're willing to stand for appointment
    • RD as a caveat to acceptance. the policy for filling the empty seats should members fulfill their terms per policy be forced off and there are no prospective new members to fill the seats needs to be established.  
      • If no candidates come forward to fill empty seats, then there needs to be a policy in place to proactively deal with this situation 
    • LM: the issue in CMG was not having folks roll off, but encouraging new membership is a better focus.  The CMG policy is to ensure there are invitations to two new members.  There is a plan to seeking and inviting new members as a proactive process.  CMG has struggled with attrition.  The focus of the policy therefore is how to sustain the management group rather than limit the terms. 
    • RM:  alternate member slots could fill vacant member slots.
    • CM: next steps are to "clean up the notes" so that RM can take back some feedback re: this discussion

Agreement Announcements

1. https://www.ohdsi.org/snomed-collaboration/
2. https://www.dbmi.columbia.edu/ohdsi-snomed-collaboration/

Review terms of agreement

• SR: Agreement enables utilization of SNOMED CT in OHDSI work products for research purposes without license
  • restricts use of SCT extracted for work 
  • provides a way for OHDSI users to utilize SCT and ensure appropriate IP for SCT 
  • CR is providing modeling feedback pertinent to research / OHDSI community as a component of this cooperative agreement
• CR: OHDSI business focus is for research (populations) as opposed to focus on patient care for other SCT use cases 

Implications for HL7 standards and Terminology management practices

• RM: anything that is not SNOMED in OHDSI, how will HL7 represent that?
  • Also will SNOMED be directly represented in OHDSI?  for HL7 how will we represent those concepts that are coming from OMOP, are these still SNOMED?
• CR:  these are SNOMED concepts, we give them a different identifier, but it is still SNOMED. the identifier doesn't impact the identifiers.
  • If you create messages, then this is a different use case than is asserted in the OHDSI / SNOMED agreement requiring a different license
• RM:  would like to focus on representational model
  • OHDSI sending an SCT concept:  then HL7 will need to figure out what 
  • CM: a supplement with OHDSI identifiers for SNOMED may be one possible solution
• CR: If you convert OHDSI to FHIR, then you can use this conversion to interpret the meaning of the SNOMED code
• RD: SNOMED to OMOP use cases is this the full international edition of SNOMED.  SR:  the version as accepted by the OHDSI team.  whatever that team uses.
  • what about affiliate editions of SNOMED CT.  SR:  this agreement doesn't apply to member editions, only the international edition of SNOMED CT
• RM:  are the SCT identifiers exactly the same within the OMOP namespace, and these never change?  CR:  that is correct. 
• CR: access to the terminologies in the OMOP Vocabulary is dependent on whether the accessing entity has licenses to the source (before OHDSI) content
• RM: need to make arrangements to host / access OMOP vocabulary content within HL7 for purposes of representing OMOP within the HL7 
• CM: requirement for an HTA record for OMOP Vocabulary
  • how / whether to obtain content from OMOP available within the THO is a decision for the Vocab WG
• RM:  need to also be thinking about creating an IRI for the OMOP vocabulary (in addition to the code system identifier)
  • The OMOP code system obtains information form a variety of other terminologies (with its transformation)
  • When that information from HL7 goes to another system (OMOP to HL7 to CMS system) will require additional information about the source coding to support exchange
  • Issue of concepts having more than on identifier presents a problem, and in this case perhaps this also adds more than one code system in addition of the identifier
  • There needs to be a conversation about how to accomplish these "rules"
• RM: question to Suzy... this is a second example where SNOMED has a second identifier (OMOP & LOINC)
  • SR: more than one concept identifier, SNOMED prefers the use of a single identifier.  We are allowing this with the agreement with OHDSI.  This is being negotiated with the Regenstrief for LOINC at this time.  Not allowing the generation of new SCT identifiers inside of LOINC
  • RM: traditional SCT identifier... can we send an SCT identifier but identify that as an OHDSI concept?
  • CR:  no we will loop back to the original SNOMED.
  • RM:  for any HL7 exchange the sender will have the requirement to indicate this is SNOMED, and revert this back to a SNOMED identifier
    • CR: for  FHIR message, you should issue the terminology and the original concept ID

• Update
• Proposal: TSC Product Management Council

• Follow-up from WGM - next steps re: terminology server (service) requirements (1-page description)
  • Needs to clearly state why we do not have what is needed in the currently available services including THO or tx.fhir.org
  • Jess / Reuben / Rob Hausam/Davera
    • working draft of the document is here
    • initial conclusion for editing period has passed