Page tree

Date/Time 

01:00 UTC on Sunday 27 October 2019 - Kuala Lumpur, Grand Hyatt Hotel, Grand Residence 102

Specifically 01:00 the 2nd time around in the UK

09:00-12:30  MYT (Catered break: 10:30-11:00 in Grand Salon 2 Foyer)

Meeting Details

Onlinehttps://snomed.zoom.us/my/snomedhl7

Phone: See https://zoom.us/zoomconference for available phone numbers (meeting id 242-348-6949)

Chat: snomedIntl.slack.com #snomed-hl7-fhir


Discussion items

ItemDescription

Mins

OwnerNotes & Actions
1Welcome and introductions10

Recording + Notes.

Statement of intent: To discuss the proposed approach on the additional of new Concepts to support an equivalence mapping with various FHIR ValueSets. Agree how to manage that new content.


2

FHIR Free Set

Proposal for supporting FHIR ValueSets in SNOMED CT

30

FHIR SNOMED CT Free Set - Consider for inclusion / rejection (Red mappings)

Update from the morning meeting.

To clarify: is any modification of the existing Qualifier Value hierarchy required or are we only looking at additional of new content.

Do we need to go back through the list and agree what could be part of the GPS and what is too large / too clinical?

106234000 |General adjectival modifier (qualifier value)|

3Review of existing work40

Review of Mappings done by SNOMED on FHIR group:

Where existing items have mappings suggested outside of the Qualifier Value hierarchy, will we continue to use those?

If an existing mapping is to a qualifier value - exactly matching the word - but has context, will we move the concept to remove the context, create a new concept (duplicate word in same subhierarchy) or use existing concept as-is.

4Proposal for addition of content from HL730
  1. CRS Access (existing HL7 Account) Discuss with Maria Braithwaite re stats inclusion.
  2. Review needed by HTA?
  3. Option for one-off bulk import to avoid intensive manual work.

Note too close to cut off for the January release, new content will appear in July 2020.

NB We need (semi?) automatic inclusion in the FHIR Free Set which by definition is then part of the GPS. Discuss with Rory Davidson.


5Abstract Normal Form and normalising Resources

GG "Keith Campbell spoke to me about a SNOMED related connectathon stream (around Abstract Normal Form and normalising Observation and Condition resources) at the HL7 meeting in Sydney. [This] overlaps with (or depends on) some of the agenda items on here. I do want to set up a meeting to talk about the connectathon stream - it’s not clear to me whether we should just do that as part of this meeting, or find some other time for an informal meeting."

PWI We've discussed this (although not to great depth) as a bidirectional mapping between a Resource instance and the equivalent Post Coordinated Expression, ideally via named slots in templates defined for each Resource.

May be relevant - snapshot of a slide from a presentation by Keith Campbell:


6Stating of problem

Simply replacing FHIR ValueSet members with SNOMED codes does not add any value beyond support for a single technology stack. The benefit appears when we can map between FHIR and SNOMED CT in a way that allows a given set of elements to be normalised to a single Post Coordinated Expression(PCE). HOWEVER, we cannot just add qualifier values to do this because the PCE must subsume as expected in the existing SNOMED hierarchy.

Could consider rules that detect the presence of - say - in remission and ensure that 765205004 |Disorder in remission (disorder)| is part of the ancestry. This may be unnecessary complexity

Problem on SNOMED side: SNOMED has context built into the hierarchy via Primitives rather than modelling eg 765205004 |Disorder in remission (disorder)| The lack of modeling here explains the lack of attribute value for our mapping. However, adding context explicitly would necessitate moving (or cloning?) diseases into the situation with explicit context hierarchy and that would be unpopular with existing implementations.

Problem on FHIR side: The condition-clinical valueset (as SI sees it) is a mix of Finding Context and Clinical Course.

These issues may not be problems individually, it is when the two system meet and interact.

Additional validation rules could be added to prevent these undesirable combinations.

7Way Forward

  1. The group here felt that the addition of qualifier values without context does not address the main use case and was therefore not a viable direction of travel.
  2. The use case came from the VA. It is suggested that they could experiment in this area and see if a most attractive solution presents itself. "We haven't even touched on role grouping here".
  3. Suggestion of SI Workplan project (SI internal escalation) to look at the practical use of SNOMED CT in Clinical Practice to support Data Analytics as part of SI's 5 year strategy.
  4. Short term suggestion that in the contexualisation and identification of a SNOMED CT concept from a FHIR Resource avoid the use of those disease subhierachies which contain primitive based context like "in remission". The isomorphic solution will be longer term.
  5. Further analysis by (initially) the SNOMED on FHIR WG of the clinical status codes and where they align with SNOMED hierarchy 'features'.
8Final Position20

Consideration of what from this should be mentioned the Expo presentation.



9For follow up - action plan20

SNOMED on FHIR group to examine Genomics and Care Planning ValueSets (see left column in Free SNOMED CT set for FHIR)

Note that cut-off for July release indicates we need to aim to complete new content for mid April 2020.


Meeting Files

  File Modified
JPEG File KC_Presentation.jpg 2019-Oct-28 by Peter G. Williams