Coded patient attributes showing up with fully qualified name on patient dashboard

It seems like coded patient attributes, when included in the patient dashboard are shown with their fully qualified names instead of their short names. Is this a known issue?

Bahmni version 0.91.

Moved to the bahmni category.

Anyone has an idea about this?

AFAIK, Reg app never had such means, also unlike in clinical app config registration app, does not have any such config. You may introduce a config element in reg and also implement the display.

Hi @angshuonline @ramses

The following are the two approaches which I think should be followed for this:

  1. Change in API from Bahmni Core

As the API throws fully specified name of coded person attributes, we can add a constraint to first check for short name. If the value is null then pick fully specified name.

  1. Referring the person attribute service from Registration module to Clinical module.

According to me, the first approach is better even if the change has to be made in the core. Using such an approach the earlier functionality will also not be disturbed whereas, in the 2nd approach, there is static change .

Thoughts ?

we should be consistent in our API responses. API must return also concept “names”, specific to user local/application local. I think the API should return all the names (application default locale & user logged in locale) and all the names (FSN, short, synonyms) and the frontend should make the decision (based on configuration whether to show FSN or SHORT, or by default show SHORT unless specified so).

In our relevant work around localization, we are taking the following approach:

  1. return all names (application locale and logged in user locale)
  2. a function on the frontend filters out and picks up the right name
  • filter out name for the logged in context locale. if names are not found, then pick the names for the application locale
  • by default pick up the “SHORT” name, unless a function parameter specifies different (FSN or otherwise)

@praveenad ^

The above mentioned issue has been overcome by making the changes to the REST API of openmrs core.This API was bringing only fully specified names for coded person attributes.

I have added the constraint for also sending short name in the REST API. Below mentioned is the file path and the code.

openmrs-module-webservices.rest/omod-1.8/src/main/java/org/openmrs/module/webservices/rest/web/v1_0/resource/openmrs1_8/ PersonAttributeResource1_8.java

On line number 296 and configured the resultant value on UI.

      @PropertyGetter("display")
     public String getDisplayString(PersonAttribute pa) {
	if (pa.getAttributeType() == null)
		return "";
	if (Concept.class.getName().equals(pa.getAttributeType().getFormat()) && pa.getValue() != null) {
		Concept concept = Context.getConceptService().getConcept(pa.getValue());
		ConceptName name = concept.getShortNameInLocale(Locale.ENGLISH);
		String displayShortName = name == null ? concept.getDisplayString() : name.getName();
		return concept == null ? null : displayShortName;
	}
	return pa.getAttributeType().getName() + " = " + pa.getValue();
}

@angshuonline Please review so that I can raise a PR.

Hi Pallavi, I am currently working on obtaining from Bahmni core, names (both fully qualified and short) of concepts in system default locale and the users’ logged in locale and filtering them out at the client side.

I think the code you have posted would modify the default behaviour of the display field of PersonAttributeResource1_8 to always return shortname in English. The consistency that Angshu has mentioned in his response will not be met out with this change.

Also wouldn’t be you modifying core webservices rest module of OpenMRS?

Hi @praveenad

For the short name to display according to the logged in locale, we can pass Context.getLocale() as an argument instead of passing Locale.ENGLISH

But, this will pick the default language of OpenMRS.

Can you please elaborate on your approach using Bahmni Core for this?

hi @angshuonline Yes, I have modified the same.

I have tried to meet this change with modification in bahmni core. But, it looks like the value present on dashborad is coming from OpenMRS REST API

Hi Pallavi,

I have essentially made two changes in Bahmni core:

  1. Make BahmniConceptResource return names in both system default locale and user locale
  2. Introduced a new NamedRepresentation for personattributetyperesource that will make the attribute type data to contain names and locales for all the answers of attribute types.

I can provide code details in a day or two.

-Praveena