Page tree

The FHIR specification has an incomplete canonical CodeSystem resource at the earlier / published version:  )

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 is in the current resource as generated text from the resource.

Ideally this should be hosted at 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.


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

url'd expect this to redirect to the most recent international release.

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.

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?
publisherIHTSDOChange to SNOMED International
Changes to
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
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."

"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.
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



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.

inactive the code is active or not (defaults to false). Not the same as deprecatedboolean
definitionStatusId of the codes that are descendants of 900000000000444006code
A SNOMED CT concept id that has the target of a direct is-a relationship from the conceptcode
child SNOMED CT concept id that has a direct is-a relationship to the conceptcode
moduleId SNOMED CT concept id of the module that the concept belongs to.code
normalForm Normal form expression for the provided code or expression, with termsstring
normalFormTerse 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

Due to
Associated with

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 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."

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


  1. 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. 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. 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 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. Do you think this behaviour would be different if the concept had been promoted to the core?   

  3. 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 or any version specific URI like could redirect to somewhere like

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

      Note to self: watch headers should be maintained.