Page tree

Note that this page has been copied from http://build.fhir.org/snomedct.html purely for the purpose of review and consolidating feedback. It would be acceptable to modify this document however, so we have a 'complete' draft to return to HL7.   We'll be able to track the changes through Confluence document history.

Source

SNOMED CT is used in FHIR international standards and resources. SNOMED CT is owned, maintained and distributed by SNOMED International . SNOMED International is the organization which publishes the International Edition of SNOMED CT. SNOMED International Members may also distribute their own SNOMED CT National Edition, which contains the international release plus local extension content and derivatives.

System
The URI http://snomed.info/sct  identifies the SNOMED CT code system.
Version

Where a code system version is used, it should be specified as a URI that represents a specific SNOMED CT Edition published on a particular date (e.g. the International Edition or a National Edition, with a version date), following the SNOMED CT URI Specification  (see note below)

Code

The following SNOMED CT artifacts are valid in the code element for the http://snomed.info/sct namespace: Concept IDs and SNOMED CT Expressions (using SNOMED CT Compositional Grammar).
SNOMED CT Terms and Description Identifiers are not valid as codes in FHIR, nor are other alternative identifiers associated with SNOMED CT Concepts.

Note: when SNOMED CT terms must be exchanged, use the Description Id Extension.

Display

The correct display for a SNOMED CT concept is one of the terms associated with that concept. The best display is the preferred term in the relevant language or dialect, as specified in the associated language reference set. SNOMED CT synonyms may be case sensitive.

SNOMED International does not define terms for expressions. If a SNOMED terminology producer publishes human-readable terms for expressions in an expression repository, this term may be used as the display. Similarly, if a SNOMED terminology producer publishes an official template for generating terms from an expression, a term generated using the template may be used as the display. If no term or description template has been published, the full expression with terms embedded may be used.

Note that Display is not intended to contain terms entered by the user that have not been officially published by a SNOMED CT Terminology Producer.

InactiveInactive codes are identified using the 'inactive' property (see below).
SubsumptionSNOMED CT Subsumption testing for concepts is based on the |is a| relationship defined by SNOMED CT.
Filter PropertiesSeveral filter properties are defined, as described below.

This specification publishes a canonical SNOMED CT code system resource. See also the SNOMED CT Usage Summary.

Note: The SNOMED International glossary  explains some of these SNOMED CT specific terms.

There is no single distribution that contains all defined SNOMED CT codes in all contexts of use. Instead the International Edition contains all concepts shared and agreed to be internationally relevant and each National Release Centre distributes this International Edition plus additional national content (to extend the international set). Other release authorities may also be designated. The SNOMED CT URI Specification  describes how to unambiguously reference a particular version of a SNOMED CT edition:

  http://snomed.info/sct/[sctid]/version/[YYYYMMDD]

where [sctid] is the concept id that identifies the given SNOMED CT edition (based on the identifier of the most dependent module), and "YYYYMMDD" is the date of release. Examples of sctids that identify a specific edition are listed here.


4.2.1.0.3 SNOMED CT Expressions

SNOMED CT Expression is a structured combination of one or more clinical concepts, stated using Compositional Grammar Syntax.

Expressions may optionally contain display terms.


4.2.1.0.4 Copyright and Licenses Note that many implementations are in the habit of simply using the date of release in the form YYYYMMDD (e.g. "20140531"), and assuming that the edition is known. However this is not always safe, so implementations that populate the version element must use the URI form.

This specification includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/get-snomed-ct  or info@snomed.org.

The SNOMED International URI specifications use the namespace http://snomed.info/sct for the code system, and the URI http://snomed.info/id for the individual concepts in the code system. This means that when a SNOMED CT concept is converted from the system::code pair, where the system is http://snomed.info/sct, to the RDF ontological form, the representation is http://snomed.info/id/[concept-id]. Expressions are represented using the URI pattern http://snomed.info/scg/[expression]. Expressions represented in this way SHALL not contain whitespace, terms, or comments.

In addition to the standard properties, the following properties are defined for SNOMED CT:

Property NameData TypeComments
inactivebooleanWhether the code is active or not (defaults to false). This is derived from the active column in the Concept file of the RF2 Distribution (by inverting the value)
sufficientlyDefinedboolean

True if the description logic definition of the concept includes sufficient conditions. This is derived from the definitionStatusId value in the Concept file of the RF2 distribution (i.e. If 900000000000073002 |Sufficiently defined concept definition status| then true).

moduleIdcodeThe SNOMED CT concept id of the module that the concept belongs to.
normalFormstringGenerated Necessary Normal form expression for the provided code or expression, with terms. See http://snomed.org/nnf
normalFormTersestringGenerated Necessary Normal form expression for the provided code or expression, conceptIds only.

SNOMED CT relationships, where the relationship type is subsumed by 410662002 |Concept model attribute|, also automatically become properties. Properties that represent SNOMED CT concept model attributes are referred to using their concept id, rather than their human readable term.

For example, the laterality property is represented using the concept id '272741003', rather than the term 'laterality':

Property NameData TypeComments
272741003
code

The value of the laterality attribute in the definition of the given code or expression.

The equivalent URI for the Laterality property is http://snomed.info/id/272741003 (see the code system definition).

Note that when a $lookup operation is performed on a SNOMED CT concept, servers SHALL return the full URI for the edition and version being used (see above) in the version property. Other properties are at the discretion of the server and the client.

This section documents the property filters that can be used with the SNOMED CT code system in value set composition statements.

For implementer convenience, some of the property filters are documented in terms of the SNOMED CT Expression Constraint Language, but this does not imply that its use is required.

DescriptionSelect a set of concepts based on subsumption testing
Property Nameconcept
Operations Allowedis-a
Values Allowed[concept id]
CommentsIncludes all concept ids that have a transitive is-a relationship with the concept Id provided as the value (including the concept itself)
ExampleAdministration Methods
<< [concept]  (Long syntax: descendantOrSelfOf [concept])
DescriptionSelect a set of concepts based on their membership of a SNOMED CT reference set
Property Nameconcept
Operations Allowedin
Values Allowed[concept id]
CommentsIncludes all concept ids that are active members of the reference set identified by the concept Id provided as the value
^ [concept]   (Long syntax: memberOf [concept])
DescriptionSelect a set of concepts based on a formal expression constraint
Property Nameconstraint
Operations Allowed=
Values Allowed[expression constraint]
Comments

The result of the filter is the result of executing the given SNOMED CT Expression Constraint 
Example:

 "compose": {
  "include": [
    {
      "system": "http://snomed.info/sct",
      "filter": [
        {
          "property": "constraint",
          "op": "=",
          "value": "<< 30506011000036107 |Australian product|: 700000101000036108 |hasTP| = 17311000168105 |Panadol|"
        }
      ]
    }
  ]
}

   
DescriptionSpecify whether postcoordination is allowed or not
Property Nameexpressions
Operations Allowed=
Values Allowedtrue or false
CommentsExpressions, if allowed, are subject to the same rules as precoordinated concepts. (Note: simple reference sets do not include expressions).
ExampleAdministration Methods
n/a

Implicit value sets are those whose specification can be predicted based on the grammar of the underlying code system, and the known structure of the URL that identifies them. SNOMED CT has two common sets of implicit value sets defined: By Subsumption, and By Reference Set. These implicit value sets do not use complex queries. This allows a single URL to serve as a value set definition that defines a value set, and can serve as the basis for the $expansion operation.

If any value set resources exist with an identifier that conforms to the URL patterns specified below, the content of the resource must conform to the template provided. Profiles and other value set references are allowed to reference these value sets directly (by reference as a URI, rather than by a value set reference, which is a literal reference).

A SNOMED CT implicit value set URL has two parts:

"http://snomed.info/sct" should be understood to mean an unspecified edition/version. This defines an incomplete value set whose actual membership will depend on the particular edition used when it is expanded. If no version or edition is specified, the terminology service SHALL use the latest version available for its default edition (or the international edition, if no other edition is the default).

For the second part of the URL (the query part), the 4 possible values are:

  • ?fhir_vs - all Concept IDs in the edition/version. If the base URI is http://snomed.info/sct, this means all possible SNOMED CT concepts
  • ?fhir_vs=isa/[sctid] - all concept IDs that are subsumed by the specified Concept.
  • ?fhir_vs=refset - all concept ids that correspond to real references sets defined in the specified SNOMED CT edition
  • ?fhir_vs=refset/[sctid] - all concept IDs in the specified reference set

A value set with a URL that follows the pattern "[edition/version]?fhir_vs=isa/[sctid]" follows this template:

<ValueSet xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
     [Some HTML that describes this value set as all concepts subsumed by conceptid]
    </div>
  </text>
  <url value="[edition/version]?fhir_vs=isa/[sctid]"/>
  <version value="[edition/version]"/>
  <name value="SNOMED CT Concept [conceptid] and descendants"/>
  <description value="All SNOMED CT concepts for [concept id or preferred description]"/>
  <copyright value="This value set includes content from SNOMED CT, which is copyright © 2002+ International Health Terminology Standards Development Organisation (IHTSDO), and distributed by agreement between IHTSDO and HL7. Implementer use of SNOMED CT is not covered by this agreement"/>
  <status value="active"/>
  <compose>
    <include>
      <system value="http://snomed.info/sct"/>
      <filter>
        <property value="concept"/>
        <op value="is-a"/>
        <value value="[sctid]"/>
      </filter>
    </include>
  </compose>
</ValueSet>

The value set with a url that follows the pattern "[edition/version]?fhir_vs=refset" follows this template:

<ValueSet xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
     [Some HTML that describes this value set as all concepts with associated reference sets]
    </div>
  </text>
  <url value="[edition/version]?fhir_vs=refset"/>
  <version value="[edition/version]"/>
  <name value="SNOMED CT Reference Sets"/>
  <description value="All SNOMED CT concepts associated with a reference set"/>
  <copyright value="This value set includes content from SNOMED CT, which is copyright © 2002+ International Health Terminology Standards Development Organisation (IHTSDO), and distributed by agreement between IHTSDO and HL7. Implementer use of SNOMED CT is not covered by this agreement"/>
  <status value="active"/>
  <compose>
    <include>
      <system value="http://snomed.info/sct"/>
      <!-- repeat: one concept element with a code for each concept that has an associated reference set -->
      <concept>
        <code value="[sctid]"/>
      </concept>
      <!-- end repeat -->
    </include>
  </compose>
</ValueSet>

For each concept that is associated with a reference set, there will be one concept element with a contained code that contains the concept id.

A value set with a url that follows the pattern "[edition/version]?fhir_vs=refset/[conceptid]" follows this template:

<ValueSet xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
     [Some HTML that describes this value set as all concepts in the reference set identified by conceptid]
    </div>
  </text>
  <url value="[edition/version]?fhir_vs=refset/[sctid]"/>
  <version value="[edition/version]"/>
  <name value="SNOMED CT Reference Set [conceptid]"/>
  <description value="All SNOMED CT concepts in the reference set [concept id or preferred description]"/>
  <copyright value="This value set includes content from SNOMED CT, which is copyright © 2002+ International Health Terminology Standards Development Organisation (IHTSDO), and distributed by agreement between IHTSDO and HL7. Implementer use of SNOMED CT is not covered by this agreement"/>
  <status value="active"/>
  <compose>
    <include>
      <system value="http://snomed.info/sct"/>
      <filter>
        <property value="concept"/>
        <op value="in"/>
        <value value="[conceptid]"/>
      </filter>
    </include>
  </compose>
</ValueSet>

Implicit concept maps are those whose specification can be predicted based on the grammar and/or content of the underlying code system, and the known structure of the URL that identifies them. This allows a single URL to serve as a concept map definition that defines a mapping between two sets of concepts, and which can serve as the basis for the $translate operation. SNOMED CT has two common sets of implicit concept maps defined:

  • Association Reference Sets
  • Simple Map Reference Sets

Association Reference Sets  are part of the core SNOMED CT distribution. The following standard Association Reference sets are mapped to implicit Concept Maps:

NameConcept IdRelationship
POSSIBLY EQUIVALENT TO900000000000523009inexact
REPLACED BY900000000000526001equivalent
SAME AS900000000000527005equal
ALTERNATIVE900000000000530003inexact

If any concept map resources exist with an identifier that conforms to the URL pattern specified below, the content of the resource must conform to the template provided. Canonical references to concept maps are allowed to reference these concept maps directly by referring to their URI.

A SNOMED CT implicit concept map URL has two parts:

"http://snomed.info/sct" should be understood to mean an unspecified edition/version. This defines an incomplete concept map whose actual membership will depend on the particular edition used when it is expanded. If no version or edition is specified, the terminology service SHALL use the latest version available for its default edition (or the international edition, if no other edition is the default).

For the second part of the URL (the query part), there is only one possible value:

  • ?fhir_cm=[sctid] - where [sctid] is a value from the table above

A concept map with a URL that follows the pattern "[edition/version]?fhir_cm=[sctid]" follows this template, where [name], [sctid] and [relationship] are taken from the table above:

<ConceptMap xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
     [Some HTML that describes this concept map]
    </div>
  </text>
  <url value="[edition/version]?fhir_cm=[sctid]"/>
  <version value="[edition/version]"/>
  <name value="SNOMED CT [name] Concept Map"/>
  <description value="The concept map implicitly defined by the [name] Association Reference Set"/>
  <copyright value="This value set includes content from SNOMED CT, which is copyright © 2002+ International Health Terminology Standards Development Organisation (IHTSDO), and distributed by agreement between IHTSDO and HL7. Implementer use of SNOMED CT is not covered by this agreement"/>
  <status value="active"/>
  <sourceUri value="[edition/version]?fhir_vs"/>
  <targetUri value="[edition/version]?fhir_vs"/>
  <group>  <!-- 0..* Same source and target systems -->
    <source value="http://snomed.info/sct"/>
    <sourceVersion value="[edition/version]"/>
    <target value="http://snomed.info/sct"/>
    <targetVersion value="[edition/version]"/>
    <!-- a mapping for each member of the reference set -->
    <element>
      <code value="[member]"/>
      <target>
        <code value="[reference set value]"/>
        <equivalence value="[relationship]"/>
      </target>
    </element>
  </group>
</ConceptMap>

Simple Map Reference Sets  (reference sets which are descendants of 900000000000496009 "Simple map") also define an implicit concept map. 




List of Substantive Changes to the above to discuss with HL7

Expressions

We've added a new section for Expressions.   Bringing other text on the page into line with SNOMED International's definition of what constitutes valid SNOMED CT compositional grammer, we've removed advice about including or not including text definitions - both are considered equally valid, although there may be an argument for including the orginal text selected by the end user.

New Sections - works in progress

These have been removed into their own pages while the text is agreed.   Since they are additional guidance, there is no reason to think that anything being added will 'break' the above.

4.2.1.0.3 Display


  • No labels

18 Comments

  1. Hi,

    The Canadian Edition of SNOMED CT includes 3 modules:

    • 20621000087109  Canada Health Infoway English module (core metadata concept)
    • 20611000087101  Canada Health Infoway French module (core metadata concept)
    • 22091000087100  Canada Health Infoway Reference Set Module (core metadata concept)

    If you could make the correction in the 4.2.1.0.2 Versions section, that would be appreciated!

    Thank you.

    1. Hi Linda,

      An Edition is identified by a single module Id.  The other modules are included by way of the Module Dependency Reference Set.

      Thus, there are either three editions here (one per module above), or the MDRS looks something like the following table and the question is what is X?

      moduleIdreferencedComponentIdsourceEffectiveTimetargetEffectiveTime
      X
      20621000087109
      T1T1
      X
      20611000087101
      T1T1
      X
      22091000087100
      T1T1
      X900000000000207008T120180131
      X900000000000012004T120180131
      1. I've now managed to download the latest Canadian release to look at the MDRS.

        The way it is structured we see that:

        20611000087101  Canada Health Infoway French module depends on 22091000087100  Canada Health Infoway Reference Set Module
        22091000087100  Canada Health Infoway Reference Set Module depends on  20621000087109  Canada Health Infoway English module
        20621000087109  Canada Health Infoway English module depends on  900000000000207008 SNOMED International Core

        Thus the module that is at the root of the dependency hierarchy is 20611000087101  Canada Health Infoway French module, so the entry in the table above is "correct", but it is also possible (from a technical perspective) to talk about a Canadian English only Edition and a Canadian English+Canadian Reference Sets Edition, which is probably not what is intended.

        Technically it is also an invalid (incomplete) MDRS because it does not follow the requirement that all transitive module dependency edges are listed.

        1. I was looking at that, too, and saw the same thing.  That wasn't what I expected the structure to be, but since that's the way that it is I think we'll need to stay with 20611000087101 for now on this SNOMED CT with FHIR page (which certainly can be updated in the future if changes are made).

        2. Yes there is a bit of confusion about the MDRS, and always has been. I'd suggest that this is a topic that the TRAG should address if you agree Andrew Atkinson?

          Matt Cordell and I have posted some information which is what prompted our recent discussions of this at Re: Purpose of MDRS (Module Dependencies).

          Long story short, there is a tension between the MDRS defining true content dependencies between modules (i.e. this module contains content that references content in that module), or defines edition composition (i.e. the edition identified by this module id is composed of the content on these modules). These two purposes can actually coexist without issue (they do in the SNOMED CT International release). But in Australia, and by the looks of things Canada, it isn't possible to represent both simultaneously with the single MDRS.

          Again long story short, I've got a few suggestions, we could

          • clarify that the MDRS means edition composition and have no mechanism for module content dependency. Extension releases can adjust their MDRS appropriately.
          • clarify that the MDRS means edition composition and add a mechanism to represent module content dependency. Extension releases can adjust their MDRS appropriately and add content to the new dependency mechanism.
          • define the set of rules that need to be followed to have the MDRS support both purposes at once. It is possible, and I won't go into the detail here for brevity, but requires a particular pattern of use of modules. Again Extension release can adjust their MDRS appropriately

          We probably need to try and understand who is using the MDRS for what purpose at the moment. I know Michael Lawley's tooling uses it extensively for edition composition calculation, ours uses it for module content dependency which right back at the start of RF2 was its purpose, before the URI spec was created and needed a mechanism to identify an edition which is where the very valid edition composition use case came from.

          I suggest we get this straightened out quickly, before the confusion spreads...

          Oh, and yes, the MDRS explicitly says it isn't transitive. I'm not sure why this is, because naturally it is, but that's what the spec says - maybe denormalised to make it easier for implementers to use? So the transitive dependencies all need to be explicitly stated.

  2. Thanks Dion McMurtrie, I've added this as a topic for our next TRAG meeting.

  3. Okay,

    This is a very interesting discussion, and by providing my detailed information, I was not expecting that I was opening a can of worms!!!

    I think that clarification would be a good thing as well.

    Linda

  4. Hi,

    in order to avoid ambiguity on our Canadian Edition, which I cannot provide you with a unique identifier for, and until this question is sorted out, I would still ask if you could make the correction in the Table above, as follows: 

    Canadian French extension: 20611000087101  

    Canadian English extension: 20621000087109  

    Canadian Refset extension: 22091000087100  


    This will also align with UK, US and AU Edition specification found in the same table.

    Thank you!

  5. Hi Linda (Parisien)!

    I have added the 3 Canadian module ids, as requested, but called them editions.

    Each edition includes the given module, plus any module on which the given module depends.

    So (based on your MDRS, with assumed transitive dependencies) the French 'edition' will include all 3 Canadian modules, plus the 2 International Edition modules, the Canadian Refset edition will include the Canadian Refset module, the Canadian English module and international modules, and the Canadian English edition will include the Canadian English module and the international modules.

    Because FHIR requires the version URI to refer to an 'edition', rather than a single extension module (or set of modules), I think this is the best solution for the moment. However, in future, you should consider adding a new 'Canadian edition' module that is dependent on the 3 Canadian modules and 2 international modules, which can be used as the single identifier for the entire Canadian edition. This would also require additions to your Module Dependency Reference Set. There is a discussion about modules, extensions and editions in the new 'Practical Guide to Extensions' which is due to be released for advisory group review in the next few weeks.

    I'd be happy to discuss further if that's helpful.

    Kind regards,
    Linda (Bird).

  6. Thank you Linda (Bird)!,

    Yes, I understand the clarification. Guillermo should provide more information on our current status. I'm looking forward to the new 'Practical Guide to Extensions' and will be happy to discuss further.

    Linda

  7. For Australia we only have one real edition and that is 32506021000036107, which now includes AMT.

    We historically had 900062011000036108 which identified just AMT by itself, and technically that is still a valid module to identify, but as it becomes integrated with SNOMED CT substances (hopefully shortly) it isn't really a separate edition to identify.

    1. Hi Dion,

      I've edited the table to reflect this. Thanks!

      Linda.

  8. The following discussion occurred in the text and has been marked a resolved since the relevant text was deleted, but we may wish to discuss further.   The text (at the bottom of the page) was: "Simple Map Reference Sets  (reference sets which are descendants of 900000000000496009 "Simple map") also define an implicit concept map. However, at this time, these cannot be converted to Concept Maps because the target code system used by the map is not yet defined in a computable way. "

    LB: We should consider deleting this sentence [ Ed: from "However" ] as well, and leaving this as a discussion topic.

    ML:  Do any SimpleMaps target more than one code system at the same time? If not, then this is easily solvable with an extra (small) reference set. If so, then things will be more complex

    LB: I am not aware of any simple maps that target more than one code system, and don't think that they should. I agree that a small reference set containing this information would be sufficient for this particular use case.

    ML: Here are the Simple map refsets available in SNOMED CT-AU.   Obviously ARTGID is AU-specific, so there's only 7 entries required for 6 target code systems

    DM: Yes I think the only thing missing here is a way to define the target code system. The information is well known but there is no agreed way to represent it.

    DM: As Michael points out a fairly simple reference set would solve the problem. Or possibly a relationship from the simple map reference set's concept to a concept identifying the target code system.  Definitely fixable and not much work.

  9. Regarding Code System supplements, I suggest reviewing the section that Grahame Grieve has recently added to the specification at http://build.fhir.org/codesystem.html#supplements and, perhaps, gaining consensus that this type of CodeSystem content is not applicable to SNOMED CT.  Similarly, there needs to be an agreement on Code System fragments as described in the preceding sections of the specification. The later 'can only be published by the code system authority, or according to a process defined by the authority, if they have defined one'.

    1. Peter, could you elaborate some on your thoughts about why this type of CodeSystem content is not applicable to SNOMED CT?  Personally, I believe I can see some potential legitimate uses for it - some of which I was trying to describe on the call today.

      1. Apologies if I missed something there, but the two main use cases I've heard for using supplements are for language translations and defining additional code system properties and I don't see either of those being applicable to SNOMED CT.  I also recall others commenting that supplements were unlikely to be required for SCT during that long breakout session about supplements at the New Orleans Connectathon. The 'poster child' for supplements appeared to be LOINC. What legitimate uses do you, or others, see in using supplements to SCT?

  10. 4.3.1.0.4 Display Terms for Specific Languages

    Any number of terms in additional languages and dialects can be specified for a given code in the ValueSet 'designation' element (ValueSet.compose.include.concept.designation). The language is specified as a BCP-47  language code as required by the 'designation.language' Preferred but limited to All Languages value set binding and would be mapped to a corresponding SNOMED CT language refset. The type of the term (e.g., the SNOMED CT code for "Fully specified name", "Synonym" or "Definition") can be specified in 'designation.use'. Note that to use 'concept.designation' the value set must be defined extensionally (i.e. as an enumerated list of concepts) rather than intensionally (i.e. using one or more filters).

    This can be done in a similar way using the CodeSystem 'designation' element for terms in a published national or other localized edition or in a code system supplement, with the additional terms then being available to be returned in a value set expansion, controlled by the $expand operation 'includeDesignations' input parameter (if supported by the terminology server). 

    Regarding the above, I don't understand the proposed linkage between a SNOMED CT language reference set and 'designation.use'; the value for 'designation.use' is drawn directly from the 'languageCode' column of the RF2 Descriptions file, which itself is an ISO-639-1 code and is thus compatible with BCP-47 (ISO-639-1 is effectively a subset of BCP-47).

    The SNOMED CT language refsets are not linked to the 'languageCode' field and have nothing to say about it. Instead they only indicate which descriptions are 'valid' designations and which one to use as the 'concept.display'

    I've proposed a wording change below to clarify this.  However, I'm not sure I follow what is being said in the italicised sentences so I have left them alone; the first sentence seems to be missing some context because it is suddenly talking about ValueSets and it is not clear what "to use 'concept.designation'" means - use how? 

    I also feel there should be some reference to the role of CodeSystem.language and the value of 'concept.display' and that it is up to the terminology server to select an appropriate value for 'concept.display' to match the CodeSystem.language value (if specified), and that this might also be influenced by an HTTP Accept-Language header or, when performing an $expand, by the ValueSet.language value.  However none of these things are particularly SNOMED-specific and apply to any CodeSystem supporting multiple languages.


    4.3.1.0.4 Display Terms for Specific Languages

    Any number of terms in additional languages and dialects can be specified for a given code in the ValueSet 'designation' element (ValueSet.compose.include.concept.designation). The language is specified as a BCP-47  language code as required by the 'designation.language' field and takes the value from the ISO-639-1 'languageCode' field of the RF2 Descriptions file. The type of the term (e.g., the SNOMED CT code for "Fully specified name", "Synonym" or "Definition") can be specified in 'designation.use' and takes the value from the 'typeId' field of the RF2 Descriptions file. Note that to use 'concept.designation' the value set must be defined extensionally (i.e. as an enumerated list of concepts) rather than intensionally (i.e. using one or more filters).

    This can be done in a similar way using the CodeSystem 'designation' element for terms in a published national or other localized edition or in a code system supplement, with the additional terms then being available to be returned in a value set expansion, controlled by the $expand operation 'includeDesignations' input parameter (if supported by the terminology server). 


    1. I think Michael makes some very good points.  I've incorporated most of what he suggested and the discussion today inspired me to do further rework and make some additional suggestions: 

      In the ValueSet resource any number of terms ('designations') in additional languages and dialects can be specified for a particular concept in a value set definition using the ValueSet.compose.include.concept.designation element. The language is specified as a BCP-47  language code as required by the 'designation.language' element, with the value taken from the 'languageCode' field of the RF2 Descriptions file ('languageCode' is ISO-639-1, a subset of BCP-47). The type of the term (e.g., the SNOMED CT code for "Fully specified name", "Synonym" or "Definition") can be specified in 'designation.use'.

      [Note that ValueSet.compose.include.concept is only used when the value set is defined extensionally (i.e. as an enumerated list of concepts).  For intensionally defined value sets (i.e. using one or more filters) additional terms could be added using CodeSystem.concept.designation, as noted below.]

      The CodeSystem resource can also similarly be used to specify additional terms ('designations') for a concept using the CodeSystem.concept.designation element (the additional terms may be from a published national or other localized SNOMED CT edition or provided in a code system supplement).  If supported by the terminology server, the additional terms are available to be returned in a value set expansion (controlled by the $expand operation 'includeDesignations' input parameter).