@akanter There are cases where I would like to change the using a CIEL concept say 161558 - Patient tested for sexually transmitted illness in current visit
I would like to change the preferred label in English to “Patient tested for HIV in current visit” to display in the encounter dropdown (see attached image below)
What is the proper way to do this without affecting CIEL compliance?
Sorry, started a response which didn’t get submitted… First, the actual form description does not have to be in CIEL or the database for that matter. We had started the process of structuring those “captions” in the data so that you could get standard forms and standard translations. However, that is not a requirement and you can manage the “captions” on the forms just being careful not to change the meaning. In your example, you ARE changing the meaning and therefore this should be a new concept. Second, if you want to actually change the database description (new concept_name description) then that should be submitted to CIEL. In this case, we would have told you that it is not possible to use that description on that concept. Third, if you are just wanting to change the preferred description to a different existing concept name, then that is an interesting customization that we should discuss with OCL (@paynejd).
@ssmusoke try overriding the display value via a messages.properties file, like is done here: https://github.com/PIH/pih-bahmni-config/blob/master/ces-config/openmrs/i18n/concepts/locale_en.properties
@darius Thanks
Does the file have to be in the same path as above or can I use my module messages.properties file
Is there any autowiring or additional configuration needed?
This is truly neat!!! when I get it to work 
Whoa, what is this? Are those concept_name UUIDs being overwriting the titles in script? Someone please reassure me that we are not allowing for systematic renaming of concepts at the display level.
I see that they are not concept_name_ids but are concept_ids. What is the implication of this? Where are these substitutions performed? If this is in a properties file, I presume that these are not updated over time with changes in the dictionary either. This seems like a bad, bad idea. Please help me out here @darius!
@ssmusoke, if you put these in any of your messages.properties files, they should override the concept names in the UiUtils.format(...) commands, and the display property of REST calls. I don’t know for certain if all the screens consistently use these calls, so you’ll have to check that.
FYI this feature is intended for translating any kind of metadata in the UI, in fact it’s the preferred way to translate most metadata, e.g. here is the French translation for the Vital Signs encounter type in the reference application.
We do allow this (i.e. the code supports it), but we don’t ever use it in the Reference Application.
As @akanter points out, it’s bad practice to use this feature for concepts. Concepts already support localization, and further this can lead to incorrect displays, if the concept names are edited.
The only time I suggest you use this feature with concepts is in the situation where (a) you cannot modify concepts, e.g. you subscribing to CIEL via sql dumps, and (b) you need to change the display (and you know the risks). For example we used this in a limited way in the Ebola project to make a handful of concepts match the names they were using on paper forms.
As soon as we have a better way to subscribe to CIEL (e.g. using OCL) then this hack will no longer be needed.
@ssmusoke, when I suggested this approach, I was assuming you’re in the situation where you are taking the CIEL dictionary via SQL dumps, and you can’t otherwise modify concepts. If that’s not the case, and you were just asking Andy how you should edit concept names to still be CIEL-compliant, then you should not do what I said.
@akanter @darius I am not using this feature for localization but rather tweaking the CIEL concept names “fit” the need for the moment including match the names on forms and within common usage.
This is exactly the gist of my question, how to change the label for a concept within its meaning
@darius and @akanter, at the risk of asking a dumb question, but for the sake of argument - how do you square your assertion that it is bad practice to have custom display names for concepts that are managed outside of the concept dictionary when we talk about using message properties, and yet we have always (and continue to) support and endorse having custom labels for concepts when configured within a Form (using any of the various form entry technologies)?
Why is this bad?
message.properties -> "concept.<uuid for weight concept> = Weight in inches"
When this is generally considered ok?
<obs conceptid="<uuid for weight concept>" labelText="Weight in inches"/>
Thanks, Mike
It’s good (and expected) for a form field to have a custom label, and to be mapped to a concept. But the custom label is applied at the level of the form field.
It’s bad to do a global override of how a concept is displayed. That’s what the concept’s preferred name is supposed to be for. And doing a global override will change the way the concept is displayed on all forms.
@darius The challenge with having a custom label in the field is that then the data on the Visits page is shown using the preferred name - which causes issues with the facility staff at implementations. The staff are experts with paper tools, have received training on those tools, therefore the solution has to match their expectation.
A challenge would be overuse of this solution
I would definitely allow modification of the prompt used to collect the data to match the forms. Getting the actual concept stored in the database to show the “correct” name should go through CIEL. We can work with you on getting the right term there… and OCL can certainly help… but for now, I think CIEL needs to hear.
@raff I am wondering how possible is it to be able to override concept names in the dashboard widgets seems like UIUtils does this for GSPs automatically
@akanter Sorry to bring back this topic, but we have run into a situation where the concept name changes in the UI leave the database out of sync since the override is not available.
@dev5 @dev4 @dev3 - would live to hear your thoughts on this proposal
Add an IMPLEMENTOR code in the concept name table which can be used to override the FULLY SPECIFIED NAME in a locale (only affects locales where it is specified)
Since concept names are added numerically have a safe range where these codes MUST be used (or does it not matter for concept names)
I think we really need to discuss this live. I think there are key best practices about defining concepts which should not be broken, but there are display opportunities when it comes to how things appear as questions on forms. The one thing we don’t want to do is have people “redefine” the meaning of concepts on the fly.
When would be a good time to talk? I am going to be in UK timezone starting Monday next week until Friday.
