Stream: IG creation
Topic: Error in ConceptMap conversion
Alexander Henket (Feb 17 2020 at 19:42):
My input ConceptMap contains:
<element> <code value="55561003"/> <display value="Active"/> <target> <code value="active"/> <display value="Active"/> <equivalence value="equal"/> </target> </element> <element> <code value="55561003"/> <display value="Active"/> <target> <code value="recurrence"/> <display value="Recurrence"/> <equivalence value="specializes"/> </target> </element>
The html rendering displays:
55561003 (Active) equivalent active 55561003 (Active) narrower recurrence
And the QA page says:
ConceptMap/ProbleemStatusCodelijst-to-Condition-Clinical-Status-Codes: ConceptMap.jurisdiction[0].coding[0] information Code System URI 'urn:iso:std:iso:3166' is unknown so the code cannot be validated ConceptMap/ProbleemStatusCodelijst-to-Condition-Clinical-Status-Codes: ConceptMap.group[0].element[1].target[0] error cmd-1: If the map is narrower or inexact, there SHALL be some comments [comment.exists() or equivalence.empty() or ((equivalence != 'narrower') and (equivalence != 'inexact'))]
I can sure enough add a comment to satisfy the complaint, but is it correct to phrase a different equivalence value than the STU3 ConceptMap has?
Alexander Henket (Feb 17 2020 at 19:46):
Secondly: the STU3 ConceptMap says that equivalence serves to state relationship from target to source, not the other way around
The equivalence between the source and target concepts (counting for the dependencies and products). The equivalence is read from target to source (e.g. the target is 'wider' than the source).
Rob Hausam (Feb 17 2020 at 21:01):
For R5 we're in the process of cleaning up the ConceptMap "equivalence" codes (replacing them with a simpler set of "relationship" codes) and fixing the language and the codes themselves to more clearly and unambiguously indicate the direction for the "narrower" and "wider/broader" codes. In this case, 'specializes' in STU3/R4 is converted to 'narrower' in the current CI build - but that is going to be changed (very soon) to 'source_is_broader_than_target' (or 'source-is-broader-than-target'), based on our continuing discussions prior to and in Sydney and our vote last week on these proposed ConceptMap changes for R5.
Grahame Grieve (Feb 17 2020 at 23:23):
but that is R5, @Alexander Henket's point is quite valid
Rob Hausam (Feb 18 2020 at 04:19):
Sure. I agree that 'specializes' shouldn't be changed to 'narrower' for an instance in STU3 (or R4). I mentioned R5 because that conversion would be applied in going from STU3 or R4 to the current CI build (although the 'narrower' code is going to be changed soon), and at first that triggered the thought that the conversion code may have been applied incorrectly - but that appears to be a coincidence.
Alexander Henket (Feb 18 2020 at 04:38):
@Rob Hausam / @Grahame Grieve there are two points here:
-
you’d expect an STU3 ConceptMap to be rendered as an STU3 ConceptMap. Current rendering has all characteristics of R5. I think Grahame indicates he’s going to look into that?
-
Vocab aims to reverse the semantics of the equivalence from target-to-source to source-to-target in R5. I think that is going to make the conversion process a lot harder. In fact for people not using the IG Publisher it might be a gem they overlook and a source of confusion and bugs. I would vote against this change. It aims to end confusion but in doing so will add more (is my expectation). Target-to-source has been explicitly documented for the longest time, it was never ambiguous, just overlooked.
- Afterthought on why conversion might even be impossible: the IG Publisher requests a comment that tells something about the equivalence. I've just added these comments, but those make a whole lot less sense if the direction of the equivalence is reversed.
I see that the new relationship element still has the same semantics by the way: The relationship is read from target to source (e.g. the target is 'broader' than the source).
Grahame Grieve (Feb 18 2020 at 06:27):
As product director, I will insist on asking the implementers about reversing the direction. I'm.. ambivalent... myself
Grahame Grieve (Feb 18 2020 at 06:29):
I will fix the rendering. @Rob Hausam I think that this is arguing against the changes vocb has made there
Grahame Grieve (Feb 18 2020 at 06:30):
and yes, I'm fixing the rendering
Grahame Grieve (Feb 18 2020 at 21:14):
should be fixed next release
Alexander Henket (Feb 19 2020 at 12:42):
ConceptMap says
<element> <code value="55561003"/> <display value="Active"/> <target> <code value="recurrence"/> <display value="Recurrence"/> <equivalence value="specializes"/> <comment value="When problem is recurring, ..."/> </target> </element>
While the xml means recurrence specializes active, the html seems to be saying the opposite. Could it be that vocab is aiming to reverse the direction of relationship because of the HTML rendering?
Rob Hausam (Feb 19 2020 at 13:38):
Yes, that's part of it. It should read with the correct semantics when it's presented in a source | relationship | target table format - which it would if the relationship was has-narrower-target. But the decision in Vocab is that the relationship will now become source_is_broader_than_target (or possibly source-is-broader-than-target), so the table display rendering (leaving off the fourth column) would become 55561003 (Active) | source-is-broader-than-target | recurrence.
Alexander Henket (Feb 19 2020 at 15:48):
But if the HTML rendering is off you fix the HTML rendering, right? What's been decided effectively retrofits the ConceptMap into the rendering thereof.
Alexander Henket (Feb 19 2020 at 15:49):
the rendering is for humans. The ConceptMap is for tools. You break the connection between tooling and ConceptMaps to please the human eye :-)
Grahame Grieve (Feb 20 2020 at 01:01):
ok so how about
pasted image
Alexander Henket (Feb 20 2020 at 09:54):
Works for me. I like it. @Rob Hausam ?
Rob Hausam (Feb 20 2020 at 16:40):
I'm not seeing this as helpful - and I think it probably is going in the wrong direction. For mapping, I think that 'equivalent' (not 'equal') and 'broader' or 'narrower' (rather than 'subsumes' or 'specializes') are the semantics that are the most appropriate (in whatever specific permutations of the actual code strings we decide to use). That's what we did in the new simplified code system and value set (that Alexander said he agreed with earlier). I think I still prefer to stay with those changes and to finish nailing down the specific codes to use for the "broader" and "narrower" cases. I think you can only rarely (if ever) talk meaningfully and definitively about subsumption relationships between concepts in different code systems, which still is the primary use case for terminology mapping generally and specifically for the ConceptMap resource.
Grahame Grieve (Feb 20 2020 at 20:21):
so first of all, you're on the wrong track with what you are commenting about.
Grahame Grieve (Feb 20 2020 at 20:21):
@Alexander Henket (who's off for a week) and I are working on the rendering of an R3 concept map, not interested in the R5 changes. So first I'll comment on that
Grahame Grieve (Feb 20 2020 at 20:23):
Alexander's criticism was around the presentation of the directionality of the relationships - because the renderer simply renders the code, the presentation is mis-leading. So I've provided substitute wording to convey the directionality in the rendering, and that was what I was asking about
Grahame Grieve (Feb 20 2020 at 20:25):
On the subject of the R5 changes:
- when it comes to big public terminologies like snomed etc, you're right about rarely talking about subsumption
- but when it comes to private codes around status etc, it's actually pretty common to be able to say definitely that concepts are subsumed. I feel as though Vocab is ignoring the actual use of ConceptMap here
Rob Hausam (Feb 20 2020 at 20:31):
Well, sorry about that. There has been some discussion in the topic about the proposed R5 changes. I see now that your rendering of the relationship was a description rather than the code, but without an explanation of that I'm not sure that was particularly clear. Anyway, I get what you are trying to do. And I think we do (or will) need to consider where we'll end up on this for R5.
Grahame Grieve (Feb 20 2020 at 20:43):
I did the same for R5 - convey the directionality in the description (where it matters)
Grahame Grieve (Feb 20 2020 at 20:44):
if the directionality flips over then the descriptions will have to flip
Rob Hausam (Feb 20 2020 at 20:44):
right - thanks
Rob Hausam (Feb 20 2020 at 22:19):
I agree that having the directionality in the displayed description/definition text is where it is really needed, if that is sufficiently clear (and this will help). I'm not sure that we need to (or should) also force all of those semantics into the codes themselves (we already don't have meaningless identifiers, but this would take us even farther in the other direction).
Grahame Grieve (Feb 20 2020 at 22:45):
I'm not proposing to change the codes
Rob Hausam (Feb 20 2020 at 22:48):
Yes, I understand that you are not - at first I thought that was what you were doing, hence my reaction (apologies for the confusion).
Giorgio Cangioli (Feb 21 2020 at 14:28):
Grahame Grieve said:
Alexander's criticism was around the presentation of the directionality of the relationships - because the renderer simply renders the code, the presentation is mis-leading. So I've provided substitute wording to convey the directionality in the rendering, and that was what I was asking about
why do not "just" invert the order of the columns in the shown html (i.e. target - relationship - source) and keep the codes as they are now ?
or do you think that also this may be misleading in term of directionality of the map?
Giorgio Cangioli (Feb 21 2020 at 14:29):
BTW, is there any specific reason why "equivalent" and "equal" are both shown as "equivalent" ?
Rob Hausam (Feb 21 2020 at 14:33):
In the CI build (for R5) there is only 'equivalent', and when converting an instance from an earlier version to CI/R5 'equal' will be converted to 'equivalent'. But that shouldn't be happening if the rendering is being done in R4 or STU3.
Giorgio Cangioli (Feb 21 2020 at 14:51):
Working with R4, but not a problem to use only the "equivalent" concept..thanks
Grahame Grieve (Feb 21 2020 at 18:49):
is there any specific reason why "equivalent" and "equal" are both shown as "equivalent"
That should no longer be the case as of the last release
Michael Lawley (Jun 16 2020 at 11:06):
In a previous incarnation of our mapping tool, we rendered maps as source | relationship | target -- we continually had problems with a subgroup of our users who would not read this left-to-right because they were very close to their workflow of creating maps where the relationship is about the target.
When we migrated our tooling to FHIR, we changed the rendering of maps to be source | target | relationship -- this satisfied that subgroup of users, and we've not had negative feedback from anyone else.
However, I think it would be naive to think that this "solved" the problem. I rather suspect that it removed the dissonance created when people mis-understood the intended direction of the relationship and thus concealed the issue.
The root cause of the problem, IMO, is that the relationship codes in R4 and prior have implicit direction (target to source) and are thus open to misunderstanding and misuse. The only safe way to correct this is to clearly indicate the direction in the code (and it's display), rather than relying on the context of a rendering (be it human or technical; JSON/XML/...)
Rob Hausam (Jun 16 2020 at 11:11):
So have we achieved that (at least reasonably) with the recent updates that we have now in the current CI build (projected R5)?
Grahame Grieve (Jun 16 2020 at 16:58):
those also reversed the direction of the meaning, which was not necessary to solve it
Rob Hausam (Jun 16 2020 at 19:53):
Agree.
Peter Jordan (Jun 16 2020 at 23:59):
Maybe, if we had something like 'source_narrower' and 'target_narrower' then we might let implementations determine the direction of the relationship, rather than attempting to herd them all in one direction?
Grahame Grieve (Jun 17 2020 at 00:18):
I think that truly sounds unsafe, where the same code could mean the diametrically opposite thing in different implementations
Peter Jordan (Jun 17 2020 at 05:19):
hmm - if you expanded those codes to 'source_narrower_than_target' and 'target_narrower_than_source', I fail to see how that's any more unsafe than what's currently in R5. That is, unless you believe we can finally reach a consensus on a single direction.
The two codes that I've suggested would certainly fit my use case which is translating between different NZ Ethnicity Code Levels - but admittedly that is quite a simplistic one as the direction is implicit in the levels of the source and target.
Grahame Grieve (Jun 17 2020 at 07:02):
I must misunderstand you - we have to get consensus on a single direction.
Peter Jordan (Jun 17 2020 at 08:32):
Grahame Grieve said:
I must misunderstand you - we have to get consensus on a single direction.
Well, if anyone can achieve that, I guess that person might just be you. :)
Michael Lawley (Jun 18 2020 at 05:05):
The CODE tells you the direction. It is the only way that works - we cannot rely on the context of use of the code to indicate direction (what we had up to and including R4).
I don't see any problem with choosing the code source-is-narrower-than-target over target-is-broader-than-source -- they both mean the same thing.
While the latter, target-is-broader-than-source, is the replacement for R4's broader so it might seem a better choice, there was a strong preference for a code that "read" from left to right.
That is, 123 source-is-narrower-than-target abc was preferred over 123 target-is-broader-than-source abc because in both cases 123 is the source, but the second rendering can be misunderstood.
Michael Lawley (Jun 18 2020 at 05:09):
FWIW I think the Definition for not-related-to should be revised to use wording that is not directional.
e.g., This is an explicit assertion that the concepts are not related to each other.
Michael Lawley (Jun 29 2020 at 11:13):
@Grahame Grieve I am concerned that you think the direction has been reversed?
The underlying ConceptMap structure is the same and the code broader (with the meaning "target is broader than source") has been replaced by the code source-is-narrower-than-target (which has the same meaning). This also aligns with your desired rendering. I don't see any direction reversing, only clarification of ambiguity.
Grahame Grieve (Jun 29 2020 at 20:46):
@Rob Hausam and I reversed all the codes in all the instances as part of the change
Rob Hausam (Jun 29 2020 at 20:54):
I think I would say rather that we updated all of the codes, in accordance with the changes as Michael described. The intended direction of the maps is still the same (although there are a small number of cases where it was wrong, and I believe those still need to be updated). What has changed is how we are reading and describing the direction, not the direction itself - and now the codes explicitly state the direction in accordance with the reading "from source to target".
Last updated: Apr 12 2022 at 19:14 UTC
