The specific problem was being caused by a CIEL concept that had been loaded into their OpenMRS instance followed by an import of the same CIEL concept that was cloned into their source with a new UUID.
“Pressure ulcer stage I” (CIEL 158507) imported into MSF server as concept 1059 with CIEL’s UUID
Cloned into an MSF source as “Pressure ulcer stage I” (MSF 3025) with a new UUID
Import fails (duplicate FSN) because OCL module doesn’t recognize concepts in #1 and #2 as the same concept.
Within the OCL module, I see this code that checks for UUID and then checks for a SAME-AS mapping to concept’s source and ID:
Concept concept = null;
if (oclConcept.getExternalId() != null) {
concept = cacheService.getConceptByUuid(oclConcept.getExternalId());
}
// If a match is not made on UUID,
// attempt to make a match on SAME-AS mapping
if (concept == null) {
concept = cacheService.getConceptWithSameAsMapping(
oclConcept.getSource(), oclConcept.getId());
}
Do you know what the oclConcept.getSource() is in this context? Will this be the source from OCL (e.g., “MSF” in this case)? So, adding a SAME-AS MSF:3025 would solve their import problem?
Yes @burke - I expect that will solve the problem. At this point of import, the incoming OCL Concept only has it’s own source/id, the mappings are imported and saved separately.
The challenge is that the OCL concept doesn’t know that it’s the same as the existing concept inside OpenMRS… the publisher would have to know to add the SAME-AS map to the OpenMRS concept_id. We talked about whether there could be other shared SAME-AS maps that would work as an identifier… SAME-AS SNOMED should theoretically be unique (although CIEL currently has 5K shared SAME-AS SNOMED codes). We need to do some cleanup. However, there are other SAME-AS concepts which are unique, such as the CIEL code (IMO, KenyaEMR, etc.)
Actually, @akanter, I think you’ve got it backwards. The SAME-AS mapping should be to the “official” code for the concept for the source. And OCL assumes concepts are stored under this official code. So, in this case, the official code for “Pressure ulcer stage I” within the MSF source is 3025, so the local concept should be mapped SAME-AS MSF:3025.
@lisamuga, if MSF goes through its source and adds a SAME-AS mapping for each concept to its “official” code (ID), this should address the issue. Since the Concept ID on OCL is assumed to be the official concept code for the source, then this means every concept in the MSF source would have a SAME-AS mapping to itself (e.g., MSF 3025 would have a SAME-AS mapping to MSF:3025 (i.e., source=MSF, code=3025).
For example, if you look at PIH’s Leg Pain (20138), there is a SAME-AS mapping to itself (PIH 20138) and OCL recognizes this as a “self mapping” indicated by a little ∞ superscript:
Once these self mappings are in place for the MSF source, any content imported into OpenMRS instances that gets assigned a random concept ID locally will be recognized as equivalent on subsequent imports through the self mapping (SAME-AS to an MSF code).
For any existing concepts already on OpenMRS instances, you would need to add these self mappings manually. In the example in my initial post, this would mean going to the OpenMRS instance where “Pressure ulcer stage I” was randomly assigned to concept ID 1059 and adding a SAME-AS mapping to the “official” MSF code (source=MSF, code=3025).
@lisamuga , let us know if this isn’t clear or if it doesn’t solve your issues.
