Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »


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 
  • Linda Bird 's material on choices to be made in selecting elements eg conflict resolution due to overlapping semantics.

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?).

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?

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.





Existing Documentation to Pull In

4.2.1.0 Using SNOMED CT with FHIR

SNOMED CT canonical CodeSystem resource


Comparable Implementation Guides

See also https://simplifier.net/guides

Child Documents

  • No labels