I don’t believe there is any intent that a concept name could be attached to more than one concept. The value that I see is in being able to uniquely identify a concept name attached to a concept for loading purposes - otherwise, assuming that changes to the actual name text is allowed, there is no way to determine when concept names are modified, unmodified, added, or removed when importing a dictionary. But dealing with uuids in this way can be incredibly unwieldy.
Given the use case that I’ve heard @akanter describe, where concept names are first-class metadata that are directly associated with OpenMRS Data to record the specific name that a user chose, if we want to continue to support this we clearly need a way to preserve existing concept names between concept import jobs.
Supporting the ability to attach a fixed uuid to a concept name in our loading tools (i.e. initializer) would seem like a reasonable first step, given that it is relatively quick and easy to implement and would provide this flexibility to those that need it. This is among the few improvements suggested in a ticket around this. But I recognize that most existing implementations using initializer for Concepts won’t have this in their CSVs and many won’t want to add them.
The other approach one might consider would be to assume that changes to the actual wording of a Concept Name represent the need for a new Concept Name and do something like follows:
-
If an existing name has exactly the same name text as one you are loading, then modify it if other properties have changed (name type, locale, locale preferred) and make no change otherwise
-
If no existing name matches the one that you are loading, create a new name
-
If names exist on the existing Concept that don’t match the name text of any concept that is being loaded, then for each of these determine if the existing name is in use (i.e. attached to a diagnosis) and if so retire it, otherwise purge it.
Unfortunately, in OpenMRS we have Concept Name as a Voidable entity, not a Retireable entity. I don’t know/recall if this was an intentional design decision or an oversight, but this would pose a challenge to the above strategy, if it were worth pursuing.