SNOMED on FHIR

Space shortcuts

Page tree

The FHIR specification has an incomplete canonical CodeSystem resource at http://build.fhir.org/codesystem-snomedct.html(or the earlier / published version: https://www.hl7.org/fhir/codesystem-snomedct.html  )

This is something SNOMED International should really take ownership of, complete it, host it and keep it up to date...but obviously this group can help with all of that (except the hosting!).

I've included a table below which indicates the elements and their values in the current resource. The other thing to consider is the HTML rendering and what it should say, the current one you can see at https://www.hl7.org/fhir/codesystem-snomedct.html is in the current resource as generated text from the resource.

Ideally this should be hosted at http://snomed.info/sct and behave as a proper FHIR endpoint (e.g. respond appropriately to JSON and XML accept headers).

Please comment on the appropriateness of the current values and suggested changes.

ElementValueDiscussion
idsnomedct

Specified by individual server, so we could leave blank here.

urlhttp://snomed.info/sctWe'd expect this to redirect to the most recent international release.
version

This probably should be a specific URI to the particular edition/version but not defined in the Canonical form.

Suggest we mandate this field if this document is specifying a template. RH had concerns about this since concepts couldn't then be referred between different versions. Note that the context here is an instance of a Code System resource from at Term Server perspective, not individual concepts as used a medical record where the SCTID plus description provides meaning.

identifier
systemurn:ietf:rfc:3986
valueurn:oid:2.16.840.1.113883.6.96
This is the SNOMED OID used in other specifications eg CDA.
nameSNOMED CTWhile this is the canonical value, each server would specify the particular edition they're making available.
titleSNOMED CT (all versions)Not required?
statusactive
experimentalfalse
publisherIHTSDOChange to SNOMED International
contact
telecom
systemurl
valuehttp://ihtsdo.org
Changes to snomed.org
descriptionSNOMED CT is the most comprehensive and precise clinical health terminology product in the world, owned and distributed around the world by The International Health Terminology Standards Development Organisation (IHTSDO).
copyright© 2002-2018 International Health Terminology Standards Development Organisation (IHTSDO). All rights reserved. SNOMED CT®, was originally created by The College of American Pathologists. "SNOMED" and "SNOMED CT" are registered trademarks of the IHTSDO http://www.ihtsdo.org/snomed-ct/get-snomed-ct
caseSensitivefalseDefinition of element here is "If code comparison is case sensitive" which because SCTIDs are numeric, it's not.
hierarchyMeaningis-aSuggest improving the documentation for this element, is somewhat ambiguous. "Properties of parent apply to child" is certainly true.
compositionaltrue"True If code system defines a post-composition grammar."
versionNeededfalse

"This flag is used to signify that the code system has not (or does not) maintain the definitions, and a version must be specified when referencing this code system."

contentnot-presentWe're not expecting to include all of SNOMED-CT in this resource.
filter
codedescriptionoperatorvalue
conceptFilter that includes concepts based on their logical definition. e.g. [concept] [is-a] [x] - include all concepts with an is-a relationship to concept x, or [concept] [in] [x]- include all concepts in the reference set identified by concept x

is-a

in

A SNOMED CT code
expressionThe result of the filter is the result of executing the given SNOMED CT Expression Constraint=A SNOMED CT ECL expression (see ecl)
expressionsWhether post-coordinated expressions are included in the value set=true or false

RH notes that the distinction between plural and not is subtle in text and substantial in effect.

Could use "constraint" for the first instance. However, is likely already in use. ML confirms and in fact this field was previously called "constraint".

"PostCoordination" a suggested alternative for 2nd which is the more problematic of the two.

ML: Is "expressions" more relevant to an expansion profile? PW: Changing "are" to "should be" would make intention clearer.

property
codeuridescriptiontype
inactivehttp://snomed.info/field/Concept.activeWhether the code is active or not (defaults to false). Not the same as deprecatedboolean
definitionStatusIdhttp://snomed.info/field/Concept.definitionStatusIdEither of the codes that are descendants of 900000000000444006code
parenthttp://hl7.org/fhir/concept-properties#parent
A SNOMED CT concept id that has the target of a direct is-a relationship from the conceptcode
childhttp://hl7.org/fhir/concept-properties#childA SNOMED CT concept id that has a direct is-a relationship to the conceptcode
moduleIdhttp://snomed.info/field/Concept.moduleIdThe SNOMED CT concept id of the module that the concept belongs to.code
normalFormhttp://snomed.org/longnormalformGenerated Normal form expression for the provided code or expression, with termsstring
normalFormTersehttp://snomed.org/canonicalnormalformGenerated Normal form expression for the provided code or expression, conceptIds onlystring

We need URI values for parent / child and Normal Form here.

If / when the URI standard is extended to include ECL then parent / child would arrive that.

ML: parent and child are general properties that are not SNOMED specific, these are FHIR specified properties. Have inserted FHIR URIs here.

Suggestion that normalFormTerse is changed to Canonical Normal Form, and normalForm changed to Necessary Long Normal Form (and use these terms in the description column also, with sufficient text to explain the difference between the two).

URI is, also, optional.

Noted the impact on implementers in changes here, so name changes noted above will not be recommended at this time.

  • Michael Lawley to take up the URIs for Normal Forms with the SNOMED Languages Group.

However in any event, the description should be updated here.


property (cont)

There is also listed the attributes used in SNOMED CT, a couple of examples to express the pattern are

codeuritype
Due tohttp://snomed.info/id/42752001code
Associated withhttp://snomed.info/id/47429007code

Code should be the SCTID rather than term.

  • Rob Hausam How is this list defined? Descendants of "Attribute" ?

Perhaps more relevant to use attributes currently in use in the International Edition.

FSN should be populated in the description column.


<additional>

Additional elements worth considering populating are

  • date - date of last change to the resource
  • purpose - why is this code system defined
  • valueSet - Canonical URL for the value set with the entire code system

DM suggested date was worth populating to show when the resource last changed.

Boiler plate text for purpose?

"SNOMED CT (Systematized Nomenclature of Medicine -- Clinical Terms) is a standardized, multilingual vocabulary of clinical terminology that is used by physicians and other health care providers for the electronic exchange of clinical health information."

https://searchhealthit.techtarget.com/definition/SNOMED-CT

The URL for the entire code system is a notional valueset that contains all versions of all editions. It would not change from instance to instance and is immutable.

<additional>Another thing to consider is whether the valueSet, if it can exist, if theoretically expanded would return all of SNOMED CT International Edition or the SNOMED CT "Universal" Edition - i.e. which does this CodeSystem resource represent?To be defined for the individual code systems. Could state the implicit value set endpoint for the server.




  • No labels

6 Comments

  1. Michael Lawley

    We should be careful with the values here.  For example, the Resource should not be mandating the value of the id field since this is "owned" by the terminology service.


    1. Dion McMurtrie

      I agree Michael Lawley, I've just copied here what was in the existing resource because I thought it may be more approachable for most for review as a table

  2. Dion McMurtrie

    There's an issue here to consider with extensions. Does this CodeSystem resource represent

    1. The universe of SNOMED CT (including all extensions)
    2. The SNOMED CT International release
    3. SNOMED CT Core

    It is maybe worth considering whether there should be CodeSystem resources for each of the extension editions, for example one at http://snomed.info/sct/32506021000036107 for SNOMED CT-AU, perhaps just proxying or redirecting to a CodeSystem hosted by the Australian Digital Health Agency. This difference may just be in the properties (additional attributes) and perhaps copyright statements, so perhaps that isn't worthwhile?

    1. Peter G. Williams

      Do you think this behaviour would be different if the concept had been promoted to the core?   

  3. Dion McMurtrie

    As mentioned by Reuben Daniels in our London meeting, it would be great if SI could redirect requests to extensions.

    For example HTTP requests for http://snomed.info/sct/32506021000036107 or any version specific URI like http://snomed.info/sct/32506021000036107/20180131 could redirect to somewhere like https://www.healthterminologies.gov.au/access?content=snomed

    1. Peter G. Williams

      I'll try to progress this.   Please confirm desired endpoint for us to use.

      Note to self: watch headers should be maintained.