Show patient language in Appointments list view

If its a server side extension in your custom omod, then why not return a single value instead of multiple? You might as well return

{ languages: “English, Hindi” }

You would still have to live with the “key” and “:” prefixed. but would that not be acceptable? If it is, then we don’t have to do anything. (You can override the column name in your specific language pack!)

Another thing that can get effected is the sort-ability. But I wonder if someone would want to sort of such columns in an appointment list, and for what purpose?

This “additionalInfo” data was meant to push such arbitrary unforeseen attributes to be displayed. (and hence such provision as a generic way).

For example, what would you do if you were returning other additional information? and all these were important to be shown?

{ “language” : “English”, “spouse_name” : “Bahubali”, “spouse_number” : “87123123” }

@pramidat For 1: I would so no. We wouldn’t want to introduce configurations at that level. Also consider the above example, it does not make sense.

For 2: “additionalInfo” is a json object. not a string.

Alternatively, few ideas

  1. Just for this, and assuming one and only “additionalInfo” column will suffice. return something like
{
   "display": "Speaks English & Hindi, alternate number 87123123 (spouse: Sudhakar)" , 
   "language" : "English", 
   "otherLanguage" : "Hindi", 
   "spouse_name": "Sudhakar",
   "spouse_number": "87123123"
}

So the hack is that if the “additionalInfo.display” attribute exists, then show that, alternatively show the string formed from the other keys. (I personally don’t like it but leaves some bit of generality)

  1. Take one or more attributes from the “additionalInfo” object, and show that as individual columns in the table. We can have a configuration element saying

“additionalColumns” : [“language”, “spouse_number”]

So the above two columns apprear in the list as columns, and the remaining ones in the “additionalInfo” column like before!

This solves the sort-ability as well.

More work in idea 2, than 1, but idea 2 is more generic.