UPDATE
These pages are currently transitioning into the SNOMED GitHub pages. See https://github.com/IHTSDO/snomed-ig
HL7 currently provide a daily build view of that which can be seen here: http://build.fhir.org/ig/IHTSDO/snomed-ig/
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).
- Link to benefits of using SNOMED CT
- Interoperability (synergy in using two world leading standards).
- Distinction between Terminology Services and Binding
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 waysThe same semantics can’t be included in 2 data elementsThe same semantics can’t be included in 2 resourcesHow widely do we require/recommend CT is used across each resource (e.g. vital signs, statuses)Which of these are potentially in scope?Restricting value sets to specific subhierarchiesNew value sets for elements not using SNOMED CTRestricting cardinalities to reduce ambiguitySplicing to align with SNOMED CT concept modelMapping FHIR value sets to SNOMED CT (e.g. status)Defining SNOMED CT templates to support transformationsDesign 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 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)SearchTerminology 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?
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 codeBodySite can only be populated if code has no finding siteBodySite (if exists) must be a specialization of finding siteBodySite must always be a specialization or self of finding siteOnly allow conditions with no finding sites and include bodySiteAny condition and any bodySite