Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
SNOMED Spaces
SNOMED on FHIR
Results will update as you type.
  • Meetings
  • Member Sharing Page
  • Collaborative Work
    • FHIR Terminology Services and Resources
      • CodeSystem, ValueSet and ConceptMap resource naming, identification and versioning
      • Setting up and operating a FHIR terminology service
      • Intensional reference sets versus intensional ValueSets
      • Changes to SNOMED CT to improve usage through terminology services
      • Update SNOMED CT Search and Data Entry Guide
      • SNOMED CT "Universal" Edition
      • SNOMED CT canonical CodeSystem resource
      • Check and fix ECL in the FHIR spec
      • Normal form and normal form terse definition
      • Implementation Guide for using SNOMED CT with FHIR
      • Mechanisms for working with Languages
      • Discussion on Global Patient Set (GPS)
      • API for FHIR Resource to SNOMED Expression
      • snowstorm FHIR requirements, issues, etc.
      • SNOMED CT and CodeSystem Fragments
      • Discussion related to changes appearing in R5
      • Surfacing Alternate Identifier Values in FHIR
    • Bindings to FHIR Clinical Resources
    • Completed Items
    • Maintenance / On Hold
  • Discussions
  • Tasks
    You‘re viewing this with anonymous access, so some content might be blocked.
    /
    Surfacing Alternate Identifier Values in FHIR
    Updated 2025-May-27

      Surfacing Alternate Identifier Values in FHIR

      2025-May-27

      ECL

      ECL 2.2 specifies support for Alternate Identifiers see 6.1 Simple Expression Constraints eg LOINC#54486-6 (which would be expanded inline before any further processing is done). 

      CodeSystem Property

      See Zulip discussion on a name for this new property:  https://chat.fhir.org/#narrow/channel/179202-terminology/topic/Alternate.20Codes/with/510871290 

      See "alternateCode" references in https://build.fhir.org/codesystem-concept-properties.html

      Concept Map

      Finding the LOINC code from a SNOMED SCTID will work easily via an implicit concept map and the $translate operation.  The suggestion is to use the alternate identifier file schema SCTID as we would normally pass a refset id.  This is not required.  The "identifierSchemeId" performs a similar function as a refset id.

      peter@PGW-IHTSDO-4 tmp % head sct2_Identifier_Snapshot_LO1010000_20250321.txt alternateIdentifier effectiveTime active moduleId identifierSchemeId referencedComponentId 1-8 20250321 1 11010000107 30051010000102 480081010000105 10-9 20250321 1 11010000107 30051010000102 480091010000108 100-8 20250321 1 11010000107 30051010000102 480101010000104

      <server>/fhir/ConceptMap/$translate?code=529881010000108&system=http://snomed.info/sct&version=http://snomed.info/module/11010000107&targetsystem=http://loinc.org&url=http://snomed.info/sct?fhir_cm=30051010000102

      This would recover one specific schema, but what if we wanted to recover all alternate identifier maps (as opposed to all maps)?

      <server>/fhir/ConceptMap/$translate?code=529881010000108&system=http://snomed.info/sct&version=http://snomed.info/module/11010000107&targetsystem=http://loinc.org&url=http://snomed.info/sct?fhir_cm=equivalentConcept

      Since the targetSystem allows you to work out which schema is being referred to, using "equivalentConcept" removes the need for the schema identifier entirely.     And we can miss out the targetSystem if we'd like to recover all alternate identifiers for a given SNOMED concept.

      See "LOINC Ontology" discussion (item 9) in 2025-04-06 - SNOMED on FHIR Meeting (TS & TB)

      See also Zulip discussion: https://chat.fhir.org/#narrow/channel/179202-terminology/topic/Alternate.20Codes/near/517923587

      Discussion

      ML Suggests that alternate codes in a different CodeSystem  should not be surfaced as an alternate code via a CodeableConcept 

      Shrimp exposes "Identifier" as a Coding type, so specifies both that it's the LOINC URI and the code (this was rejected as being already too heavily overloaded a word)

      2025-04-15 "alternateCode" ← workshopped by group.

      2025-04-29 further discussion on Zulip.  "equivalentConcept" now gaining traction.   The datatype would need to be Coding, as a code on it's own is meaningless.

       

      Copyright © 2025, SNOMED International

      {"serverDuration": 15, "requestCorrelationId": "60b3aeee927f4404a39d9f08a76fce54"}