SNOMED on FHIR

Space shortcuts

Page tree

Versions Compared

Old Version 26

changes.mady.by.user Peter G. Williams

Saved on

compared with

New Version 27

changes.mady.by.user Peter G. Williams

Saved on

Key

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

Assumptions and Audience

Introducing SNOMED to a FHIR audience and FHIR to a SNOMED Audience!Explanation of 4 levels of binding.

Code, Coding, Codeable Concept as specific to SNOMED CT (include link to introduction and points about display terms & multiple languages).

Introduction to using SNOMED with FHIR

  • Link to benefits of using SNOMED CT
  • Interoperability (synergy in using two world leading standards).
    • Distinction between Terminology Services and Binding 

  • A summary of using SNOMED CT with FHIR can be found here:  https://hl7.org/implement/standards/fhir/snomedct.html
  • Introduction for specific stakeholders

    • General Implementation Considerations

  • Is the goal (a) homogenous population of resources or (b) permissive guidance to cater for greater flexibility?
  • Do we restrict value sets to ensure that the same information cannot be represented in 2 different ways
  • The same semantics can’t be included in 2 data elements
    • The same semantics can’t be included in 2 resources

    How widely do we require/recommend

    SNOMED

    CT is used across each resource (e.g. vital signs, statuses)
  • Which of these are potentially in scope?
    • Restricting value sets to

    specific

    sub-hierarchies
  • New value sets for elements not using SNOMED CT
  • Restricting cardinalities to reduce ambiguity
  • Splicing to align with SNOMED CT concept model
  • Mapping FHIR value sets to SNOMED CT (e.g. status)
  • Defining SNOMED CT templates to support transformations

    • SNOMED specific behaviours

    • Emphasise use of Code field.
    • Links to other SNOMED using profiles (held elsewhere)
    • Considerations that were made as part of these profiles
    • Pull summary from Dion's validate code page
    • Validate code (Valuset and CodeSystem)
    • Expand (Valueset)
    • Lookup (CodeSystem)
    • Search
    • Terminology Capabilities Resource (check latest release of HAPI for support?).

    Implementing Terminology Services with SNOMED CT

    Implementing a Terminology Services Server with SNOMED CT - Frequently Asked Questions

    Design Notes specific to Client Applications

    Option for "pass-through" terminology requests so that FHIR server acts as proxy for Terminology Server.   Operations such as Expand may need to make calls on to Terminology before collating results.

    SNOMED Specific profiles (clinical resources)

    http://build.fhir.org/profiling.html

    Conflicts & Specialisation within a Resource

    Many resources specify a "code" element which is the obvious location for a SNOMED CT code and this should be used where feasible.  However, other fields may exist (often with multiple cardinality) that could potentially conflict or extend the meaning given by the code field.   For example, in the Procedure Resource as well as the code, a message can supply (potentially multiple) bodysite codeable concepts.

    So where a body site is NOT a child of the body site specified in code, what behaviour is expected?

    Comment - issues with lack of relationship grouping (eg device with bodysite where multiple exist) and inability to specify whether the site is being accessed in a direct or indirect manner.    We could, potentially, suggest enhancements to FHIR to bring its model into line with that of SNOMED to allow it to accurately state meaning using SNOMED CT concepts in an atomic manner, but what benefit would this give (plus ongoing maintenance overhead) when compared to using SNOMED CT in the first place?

    Options for Handling Semantic Overlap

    The following options could be considered to handle the semantic overlap between, say, Condition code and bodySite:

  • Restrict bodySite to [0..0] and require finding site in code
  • BodySite can only be populated if code has no finding site
  • BodySite (if exists) must be a specialization of finding site
  • BodySite must always be a specialization or self of finding site
  • Only allow conditions with no finding sites and include bodySite
    • Any condition and any bodySite


    Terminology Binding



    Assumptions and Audience

    Introducing SNOMED to a FHIR audience and FHIR to a SNOMED Audience!Explanation of 4 levels of binding.

    Code, Coding, Codeable Concept as specific to SNOMED CT (include link to introduction and points about display terms & multiple languages).

    Existing Documentation to Pull In

    4.2.1.0 Using SNOMED CT with FHIR

    SNOMED CT canonical CodeSystem resource

    https://hl7.org/implement/standards/fhir/snomedct.html

    Comparable Implementation Guides

    See also https://simplifier.net/guides

    Child Documents

    Children Display
    alltrue

    Feedback for HL7

    19 March 2019

    These two pages seem to be very similar?

    http://hl7.org/fhir/2018Sep/codesystem-operation-find-matches.html
    http://hl7.org/fhir/2018Sep/operation-codesystem-find-matches.html

    Publishing Notes

    4 June - group agreed to target R4 in the first instance but to indicate any future changes inline.   Also (PJ) suggested section on major changes from STU3 to R4 where relevant to SNOMED eg $compose is now $find-matches

    2 July - PJ: question over specific content for different stakeholders (FHIR spec does this) and how we present that - separate pages for developers (details) vs architect (integration, general 'use' of terminology services eg off the shelf solution.  Why use the FHIR API at all?) vs business level?

    16 July - PJ suggested initial page to target specific stakeholders (jumping off pages).  Compare with FHIR "Getting Started" Page - "see the Overviews: General, Developers, Clinical, and Architects"

    ML suggestion that we introduce SNOMED "through the lens of FHIR", so stay away from language reference sets and stick with what can be seen directly from FHIR resources.  (But we can have links to the detail & implementation course - PJ)

    Test Suites for using SNOMED with FHIR Servers

    • Examples of REST calls and their expected results (using SNOMED where possible), with narrative including any associated business logic.   
    • Be sure to make FHIR version and SNOMED CT Edition for each test clear
    • Pick SNOMED concepts that aren't likely to be retired any time soon.   Some tests will be more vulnerable than others eg checking the number of concepts subsumed.
    • Suggested to use and extend the test scripts used in previous Connectathons.
    • Potential to save resources from "Postman" as an aide.
    • Would be beneficial if SNOMED International server could use test script resources in a generic way as part of unit / integration testing.
    •  Dion McMurtrie Is any test related tooling that you've created re-usable?
    •  Peter Jordan  & Michael Lawley update on in-week discussion.  Update:  IG command line tooling having issues building SNOMED IG.   RobH says he's got a fix for that - will commit.
    •  Rob Hausam commit fix for SNOMED Implementation Guide (issue with NPM name)

    Attachments