Stream: implementers
Topic: Use of “Wider” v “Inexact” in concept-map-equivalence?
Thomas Wicker (Jun 13 2017 at 17:50):
All - dealing w/a mapping question, wondered if people might have an answer as to what's intended:
Is there a standard for distinguishing between "inexact" match and "wider/narrower" match in concept mapping?
https://www.hl7.org/fhir/valueset-concept-map-equivalence.html
Reason I ask:
We (McKesson Clear Value Plus) have terms that seem in grey area between these. Example: We're mapping our (source) "Colon Cancer Stage at Diagnosis: Stage IIA" to NCI Thesaurus (target) "Stage IIA Colon Cancer." Would folks consider that "wider" or "inexact?"
Support for "wider:" Target includes all Stage IIA colon cancers; ours is a specific (at diagnosis) Stage IIA colon cancer.
Support for "inexact:" Target concerns stage without any information re: temporal/sequential/contextual info; ours specifies "at diagnosis," a part of the meaning external to NCIt concept.
Some instances are obviously wider/narrower (e.g., a general Stage II Colon Cancer is wider than Stage IIA Colon Cancer); this is one where, depending on what we're thinking at a particular point, we might go either way. Any guidance as to how absolute the boundaries are would be deeply appreciated. 
(In case anyone's interested, the NCI Thesaurus concept:
https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&code=C115041 )
Eric Haas (Jun 13 2017 at 18:10):
@Rob Hausam ?
Thomas Wicker (Jun 13 2017 at 22:32):
(or anyone else? :) )
Grahame Grieve (Jun 13 2017 at 22:45):
I would call that inexact. In general, if it is not specifically 'narrower', in that the semantic space of the 2 concepts overlaps without one completely containing the other, then it is an inexact mapping
Thomas Wicker (Jun 14 2017 at 13:01):
@Grahame Grieve -- thanks; we're going w/your answer from here (makes a lot of sense). Would it be appropriate to submit request for https://www.hl7.org/fhir/valueset-concept-map-equivalence.html to include examples/more detail around wider, inexact, etc.? Would be happy to volunteer to work on that, since we're in middle of implementing equivalences.
Grahame Grieve (Jun 14 2017 at 13:07):
sure that would be good. add suggested text to the task
Rob Hausam (Jun 14 2017 at 21:51):
I agree with Grahame's reasoning, but using it I arrive at a different conclusion. From my reading of the descriptions I think that the semantic space of "Colon Cancer Stage at Diagnosis: Stage IIA" is completely contained within "Stage IIA Colon Cancer". "Colon Cancer Stage at Diagnosis: Stage IIA" has the additional temporal qualification of "at diagnosis", and any instance of it is also an instance of "Stage IIA Colon Cancer", so I think that a mapping of "wider" in this case is entirely appropriate.
Grahame Grieve (Jun 14 2017 at 22:28):
but the cancer might now be at stage III. Or in remission. The qualifier 'at diagnosis' is more significant to me. (but good that we agree about the principles ;-) )
Thomas Wicker (Jun 15 2017 at 15:29):
@Grahame Grieve re: "might now be" -- exactly how this came up. For our system (Clear Value Plus, an oncology CDS system), current stage is more important than stage at Dx. For colon cancer specifically, when we care about stage, it's pathologic (post-surgical, well after diagnosis) stage. So we're going w/inexact & explaining our reasoning in the equivalence comments (since all this really does is help external parties understand why we did what we did so they can determine if their understanding of ConceptX matches ours well enough to map).
Thomas Wicker (Jun 15 2017 at 15:36):
Basically, by using "inexact," we're hoping to flag the term for external mappers to say, "You'll want to closely check this mapping because it loses some of our meaning" -- same as a "narrower" mapping would. Might be that they're ok w/that (e.g., if theirs is also Stage at Dx & we're the only system they integrate with), might be that it's a problem; this just helps them determine that (we hope).
Same reason we're explaining "wider" maps and not just narrower/inexacts; if you're sending us information, and your concept is equal to a concept that's wider than ours (and especially if we end up mapping one wider target concept to several of our source concepts), if we return the info to you, we might not return the correct value or we might misinterpret what you meant.
Thanks, all!
Rob Hausam (Jun 16 2017 at 21:29):
Yes, there is this "temporal shift" aspect which I wasn't addressing in my response. But, thinking about it further, I'm still not sure if that makes the "inexact" mapping to "Stage IIA Colon Cancer" the best one. I think it may matter whether we consider what we are mapping to be a reference to the instance of the tumor which was characterized as "Colon Cancer Stage at Diagnosis: Stage IIA", or a reference to the diagnosis itself. Following on with @Grahame Grieve's example, if we are thinking of the tumor instance, which may progress over time (and if we either do not know or are not considering information about the current stage), then the only thing that you really know for sure is that it is a "Colon Cancer" (whether in the same or a different stage or in remission), and a mapping to a concept of "Colon Cancer" (not further qualified) would be the best - and that mapping, I think, would still be "wider". If, on the other hand, we're looking at the diagnosis itself as an independent entity, then whatever happens with the instance at a later time isn't really relevant, and in that case I think that the "wider" mapping to "Stage IIA Colon Cancer" would still be the best one. This is tricky. If I'm still missing something, let me know what you think it is.
Grahame Grieve (Jun 16 2017 at 21:31):
well, this is something that comes up - the mapping depends on context as much as the underlying meaning of the codes. This is why ConceptMaps are always qualified by a value set (as a proxy for context)
Rob Hausam (Jun 16 2017 at 21:35):
I will also grant that @Thomas Wicker's last point about using "inexact" as a flag to alert downstream mappers/users that they need to pay attention because meaning may be lost is probably legitimate, and may hold sway here.
Rob Hausam (Jun 16 2017 at 21:35):
Agree, @Grahame Grieve
Last updated: Apr 12 2022 at 19:14 UTC
