I already see a number of changes in ConceptMap source/target equivalence and I'm made aware that some more are coming.

• Rename equivalence relationship
• Rationalize codes in http://build.fhir.org/valueset-concept-map-relationship.html
• Change semantics of equivalence from target-to-source to source-to-target

In order of appearance:

• I don't feel too strongly about renaming equivalence even though "equivalence" is a well know term in our SNOMED NRC and in discussions I have on terminology mapping. I would have voted against renaming the element, because it does not seem to add to understanding what "equivalence" does, but it does add to conversion headache. But as said I'm not too strongly on that
• Rationalization of codes. I think the set in the current build (related-to | equivalent | broader | narrower | not-related-to) is better than the STU3 set. In the STU3 set which is my point of reference, there's too much overlap.
  • In FHIR-25923 however, there is another set of changes that should really be conveyed in relation to:
• Changing the semantics by reversing the direction of equivalence (now relationship) is what I strongly object to.

The semantics of equivalence have always been documented really unambiguously and clearly for this element. There simply cannot be any confusion over what the direction is. I understand someone like Michael Lawley even argues his implementation works fine the way things are...

Reversing the direction just creates a lot of extra work for anyone not starting from a white piece of paper. It is very likely going to create bugs for years to come in the interpretation of R5 versus pre-R5 for anyone who has ever worked with ConceptMap.

The strongest statement that comes to mind is that this change feels like a pseudo-change to fix something that is not broken. It feels like the ever changing ITS rules in V3 that ultimately made every normative release of V3 breaking compared to the previous year.

Please don't?

As for making more sense of the codes by merging a few, I'm fine with that. As said the R5 list as currently in the build seems much cleaner. Because there cannot be any confusion about the direction of relationship/equivalence, there really is no call for including that direction in the codes. But if you feel you must to make the direction as-is even more obvious, and avoid having to reverse that direction, I don't feel too strongly about that part.