Page tree

Date/Time 

20:00 UTC on Tuesday 1 October 2019 - 90 minutes.

Objectives

  • Bindings to FHIR Clinical Resources (e.g. value set bindings)

Discussion items

ItemDescription

Mins

OwnerNotes & Actions
1Welcome and introductions5

Recording + Notes.


2

Summary of previous week (TS) and previous TB

5


3Future meetings5Jane Millar
  • Jane Millar To draft abstract for October Expo presentation

KL Meeting - JR can we do some connectathon type activities at the Sunday afternoon?

Next FHIR DevDays Amsterdam, November 20 – 22, 2019

14 September Atlanta connectathon will feature breakout session for SNOMED CT Terminology Services

Peter Jordan suggests creating the relevant ValueSets to support our suggested bindings for current profiles.

2019-10-01:

An hour slot in the Expo (as opposed to the planned 30 min slot). Peter G. Williams Discussion about the presentation on next call 2019-10-08.

4Information Model Binding & dealing with overlap60Kirstine Rosenbeck Gøeg

2019-10-01:

Excellent presentation by Kirstine Rosenbeck Gøeg on experiences of real-life terminology binding.

Suggestion to start looking at more complex use cases (as opposed to or in addition to single profiles) to derive good practice. Also suggested to look at the use cases from data input, storage as well as analysis perspective.

5Free Set Response5Group discussion on response to HL7 for Free Set / Mapping by Jim Case (see update July 2019) here: FHIR SNOMED CT Free Set - Consider for inclusion / rejection (Red mappings)
6Implementation Guide

Did we conclude on the best approach(es) for semantic overlap between fields as discussed in Terminology Binding

Update: Option 4 seems the most elegant - "BodySite must always be a specialization or self of finding site" although BodySite is an easy example since the mapping to the SNOMED concept model (finding site) is well understood. It would not work for Condition.Status where resolved/remission is not represented in attribute values.

Update 17 Sept: If we were to express ValueSets for profiles using Refsets (which this group would have to curate and publish) then National Centres could add to those refsets using their own module.

7


If a refset contained a query specification which was referenced as ECL in a Valueset which was expanded, is it obvious that we would want the result of the query, rather than the query itself? ^^ double expansionMichael Lawley ecl=^1234556701

8Free SNOMED CT Set for FHIR

Free SNOMED CT set for FHIR

25 June. Grahame keen to see work done on both sides to bring us closer together in the ValueSets concerned with clinical safety:

-          AdverseEvent.outcome (red)

-          Condition.clinicalStatus & AllergyIntolerance.clinicalStatus (amber) These are the same items although in separate Valuesets. HL7 could discuss making them a single ValueSet.

Update 1 October


  •  
9Observation resource

See updates here: Observation binding


10Exemplar Profile

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

Options for Profile discussion:

Notes 26 Feb: UK working on pathology reporting - diagnostic / observation.

Suggestion that we try out two types of profile, both of which avoid issues of conflict between fields within the information model:

  1. Where we only use the code field for clinical content (plus the administrative fields)
  2. Where we restrict the code field to atomic values and all other resource fields should also be populated. Note that this does not solve the role group problem.

28 May: Plan to publish profile for the October conference (8 sessions + working between meetings. Completion for review Tues 14 October (or earlier since we'll need time to complete the IG?)

  • Build implementation guide
  • Setup FHIR server with relevant valusets

Tooling for profiles: Forge (.NET) is now R4

  • Daniel Karlsson to try loading existing Allergy Intolerance profiles into Forge R4. The STU3 profiles loaded fine in Forge R4 as just STU3 profiles. There are almost no changes between STU3 and R4 for AllergyIntolerance, so by manually changing the XML files from "3.0.1" to "4.0.0" the files showed as R4 profiles with no errors displayed. Files uploaded to profile page.
  • Rob Hausam to take Observation questions to OO group.

RH: Suggestion that "published" valuesets would be read-only.

11

Allergies


Revisit any outstanding questions on Allergies.

External publication of v0.1 of the AllergyIntolerance resource

12Vital Signs10Daniel Karlsson

Vital Signs Profile of Observation 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

2019-08-20:

Update of the Vital Signs panel binding page.

Discussion about the Vital Signs FHIR profiles and how to profile those to SNOMED profiles. We are going to create SNOMED profiles on the specific FHIR Vital Signs profile (e.g. Heart rate) and declare conformance with a generic SNOMED Vital Signs profile.

13

v3.0.1

ProcedureRequest

ReferralRequest


v3.4.0 (publication Aug 19?)

ServiceRequest

X

These two separate resources existed in the FHIR 3.0.1 Spec. Rob Hausambut have been removed in 4.0 and replaced with ServiceRequest

http://build.fhir.org/servicerequest.htmlServiceRequest

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?

Need to revisit the original questions raised in this group wrt the two separate resources of yore, and consider whether the same issues persists wrt the new single ServiceRequest resource.

14Next meeting5


1 October (Note Peter and Jeremy will be in Cardiff for NHS Event)

Next Resource for discussion: JR suggested focus on progressing the profile to a point where it can be shared with the wider world, which could then be build on with other resources.

Share progress with IG!

Further discussion on Terminology Binding Overlap (particularly of interest to Kirstine Rosenbeck Gøeg who may be able to share something at some point).

Meeting Files

  File Modified
PNG File image2019-6-26_10-43-2.png 2019-Sep-18 by Peter G. Williams
Microsoft Powerpoint Presentation Terminology binding.pptx 2019-Sep-18 by Peter G. Williams