How should the alternate identifier for the LOINC Ontology be represented using the HL7 FHIR concept map?
The ConceptMap.group.element.target.relationship only allows for:
• Related to
• Equivalent
• Source-is-narrower-than-target
• Source-is-broader-than-target
• Not-related-to
Discussions at past SNOMED business meetings led me to believe that the alternate identifier is a “stronger” relationship statement than an equivalent map between two terminologies because it represents an identical reproduction of a concept.
In FHIR R4, ConceptMap.group.element.target.relationship used to have a value of “equal” with a definition of “The definitions of the concepts are exactly the same (i.e. only grammatical differences) and structural implications of meaning are identical or irrelevant (i.e. intentionally identical).” This value does not appear to have been carried forward into FHIR R5, R6, etc. It is possible, the alternate identifier use case for the LOINC ontology didn’t exist when the decision was made to remove “equal” as a value from this data element.
Questions:
is the FHIR concept map resource, the correct resource to be used to represent the alternate identifier in the LOINC ontology?
Should a request be submitted to HL7 Terminology Infrastructure WG to have “Equal” reactivated as a valid value for ConceptMap.group.element.target.relationship?
Due to my ignorance in this space, I am certain I am missing, misunderstanding or failing to ask a pertinent question, so please fill in any gaps I may have missed.
According to this documentation, the SNOMED and LOINC concepts are “more than an equivalent mapping”. Instead, they are considered “exactly the same”, or alternate representations of one another.
With that said, FHIR ConceptMap may not be the ideal resource to use here. Instead, a CodeSystem supplement could be used to define additional properties, in effect linking one code to another. In Canada, CodeSystem supplements are used to add designations (French terms) to English HL7 codes.
It would be an interesting exercise to express the LOINC ontology in this manner. Not sure about the licensing implications or if someone has already attempted this.
Feel free to DM me if you want to talk about this more.
There was a lengthy discussion, that included this topic, on the FHIR Chat Site which landed on rendering LOINC Extension Concepts as a property named ‘equivalentConcept’ of type CodeableConcept.
There is a codesystem concept property for alternateCode that would be used to indicate a potential replacement concept for an inactivate or retired concept. Examples of appropriate use for LOINC would be a deprecated LOINC code that has a value(s) in the Mapto file and the user is requesting these possible alternative codes. Same would be true for content in the SNOMED AssociationRefset. The primary point here is that both the codeable concept and the alternatecode be in the same codesystem.
The code system property of “EquivalentConcept” is a codesystem concept property for defining the exact representation of a concept in a different code system.
Could you point me to FHIR resource for R4 and R5 that lays this out as I am having issues finding it?
The only place where it could be a little confusing is that the mapping of LOINC parts (i.e. LP codes) to SNOMED Concepts would be communicated using the Concept Map resource, but the alternate identifier from SCTID to LOINC code uses a property of codable concept.
The equivalentConcept property was only established last year, so it won’t appear in the R4 or R5 specifications which can’t be changed retrospectively. Hopefully, it will appear in an updated version of this page by the time that R6 is published.
We have only just started using the Alternate Identifier RF2 file so all of this is still quite new.
It’s clear that the semantics of the alternate identifier file are the same as a bidirectional SAME-AS / Equivalent map, or a map in each direction, between the SNOMED CT code system and the code system represented by the alternate identifier scheme.
I don’t think we have agree how the information in the alternate identifier RF2 file should be exposed in FHIR R4. I believe it would be most consistent and useful to have an implicit FHIR ConceptMap, or pair of maps, to represent this equivalence. This would fit nicely into R4 and later implementations.
This would not prevent anyone using the equivalentConcept property in addition to an implicit map.
This is a strange case because we are representing a LOINC concept within the SNOMED CT system so although one could argue the two representations are equal (the same thing) they are in different code systems so “equivalent” seems more accurate and practical.