we are noticing that when we use initializer to import concepts, we can mention reference terms in the “SAME as mapping” column, and in that case, initializer will create the ref term with the coding. In the process, if a new ref-term needed to created, it is creating with a blank name. This is very confusing … is it possible to at least use the “concept name”?
@sivareddy - this isn’t something that is unique to initializer. I think the name on concept reference term is typically left empty but most of the different technologies. name exists on this object because it extends OpenmrsMetadata, but it is not used here meaningfully. There isn’t any harm in populating it, but I don’t think it would make sense to use concept name, as there is not a 1:1 relationship between a term and a concept, concept names change, etc. I could see defaulting the name to something like the typical <sourceName>:<code> syntax that we use throughout OpenMRS if that makes managing/viewing terms easier, but doing so could also cause some confusion. What exactly are you trying to gain by populating this?
3 Likes
btw, we mean “concept_reference_term.name” by name. While things work just fine … few things do feel confusing … 1) to search - people dont usually use code to search 2) When we make FHIR API calls, it comes as the code, but without a display … in India’s HIE context, a coding “should support” a name. Right now, we are just populating the same concept name/code
Not great, but if it appears as “LOINC:xyz”, thats ok too? @sivareddy
Is there a reason you can’t just load the name from the underlying concept?
I didn’t understand. You mean just specify the name of the coding as the same as the concept name? If you meant the same - yes, thats what we are doing … but thats not right imho. (This is what @mseaton mentioned above as well) For example, I can have multiple concepts linked to the same reference term. And if 2 are linked that way, that means the coding will have 2 different display when exported in FHIR. Confusing … alternate option as I mentioned is “LOINC:XYZ” if name is not there
The reference name is the name from the standard code system and cannot be implied by any other source (even if SAME-AS, theoretically). I think the intention was that the reference tables were indeed reference materials provided by a reputable source. CIEL does not include reference terms (only mappings to codes) as this changes the licensing. Users should have a license to view reference content (particularly reference_reference links). The code system:code option is probably best if you can’t use a URI to fetch a publicly available concept name for the reference code.
I apologise. You did say that and I missed that.
So the original request was “can the Iniz concept domain populate the concept_reference_map.name field.” So what value would we put there? The concept name (as originally suggested) would make that field, at best, equivalent to what you’re doing today. That means we still have the problem where the same mapping attached to two different concepts would have different names plus the problem that the name in concept_reference_map.name might become out of date with the name of the actual concept.
From the perspective of using this in an integrated system, this is actually worse than just omitting the display field or using the concept name. At best it communicates no more information than the system and code by themselves do, but in a non-standard format and it places that information in a field that is supposed to “be able to carry a human-readable meaning of the code for readers that do not know the system.” The problem is that if the receiving system naïvely displays the display string to the user, the user will now see “LOINC:12345-5”, which isn’t really helping anyone.
As @akanter says, the name that should go in the display field is the name from the standard code system, but I don’t see how the Iniz concept domain has access to that information. What could be done is to add a concept_reference_term domain to Iniz which could be provided with the correct strings and use that to to populate the concept_reference_term.name field with the name from, e.g., SNOMED or LOINC. That would be a reasonable way to populate the field with the “right” value.
1 Like
Ian, so you are suggesting that a decode file could be provided to those people who have licensed access to the reference terminology and the combination of the standard file plus this reference file would be used to populate the server? That makes sense from an IP protection point of view, but would cascade with each code system required.
Yes, that’s it exactly.
Ideally, there would probably be an authoritative terminology server that we could ask for the display strings. I’m assuming, though, that this either doesn’t exist or can’t reliably be connected to, such that we need this data in the EHR.
Thanks @ibacher @akanter - if the ref term name can not be included because of licensing. then I think thats absolutely fine - we will just advise the orgs in that case 
However, in India, anyone can use SNOMED-CT (still need a MLDS license from NRC) and it would be great to find a solution. As of now, I will just send the concept name
I cannot go on record saying that it is OK to send a SNOMED code with a CIEL concept name as the reference code title. We should figure out a way for India to leverage their license to populate the reference tables with their licensed content…
Understood Andy. since we are importing CIEL zip (from OCL) - actually even in case of synz, - I wonder what possible options can be