Stream: terminology
Topic: ConceptMap
Jay Lyle (Nov 09 2017 at 16:52):
I have some questions about conceptMap equivalence values.
relatedto - "The concepts are related to each other, and have at least some overlap in meaning, but the exact relationship is not known": If relationship is not known, why does this require knowledge of "some overlap"? Recommend removing that criterion. Requiring overlap prohibits mapping for any purpose other than synonymy (cause & effect, disorder & department, DRG to procedure, etc.)
equivalent - "The definitions of the concepts mean the same thing (including when structural implications of meaning are considered) (i.e. extensionally identical).": If there is a difference between equivalent and equal, it is not clear. 'Structural implications' requires further explanation or illustration of how they affect the mapping use case.
equal - "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)." See above.
wider - "The target mapping is wider in meaning than the source concept.": If there is a difference between wider and subsumes, it is not clear. If the distinction is > vs =>, perhaps the names could reflect this as "broader" and "broaderOrEqual"
subsumes - "The target mapping subsumes the meaning of the source concept (e.g. the source is-a target)." See above.
narrower - "The target mapping is narrower in meaning than the source concept. The sense in which the mapping is narrower SHALL be described in the comments in this case, and applications should be careful when attempting to use these mappings operationally." See below.
specializes - "The target mapping specializes the meaning of the source concept (e.g. the target is-a source).": If there is a difference between narrower and specializes, it is not clear. If the distinction is < vs <=, perhaps the names could reflect this as "narrower" and "narrowerOrEqual"
inexact - "The target mapping overlaps with the source concept, but both source and target cover additional meaning, or the definitions are imprecise and it is uncertain whether they have the same boundaries to their meaning. The sense in which the mapping is narrower SHALL be described in the comments in this case, and applications should be careful when attempting to use these mappings operationally.": This sounds like the appropriate home for the secondary sense of relatedTo
unmatched - "There is no match for this concept in the destination concept system.": Term sounds like "match not performed" rather than "match not found." Suggest "notInTarget"
disjoint - "This is an explicit assertion that there is no mapping between the source and target concept." This is self-contradictory, as “disjoint” is itself a mapping. Recommend “that there is no semantic overlap.”
Also, indentation suggests that ‘disjoint’ is a child of ‘unmatched’: this is incorrect. ‘unmatched’ rows have no target; ‘disjoint’ rows must.
Grahame Grieve (Nov 09 2017 at 21:22):
relatedTo: I disagree with removing the requirement for some overlap in meaning. "cause & effect, disorder & department, DRG to procedure, etc" - these are all changes to the scope of ConceptMap, and if we made the change (I think it would be good idea) would require additional consideration
Grahame Grieve (Nov 09 2017 at 21:23):
with regard to equal and equivalent: I think the difference between 'mean the same thing' and 'have identical definitions' is pretty clear.
Grahame Grieve (Nov 09 2017 at 21:24):
subsumes requires that the relationship between the concepts be is-a as well as the wider. Wider does not require is-a
Grahame Grieve (Nov 09 2017 at 21:24):
I don't mind the change to 'notInTarget' rather than 'unmatched'
Grahame Grieve (Nov 09 2017 at 21:25):
I think the suggested changes to disjoint definition is good
Michael Lawley (Nov 23 2017 at 01:43):
I agree with removing the requirement for overlap for relatedTo. One of the common relationship pairs we deal with is "belongsTo / memberOf" when, for example, grouping codes together into categories.
Michael Lawley (Nov 23 2017 at 01:47):
With regards equal and equivalent, I've had to ask this question more than once, and almost everyone I've tried to explain it to after they've asked me has not been satisfied. So I think the response of the difference is pretty clear is demonstrably false. It is not clear. The closest I get to understanding why the distinction might be important is when it is described in terms of a concrete example. At the very least I think such an example should be provided as both helpful explanation and motivation for the distinction.
Michael Lawley (Nov 23 2017 at 01:48):
+1 for disjoint
Michael Lawley (Nov 23 2017 at 01:49):
At one point I came up with the following table to try to illustrate the different meanings of the relationships ConceptMap-equivalence.png
It may /may not be accurate or helpful, but feedback appreciated
Peter Jordan (Nov 23 2017 at 06:16):
At one point I came up with the following table to try to illustrate the different meanings of the relationships ConceptMap-equivalence.png
It may /may not be accurate or helpful, but feedback appreciated
Why is there any overlap between the concepts for unmatched? I appreciate the need to distinguish it from disjoint, so maybe just touching for unmatched. A small point in an otherwise very useful illustration.
Jay Lyle (Nov 28 2017 at 15:26):
1. Examples show 'unmatched' without targets, confirming Lloyd's point.
Jay Lyle (Nov 28 2017 at 15:27):
2. The bits on the right don't seem Venn-distinct. I thought the diff was between "<" and "<=" but that's not what I see in the diagram.
Jay Lyle (Nov 28 2017 at 15:28):
3. but an excellent tool for settling things
Jay Lyle (Nov 28 2017 at 15:29):
I wonder if it's too late to create an alias for "ConcetpMap"
Rob Hausam (Nov 29 2017 at 10:50):
I agree that unmatched is (or should be) without target. As we discussed on the Vocab FHIR Tracker Issues call, I agree that the apparent distinction being made in the diagram on the right side between 'wider' and 'subsumes' and 'narrower' and 'specializes' (whether or not they "touch" at two points along the edge in the diagram) probably isn't a real or useful distinction to make. Any further clarification on that, @Michael Lawley? I'm not sure what you are thinking about regarding an alias for ConceptMap, @Jay Lyle?
Jay Lyle (Nov 29 2017 at 13:22):
Regarding "alias": I mistyped "ConceptMap."
Regarding the Venn sheet: I had thought I'd seen a distinction between "broader" and "subsumes." But, like the equal/equivalent issue, while I see a distinction for value set definitions, I don't see how it applies to value equivalence. I.e., I might have a value set defined as "things subsumed by hepatitis" (hep a, hep b, etc.) and I'd have to decide whether the general head concept was a member. But as for the concepts themselves, hep > hep a. Period. What am I missing?
I'm trying to think of examples where a concept can be defined as including more specific classes but not what they have in common, and all I can come up with is question codes ("kind of hepatitis"). Which is different.
Michael Lawley (Nov 29 2017 at 22:16):
My understanding is that broader and narrower allow for the kinds of issues that crop up when mapping between a poly hierarchy like SNOMED and a mono hierarchy classification like ICD 10.
Rob Hausam (Nov 30 2017 at 17:28):
I think that's right, Michael. But I think how that really works in that case is that what you would have might be more completely described as "inexact-broader" and "inexact-narrower" (which, if true, should be represented as subtypes of "inexact"). In your current diagram I think that "wider" is still showing true subsumption and "narrower" true specialization (as from the set membership perspective "touching" at points along the edges wouldn't invalidate that).
Michael Lawley (Dec 01 2017 at 00:01):
That sounds much better to me; they are special-cases of "inexact"
Jay Lyle (Dec 21 2017 at 13:45):
The sentences I'm reading make sense but I'm still not getting a distinction. Examples would be very useful.
Rob Hausam (Dec 21 2017 at 14:48):
@Jay Lyle Do you have suggestions? Do you want to add a tracker for it?
Jay Lyle (Dec 21 2017 at 14:51):
Of course: 14209
Jay Lyle (Dec 21 2017 at 14:55):
Suggestions: add examples to demonstrate, e.g., how Wider <> Subsumes.
"Mapping a polyhierarchy to a monohierarchy": getting there, but I still need the instance example.
Jay Lyle (Mar 09 2018 at 15:44):
Gforge 14209: It feels like the answers to these questions were "gee, that's complicated; let's not do anything." How do we line up act II? Would it be easier if it were 5 more bite-sized suggestions?
Jay Lyle (Mar 09 2018 at 15:53):
E.g., 1 - Either loosen the semantics of the binding or tighten the semantics of the resource.
related to - The definition specifies overlap in meaning. Does this mean that there are no use cases for other kinds of relationships? (E.g., CDC reportable condition mapping table for lab test to inferred condition). The property is called 'equivalence,' but the resource is 'ConceptMap.' Rename property 'relationship' (& expand binding) or rename resource 'equivalenceMap.'
2 - provide examples for equivalent & equal
3 - provide concrete differentation between wider & subsumes, narrower & specializes, with examples, and let the hierarchy reflect the relationships.
4 - distinguish 'inexact' from 'related to' by removing 'uncertain' from definition of 'inexact' and clarifying that it means that it is known that the relationship is not disjoint and not equivalent.
5 - decouple hierarchy of unmatched & disjoint - unmatched instances have no target by definition. (There may be two meanings: this map doesn't specify a match but we may not have looked; or we looked and we assert that the target system does not have a match.) Whereas all disjoint instances should have a target for which the disjointness is asserted. This suggests that 'disjoint' is not a specialization of 'unmatched,' for which instances do not have targets. Flatten.
Rob Hausam (Mar 09 2018 at 16:05):
We decided to pull this one from the block vote, so I think we can continue with Act I. Carmela Couderc requested the pull, and I asked her to help with figuring out what the right pathway forward is for this. She is planning to add some additional material on it to the tracker. Any or all of your thoughts above may be helpful. Do we need to form a small group (maybe the three of us) to work through this?
Carmela Couderc (Mar 09 2018 at 18:04):
I updated the tracker with some information that will help us move forward. Forming a small group sounds like a good plan.
Jay Lyle (Mar 09 2018 at 19:43):
Thanks. I think I've said what I know but happy to participate when meetings happen.
Rob Hausam (Mar 09 2018 at 19:44):
Thanks, Carmela. I've attached the diagram of ConceptMap equivalences from @Michael Lawley's post on Nov. 22.
Grahame Grieve (Mar 09 2018 at 20:17):
#1. I don't understand - I think you haven' said enough about why the definition of relatedTo suddenly becomes the need for a while new renamng
#2. good to provide examples
#3. ok to add better doco about the relationship between the difference and the heirarchy meaning
#4. not sure what the 'secondary meaning' of relatedTo is, but there's a big difference between 'these things are related' and 'these things have vague definitions that overlap to some degree'
#5 . the definition of 'unmatched' is clear: we looked and there is no map. But agree that you could assert a valid relationship from concept A to B, and also assert that the concept A is disjoint from concept C (that would be common) and so disjoint is not a specialization of unmatched
Jay Lyle (Mar 10 2018 at 14:58):
#1. the definition of 'relatedto' has two clauses: one that restates 'related to' as two words (could be more specific, but aligns with the general concept of map, NOS), and one that asserts an overlap (which is a more specific kind of relationships, which might be more appropriately named 'equivalenceMap').
Jay Lyle (Mar 10 2018 at 15:13):
#1 and #4 are related. perhaps this is clearer:
wider: A ⋂ B = A; A ⋃ B = B
narrower: A ⋂ B = B; A ⋃ B = A
equivalent: A = B
disjoint: A ⋂ B = ∅
inexact: A ⋂ B ≠ ∅
OR
inexact: A ⋂ B ≠ ∅ & A - B ≠ ∅ & B - A ≠ ∅
(i.e., distinct from wider & narrower)
relatedto: A ⋂ B ≠ ∅ (same as inexact #1)
OR
relatedto: no testable assertion can be made (leaving aside the question of whether all relationships must be equivalence relationships)
Grahame Grieve (Mar 11 2018 at 04:27):
so firstly, concept map is about equivalence. if you want to relate concepts by different criteria (e.g. 'this test for this disease') then we anticipate that you'll create CodeSystem supplements
Grahame Grieve (Mar 11 2018 at 04:28):
related to is for cases where at least some degree of overlap is asserted (as specifically different from unmatched or disjoint), but it is not possible to say more than that
Michael Lawley (Mar 12 2018 at 00:09):
My understanding of wider & narrower is that they allow for some "spillage", so
wider: A ⋂ B = A - ε; A ⋃ B = B + ε
narrower: A ⋂ B = B - ε; A ⋃ B = A + ε
The presence of the ε being the key distinction between wider and generalizes and narrower and specializes.
I also understand the difference between relatedTo and inexact as being more like
relatedto: A ⋂ B ≠ ∅
inexact: A ⋂ B >> ∅
Jay Lyle (May 24 2018 at 22:09):
Use cases needed
We are looking at the value set for ConceptMap equivalence. One of the issues is values that don't seem clearly distinguished, and we're tempted to recommend collapsing them. But we want to make sure they aren't needed.
1. Equal & equivalent.
The current structural distinction sounds like a reasonable criterion for value set definitions, but it's not clear how it applies to concepts from different systems. We need an example of how the distinction might be recognized, ideally with some functional consequence.
2. broader & subsumes; (same question for Narrower & specializes)
These seem indistinguishable. One suggestion was that the broader parent might be close but include some error, which is not tolerated in the child. For an automated map, it's not obvious where that distinction -- not a match, not a miss, but close -- would be useful.
If this is useful, it would also be good to know
a) whether this distinction is met by SKOS "closeMatch" or if it must also specify which side the error may be on.
b) whether "close" might subsume "match"
A second question concerns the need for many other values, whether sufficiently distinguished or not. The obvious use-case of substituting target values for source values in a specification seems to need a "match" value to support matches, possibly a "broader" value to support BT translations that may support valid albeit lossy rule application, and not much else. Can we identify use cases for no match, disjoint, narrower, inexact, etc.?
Grahame Grieve (May 24 2018 at 22:34):
1. I don't see why it matters whether they come from different systems for the difference. it might be more relevant if they don't have a definition
Grahame Grieve (May 24 2018 at 22:35):
2. see CodeSystem.heirarchyMeaning. if the hierarchy meaning is subsumption, then broader and subsumes are the same thing. But if either code system heirarchy is not subsumption, then they mean different things
Grahame Grieve (May 24 2018 at 22:36):
I don't understand the second question
Jay Lyle (May 25 2018 at 14:37):
1. If they come from the same system, they might have the same "structural" definition, in which case it's hard for me to imagine needing a map. If they come from different systems, the odds of the "structural" definitions being the same seem infinitesimal. But perhaps I don't understand what is meant by "structural" definition, so, again, some concrete examples would be most useful.
(The situation could conceivably, rarely, arise among extensions of SCT, but it's still unclear to me how the distinction would be useful.)
2. HierarchyMeaning describes the respective systems, not the map. The map, if we're talking about equivalence maps, is about semantic overlap, which, in the cases of broader and narrower, means subsumption. IMHO.
It's quite possible I'm missing something here, and I'm really interested in seeing some examples to find out what it is.
3. The "second question" (apologies for the numbering) is that even for values that seem semantically clear, I don't have any use cases. Examples would be nice.
All three questions are requests for examples.
Grahame Grieve (May 25 2018 at 17:00):
#1 you might not find examples of this amongst the big code systems , with their extensive editorial rules about meaning, but it's commonly encountered in the real world where code systems are exact copies of each other. or subsets of them are. We have lots of this at HL7 - and in the existing concept maps, in fact. See http://build.fhir.org/cm-address-type-v3.html.
But you might start finding it between LOINC and SCT if SCT starts importing LOINC concepts....
Grahame Grieve (May 25 2018 at 17:05):
#2: here's a code system where the relationships are not subsumptive: http://build.fhir.org/v3/AddressPartType/cs.html (not that this is not stated in the resource, erroneously and something that will be fixed as part of the UTG remediation). So, when mapping between address type code systems, you could assert that one code is broader than another, but not that it subsumes the other.
The same would apply if you were mapping between classifications - where the relationship between the terms is 'grouped-with', not 'is-a'. In this case, you could map 2 concepts as 'bigger' or 'smaller' without being able to say anything about 'is-a' between them
Grahame Grieve (May 25 2018 at 17:06):
#3: you're asking for examples for disjoint etc? or just saying that you don't have any use for that?
Jay Lyle (May 30 2018 at 22:19):
#1. I think the only distinction between the two is that the "The definitions of the concepts mean the same thing" vs "The definitions of the concepts are exactly the same." So, does this mean that the _text_ definitions are the same? Because it goes on to say they can have "grammatical differences," which makes it hard to say what the difference is between meaning the same thing and being textually sort of exactly the same.
E.g., the definitions of the address examples seem to me to mean the same thing, but I can't see arguing that the definitions are identical.
Mailing addresses - PO Boxes and care-of addresses. = Used to send mail.
A physical address that can be visited. = Used primarily to visit an address.
It seems to me that the point of the map is to assert that the definitions are equivalent, for the purposes of the use case, whether the text is identical or not. If there is a distinction to maintain here, what would be useful would be an example of a case where the distinction matters to someone.
(The "structural implications" verbiage hurts more than it helps, I think, as it doesn't distinguish the terms but it does introduce undefined complexity.)
#2. Yes, address parts can be compositional (though the only hierarchy I see in that system is subsumptive). But assume you have an address code system that does assert, e.g., that counties are parts of states. If I were to map Maryland from system A as broader than Arundell County from system B in a Concept Map I'd be doing it wrong. Concept Map relations are equivalence relations, not partitive. The internal relations the systems may or may not assert about their contents are orthogonal to the equivalence map.
So if the answer is that 'broader than' includes kinds of relationship other than semantic equivalence overlap, I think that stuff belongs elsewhere. Or, if we do decide to handle other relationships here, that would be in a different part of the hierarchy.
#3. I am asking for examples for all of these. Does anyone have any?
Michael Lawley (May 31 2018 at 00:16):
We use no match all the time, and inexact when the maps are auto-generated (because the algorithm can't be more specific).
In the past we've also used disjoint to help with QA
Grahame Grieve (May 31 2018 at 08:05):
@Jay Lyle
#1: "The home address of the patient" and "Patient's home address" are grammatically different but identical. It certainly is true that there's a grey zone here - we knew that when we defined the codes. But in principle, there's exact matches and non-exact matches. It's possible that some of the example is wrong - can you create a task to review the mapping equivalences there?
#2: the heirarchy is much flatter than it used to be... or I've processed it wrongly.... BNN, BNR, BNS are under SAL, but they are not is-a with "SAL". If you take for granted that concept maps are not about non-subsumption heirarchies then of course you won't be able to tell the difference between non-subsumption and subsumption based relationships since you defined use cases out of existence. I think you wrong about concept maps.
#3 we have an example of disjoint: http://build.fhir.org/conceptmap-example.html (here it makes a common confusion people have). I've seen no-match used as well
Rob Hausam (Jun 04 2018 at 15:45):
We are still working on the concept-map-equivalence valueset and soliciting requirements and use cases for understanding whether these codes are clear and consistent and sufficient for the intended uses of ConceptMap. We're also looking at SKOS and ISO 21564 (I'm looking for a more helpful reference) mapping codes/concepts to see if they can provide additional clarity or value. And we're also thinking about non-equivalence mapping uses for ConceptMap (for general attributes, etc.). Please add any thoughts, use cases, requirements and experiences that you have.
Carmela Couderc (Apr 18 2019 at 12:56):
In preparation for Montreal WGM, a small team of @Rob Hausam , @Jay Lyle , @Michael Lawley , @Reuben Daniels and myself planned to meet, but ended up with an email exchange, consolidated here: https://docs.google.com/document/d/1ViXN5iAo1mnG7s_SauzHtKBBHd869IwkvAsVYX0W7-0/edit?usp=sharing . Folks interested in ConceptMap and CodeSystemSupplement - please read. Thanks.
Michael Lawley (Apr 30 2019 at 03:55):
I've added come clarifying (I hope) comments to this doc
Last updated: Apr 12 2022 at 19:14 UTC
