Ability to configure alternate terms from custom dictionary for concepts

Hi, In Bahmni, we have a way of generating reports using SQL queries. One of our customers would like to create an Observation report, which has concept names and answer concept names in a tabular format. The answers should be replaced with a Numeral (based on some non-standard dictionary). The output is consumed by some statistical tool for further analysis. For example, a question called “Posture?”, the answer 1 denotes Sitting and 2 denotes Supine.

We are planning to model it as a custom Concept Source and the reference terms as the numerals (1 and 2 in this scenario). i.e. obs (value_coded) -> concept (concept_id) -> concept_reference_map (concept_id) -> concept_reference_term (concept_reference_term_id) -> concept_reference_source (concept_source_id)

Is this approach correct? Is there a better alternative like using concept tags or concept names with a custom concept_name_type. Request your help in this regard.

I think you probably would want to use the code field rather than the name field for the new concept source. The concept source would be something like “Bahmni report code” and the code would be 1, 2, 3, 4, etc. These would be placed in the reference map with a relationship type of “Narrower than”. Since more than one answer term will map to the same “code”, it can’t be SAME-AS. Does that make sense?

Thanks @akanter. I think that approach works. One more similar use case. We have to show a “Drug-o-gram” on the patient summary dashboard. The drugs are configured in the system with the associated concepts having their own SHORT and FULLY_SPECIFIED_NAMEs. But we would also want to store its abbreviations. For example, Isoniazid as a drug will have an abbreviation of “H”. This should be shown up in the “Drug-o-gram”. We are planning to model it similar to what you mentioned i.e. defining a new ConceptSource for Abbreviations and concept_reference_term:code will denote the abbreviations. Do you see a better approach or this is fine?

One problem with this approach is that you are still putting reference terms on Concepts, not on Concept Answers, which is where you actually need the codes. For example, in the contrived example where for one question 1=Red, 2=Blue, but for another question 1=Yellow, 2=Green, 3=Red, 4=Blue, how would you apply code 1 for Red for the first question and 3 for Red for the second question?

It seems to me that this is something more associated with the form schema than with the concept dictionary directly. Though if the above scenario will never take place, then it might still be the best we can come up with using existing structures for now. Of course, you can always use a custom JSON configuration file to make these associations for exports.

Thoughts? Mike

Hadn’t thought that the same answer might have different numbers for different questions… if that is the case, than Micheal is correct. We need a different approach. As for the Drug-o-gram, it does seem that the short name would always be true for that concept. However, for the UI approach, I would think that we’d want to include the abbreviation as a short name. Can we do that in a particular locale to avoid confusion with other short names?

Hi @mseaton, I agree that this approach wouldn’t work if the same concept answer means two different things in two different contexts. But I personally think if the answer is different in two contexts, it should be a different concept. i.e. Yes should represent the same answer for whichever question. But we will get more clarity on the requirement before we proceed forward. Thanks for your suggestion.

Hi @akanter, in Bahmni we use ShortNames as the form displays. i.e. Isoniazed will be shown as H (if configured as short name) on the form UI and it is not very clear what it means… especially if the person is a data entry operator. So, we are thinking of abbreviation dictionary. Also, regarding the locale support, the abbreviation reference term will contain a KEY which will be translated into the specific locale according to the locale specific configuration

Sorry for the late answer here.

In the scenario where you want to display a specific concept name in only one context I have used a concept name tagged with a special tag. (E.g. names tagged with “Ebola UI” were used preferentially when displaying names in the Ebola tablet app.)

A benefit here is that you could even have a specific tag for each report that needed custom output codings.

I don’t know whether this is theoretically better or worse than using a concept reference source.

(Note that concept name tags can’t be managed through the UI and you need to set them via code or in the DB.)

In the bigger picture, in Bahmni you will eventually want to move towards a model where forms have a representation outside of just being a concept set. Depending on your time horizons, you might consider using that hypothetical new mechanism to handle the answer codings.

Agree with Darius that the specific concept_name which is used should be based on a tag rather than a map which would apply to all names for the mapped concept. Also, I am not clear what exactly is being proposed for the short names and the likely ambiguity of them (given they are so short). Maybe this requires an actual design call…