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?
@k_joseph, I donât understand the question, could you give an example of what you are talking about?
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: http://pastebin.com/k6QxViTt 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?
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)â.
About the question, all your responses have given me a satisfactory answer, in short my issue was understanding the advantages in saving different concept_name.name
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 (concept_name.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:
- Always display back to the user the actual
concept_name
recorded in the medical record. - 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. - 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.