Any Advantage(s) of storing distinct conceptNames of the same conceptId

Just encountered this while construction SQL queries to fetch results from the DB to offer to solr for the chartsearch module where i would return synonymous sort of concept_names having the same id which is actually of help to me to return more relevant results, however i thought it a wiser decision to know why we do this, what are the benefits of doing this?

@k_joseph what do you mean storing distinct conceptNames of the same conceptId? Do you mean the attribute “name” of the concept_name table being unique?

1 Like

@k_joseph, I don’t understand the question, could you give an example of what you are talking about?

1 Like

Because i18N ?

Yes @willa, i mean column ‘name’ of concept_name table, it’s entries though different from one another can be of same concept_id, here is an example: So am wondering what could be the reason for this, i thought name is the main column of concept name and each name would have a unique conceptId,

The idea is to store multiple names for the same concept. It is also helpful when you want to store names for different locales. Or putting it another way, how would you go about storing the names displayed in the link you provided?

1 Like

So do you think if the user searches a specific name from the UI, would it be a good idea for the chartsearch module to return all other names for the same name searched or rather return one which is searched?

I think there was a discussion of what names to return when searching for a drug and since drugs are linked to concepts I believe your question is related to that discussion. It is unfortunate however I don’t remember exactly what the conclusion was but I think @burke and @darius might have a better idea.

@k_joseph, I don’t understand what you’re asking here. Can you please clarify.

As an example, “Heart Attack” is a synonym for “Myocardial Infarction”. I.e. that Concept has at least these two names. Some other synonyms from CIEL for that concept:

  • infarto de miocardio [es]
  • MI (Myocardial Infarction) [en]
  • myocardinfarct [nl]
  • Infarctus du myocarde [fr]

In a UI where you are picking a concept, you might be shown something like “Heart Attack (a.k.a. Myocardial Infarction)” in the search UI.

If you’re showing a list of the patient’s obs, you would just want to see one row (e.g. “Diagnosis: Myocardial Infarction”) or, if the obs.value_coded_name field records the obs against a specific synonym you might show something more like “Diagnosis: Heart Attack (a.k.a. Myocardial Infarction)”.

1 Like

About the question, all your responses have given me a satisfactory answer, in short my issue was understanding the advantages in saving different database entries with yet the same concept_id.

For now, I am supporting searching patient allergies using the chart-search module, and my background indexer takes all coded allergies name ( of a given concept_id therefore including all other names of the same allergy, So i wanted to know what needs to be the better display on searching, would the module include all other names of a searched coded allergen among results or it would only show the one searched!

@k_joseph the reason you have multiple rows in the concept_name table with different name column values but same concept_id values is because a concept can have multiple names, this is so because we need to support synonyms and internationalization, as you may already know concept.names is a collection


Some general rules:

  1. Always display back to the user the actual concept_name recorded in the medical record.
  2. If you need to translate the concept_name into a different concept_name on the same concept, then it is important to show the original as well.
  3. Searching for data within the medical record would generally be at the concept level (or at a mapped code level) and not the specific concept_name. It does not matter if I search a record for ALS or Lou Gehrig’s disease… either should return the other. If you are searching a DICTIONARY, then you would preferentially return the term they searched for.
1 Like