Peter G. Williams

Rob Hausam

Recording + Notes.

Jane Millar

Peter G. Williams

Peter G. Williams

Rob Hausam

2019-01-08 - SNOMED on FHIR Meeting (TS)

2018-12-18 - SNOMED on FHIR Meeting (TB)

Jane Millar

Rob Hausam

Daniel Karlsson

Meeting with Keith & Graeham Grahame (notes by Daniel Karlsson):

Keith Campbell and Grahame Grieve are only interested in equivalences between FHIR concepts and SNOMED CT concepts (how equivalent is equivalent?) and thus we should aim to sort the cases into equivalent and non-equivalent. Keith’s intention is to allow (some?) reasoning across FHIR and SNOMED CT representations, with likely significant impact on the SNOMED CT concept model. If we can move from amber to green, that’s good but if it’s not possible it’s not possible. When we have agreed on a list of equivalences HL7 will take the rest and create SNOMED CT concepts in their extension to allow (partly?) representing FHIR CodeSystems content in RF2. SNOMED I will publish the set of equivalent SNOMED CT concepts as a free for use set.

We might still discuss what is our equivalence threshold, from lexical to concept-model equivalence, but I suggest that we limit the number of additional meetings we spend on this topic.

Jane: Clarified the function of the SNOMED on FHIR group with the HTA. Keith's use case is in transferring data between companies, so a shared extension would help with this. HTA discussion on how to input to this group - SNOMED on FHIR may be added as official project to HL7's list - RobH progressing.

Daniel: This group is being asked to check alignment and provide list of "Red" value sets to HL7 so that they can add concepts to SNOMED in some extension. Question around how much 'context' is included in our selection of concepts (on both sides).

Jeremy: Notes that mapping to only certain qualifier values could lead to records not being found if some wider SNOMED CT set of values is used which wouldn't match with a reduced set via FHIR. We should include discussion of how this map should be used in various situations.

Rob: FHIR R4 published in December. R5 work underway (ML: watch concept map going normative!), targeting Q3 2020. Lots of IGs being balloted (eg IPS). See list of resources going normative at https://onfhir.hl7.org/

Jane Millar

Jeremy Rogers

Daniel Karlsson

Daniel Karlsson

Publishing Profiles

• Wrapped by implementation guide - in this case https://github.com/IHTSDO/snomed-ig
• Value set publish to a live SI hosted Snowstorm instance. Alternatively Michael Lawley has offered to host.
• Additional hosting on Simplifier (STU3, not yet R4 - January?)
• Suggestion to review work already done to ensure R4 compatibility
• Would value sets also be published as reference sets? Maintain via Refset tool and published in MLDS. Note: UK experienced substantial 'getting off the ground' effort in this area. Sweden have worked through ~10 (will request promotion of content to International Edition where appropriate).
• HL7 FHIR Registry?
• Option to have multiple profiles available at the same time using slicing.
• Chance to do some technical work at HL7 San Antonio

• •  Peter G. Williams discuss Rory Davidson

Daniel Karlsson

Vital Signs Resource

Jeremy's work to compare Vital signs profile and SNOMED Subhierarchy - issues with eg blood pressure. Complex expression constraints available which cover the use of observables by the NHS(UK). Mapping to LOINC codes.

See Spreadsheet attached to: SNOMED on FHIR Meeting (TB) - Tuesday 21 August 2018

Issues / Discussion :

• Normative vs. descriptive purpose - 1, 2, or 3 profiles?
• Unresolved modeling issues
  
  

Daniel Karlsson

Neither of these exist in the FHIR 3.0.1 Spec. Rob Hausam

http://build.fhir.org/servicerequest.html → ServiceRequest

Questions:

• What determines which FHIR resource to use: the location of the data item in the sending system’s information model, or the semantics of the particular code regardless of where it was found? Some hybrid of both?

• If the resource to be used is determined at least partly by the location in the sending information model, how does a requesting system cope with the fact that different implementations (or different users of the same implementation) both can and do secrete essentially the same clinical info in very different parts of the host information model?

Tuesday 5 February 2019