SNOMED on FHIR

Space shortcuts

Page tree

Versions Compared

Old Version 7

changes.mady.by.user Peter G. Williams

Saved on

compared with

New Version 8

changes.mady.by.user Peter G. Williams

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

20:00 UTC on Tuesday 14 August 2018 - 90 minutes.

Objectives

  • FHIR Terminology Services and Resources

Meeting Details

Online: https://snomed.zoom.us/my/snomedhl7

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

Chat: https://chat.snomedtools.org/channel/snomed-fhir
          (instructions and guide here - Getting Started with Rocket Chat)


Attendees

Peter G. Williams, Dion McMurtrie, Rob Hausam

Apologies

Meeting Recording

https://snomed.zoom.us/recording/share/jPRalPbWvZP5-CFFutQnokn7yVJ3D1vQYKSophWkqvawIumekTziMw?startTime=1534276899000

Discussion items

ItemDescription

Mins

OwnerNotes & Actions
1Welcome and introductions5

Peter G. Williams

Rob Hausam

Recording, notes & attendance.

SNOMED on FHIR meeting planned during the business meeting - closed session (observers space dependent).

2October Expo - Vancouver5

Jane Millar

Call for abstract - presentation on the work of this group (2 presenters max).

3Summary of previous week5

Rob Hausam

4Work suggestions from last meeting

Dion McMurtrie

Proposals for expand

Options for validate code - mapping between various data issue scenarios and true/false result flag.

5Zulip discussion on Post Coordinated expressions50

Dion McMurtrie

Summary: Expressions filter on CodeSystem Resource - Dion asked Graham about origin of these two items. GG clarified true = permit PCE eg for use in validate-code and similarly for expand. Default = true also. Suggested that expand call should then return every possible post coordinated expression (!!) which is a) hard and b) probably not useful. Such expressions could be available if an expression library had been implemented. However, validate code should handle arbitrary PCEs since this will be a finite set. Note that people do post coordination for other code systems eg UCUM and MIME.

Update: Difference between two positions - when expanding value sets defined intensionally, expectation that any existing pre-coordinated concept or PCE would be included. Graham expects server to return "Too Costly" as logical behaviour would be to return every possible PCE.

Suggestions:

  • Possible valid use case in calculating lateralized expressions (even at runtime).
  • Principle could be applied that in general SNOMED Pre and Post coordinated expressions should be interchangeable.
  • Incomplete response should be labelled as such.
  • That we should return "published" content, which might include post coordinated content in some cases. ML suggested "at least" this content.
  • We could make a statement in the "Using SNOMED with FHIR" page. Clarify with the HL7 Vocabulary group.

Questions / Discussion

  • In the "membership" query, does a PCE that is equivalent to a pre-coordinated that is part of the value set match? RH: If the value set says that PCE is included, then yes it should handle that.

Update 26 June

  • PCE validation would be expected to take into account MRCM rules.
  • PCE would not necessarily have a term associated with it - arguably useless in an EHR.
  • No know use cases for expression libraries (JC)

PJ: Could change excludePostCoordinated to includePostCoordinated (and default to false) in operation-valueset-expand.html to better reflect the current capabilities of 99% of systems. Option for finer grained enumeration ("PostCoordination" / "Composition Behaviour"?)for varying efforts in PCE generation. RH: Remember these changes would apply to all code systems.

Suggested Enumeration:

  • None (returning a valuset in this case would indicate that it's a subset)
  • Pre-defined (eg library) PCEs - this would be the default setting.
  • Generated PCEs eg Laterality
6SNOMED with FHIR30Rob Hausam

Revisit 4.2.1.0 Using SNOMED CT with FHIR

All participants are invited to review this local copy of that page.

  •  Section 4.2.1.0.5 Clarity needed on which Normal Form is being represented (eg breaking sufficiently defined concepts down to their primitive components, unlike what is supplied in the browser). Further discussion needed on what these properties are being used for. Perhaps only 1 is necessary since terms can be added/removed as required
  •  Supplements are a possible way to allow language reference set type functionality.
7

$validate-code behaviour

Note this discussion is specific to the response to Term during validation.

20

Dion McMurtrie

Current behaviour doesn't allow for distinction to be made in responding to quality of term queried.

Note: Since server returns display term, if the query just checks for membership then the client could check its term against that returned. This waters down the usefulness of the server but would simplify if functionality is not in the 80% of features required.

See GForge issue #17218 (ML's). Also #16586.

See also https://chat.fhir.org/#narrow/stream/48-terminology/subject/Validation.20for.20foreign.20language.20resources

Discussion

14 Aug Update - Discussion planned for Vancouver Meeting Agenda. Note that Grahame Grieve stated "already done" on tracker item 11 Aug.

8Main item for discussion30

Dion McMurtrie

SNOMED CT Canonical CodeSystem resource
  • Review and attempt to resolve detail questions
  • Issue around extensions and what this CodeSystem resource actually represents

Update: URIs populated. Intention to provide short URLs for normalForm and normalFormTerse to point to appropriate definition of terms.

9Current items10

Dion McMurtrie

  • SNOMED CT "Universal" Edition
    • Definitely useful to have a catalogue of all concepts ever issued if not a proper edition which may be much harder?
    • Is this work for this group, or should this be handed on to a more appropriate SI group?
    • Update 14 Aug - Are we going to shelve this item as not currently practical? Hand to MAG/TRAG?
  • Check and fix ECL in the FHIR spec
    • Is there a way to systematically identify all ECL expressions in the FHIR spec?
    • If we run these through validation is there appetite/volunteers to review and fix them as feedback to the spec?
    • Is there a way to integrate ECL validation into the FHIR spec tooling to prevent recurrence?
  • Linda Bird to progress defining Terse Normal Form with the Family of Languages group (Rob Hausam confirms needed for July)
    • SLPG agreed that the Languages group is not the appropriate forum for this definition. Instead, we believe this should be defined in the DL subgroup of the Modelling Advisory Group.
    • Also agreed that the terms that need defining are "Canonical Normal Form" (which is terse by definition) and "Necessary Long Normal Form"

Update 14 August See draft (doesn't specify particular normal forms) :

10Mechanism for working with Languages.15Reuben Daniels

HL7 Vocab Item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=15806

ML: Supplement would hopefully only add additional descriptions that are not described in the base content.

Precedence (fallback) for multiple language reference sets only really discussed in Languages Group for ECL - other use cases not yet brought to light.

11Review of TS Collaborative Work5

Dion McMurtrie

Collaborative Work
12

Any other business




Next Meeting: Tuesday 28 August

Actions for next week:



Meeting Files

Attachments