Stream: ontology
Topic: terminology stream
Grahame Grieve (Jul 10 2016 at 20:56):
I have created a new terminology stream for discussions about CodeSystem, ValueSet, ConceptMap, and the terminology service.
Grahame Grieve (Jul 10 2016 at 20:57):
This stream remains focused on RDF, Turtle, RDF related reasoning, and bindings/mappings from FHIR to other ontologies
Erich Schulz (Jul 10 2016 at 22:56):
which is here to save you looking
Amy Knopp (Jul 26 2016 at 16:30):
Our terminology team has two questions on the ConceptMapEquivalence Value Set. First, can you provide the source (or reference) for these codes and definitions? Second, we have maps in which we have not asserted the map equivalence (map type = source “has” target). One way to address that scenario would be to retrospectively review and update the map equivalence. A second option would be for the code to be optional, and a third option would be add a concept to the value set of “unspecified association” or “associated to.” Although we have the capability in our organization to assert map equivalence, I expect many organizations (systems) may not, and so near-term, what do others think of a recommendation to make the code optional or add a concept to the value set that supports this scenario?
Grahame Grieve (Jul 26 2016 at 20:21):
first, there are both value set and code system references - is that what you mean?
Grahame Grieve (Jul 26 2016 at 20:21):
second, I'm not sure I follow. how are they 'associated'? Presumably you could rule out many of the equivalence values, yes?
Michael Lawley (Jul 28 2016 at 06:04):
@Amy Knopp I would expect that a default value of 'inexact' would be reasonable
We too have been struggling to pick apart the meaning and implications of the various codes.
Amy Knopp (Jul 28 2016 at 16:55):
Grahame,
The code system reference is: System URL: http://hl7.org/fhir/concept-map-equivalence. Is there an existing reference standard from which these codes/concepts are based? The scenario we have is when the map equivalence has not been asserted. They may be equal or they may be wider. We may change our approach going forward to assert the map equivalence more accurately, but for now, we have many mappings in which the ConceptMap.element.target.equivalence is unspecified (e.g. we provide the appropriate LOINC code to map to for a lab result, but don’t specify whether the concept map is equal or wider). Near-term we need to decide if we are going to leave the ConceptMap.element.target.equivalence as uncoded (even though it is “required”) or pick the best of the options provided (and not have it be accurate). Our recommendation is to either leave the map equivalence code as optional or provide a concept in the value set (http://hl7.org/fhir/ValueSet/concept-map-equivalence) for “unspecified association” or “associated to” (which I suspect may be needed by many organizations that do not have terminology servers that support this richness.
Your near and long-term recommendations are welcome.
-Amy Knopp, Terminology Manager, Mayo Clinic
Amy Knopp (Jul 28 2016 at 16:58):
Thank you, Michael for your input. We are considering the use of "inexact" (which will be inaccurate) or not coding the ConceptMap.element.target equivalence (which will be non-conformant).
Robert McClure (Jul 28 2016 at 18:49):
I agree that if this is a required element the value set needs to include "Unspecified". The problem with making the element optional is that it allows laziness to creep in, but I would understand that is a change that should also be considered.
Grahame Grieve (Jul 28 2016 at 19:25):
but you can rull out unmatched, and disjoint, right? Maybe we should create a parent concept for equal, equivalent, narrower, wider and inexact. Called 'related to'?
Robert McClure (Jul 28 2016 at 19:55):
@Grahame Grieve I agree, that is another solution but while I think it's semantically correct, I'm not sure that it helps because the inferencing capabilities don't seem that useful, but I might be missing something. Even so, your solution is workable and I don't think it would lead to misuse (I hope.)
Grahame Grieve (Jul 28 2016 at 19:57):
well, it's saying at least that the association is no 'not this one'
Michael Lawley (Jul 29 2016 at 06:31):
My terminologists would be very happy with related_to -- often maps are built for use-cases where inferencing is not required.
I would strongly object to unspecified; it offers no advantage over making the equivalence optional; it can't be used to disabiguate related_to and unmatched, which will lead to problems of ambiguity
Rob Hausam (Jul 29 2016 at 12:28):
+1 for related_to, as Grahame described
Last updated: Apr 12 2022 at 19:14 UTC
