Show only the form specific observations in the patient dashboard observation display control

Current Behaviour:

Observation Display Control(ODC) can be configured to display all the observation values captured against the configured concepts(and within the configured number of visits). We can configure ODC specific to a form by configuring the form specific concepts/generic one where the concepts can be pulled across the forms. As part of our implementations, we mostly used the form specific display control and the display control name will be the name of the form.

Sample Form specific display control:

Problem Statement: So far we have used unique concepts across forms, so the above mentioned display controls are working as expected. But one of our implementations planning to use OCL concepts where we have to use the same concept across the forms. With this approach, we end up seeing observations values for a concept captured across different forms in the form specific display control.

Requirement: The form specific display control should only show the obs captured as part of the form. It shouldn’t pull the obs from different forms though the same concept being used across the forms.

Technical Approach to pull only the form specific observations:

Configure new parameter like mentioned below in the exiting ODC configuration file.

“conceptFilterByFormName”: “Form A”

This would be an optional parameter. This would take the name of the form as json value. If the parameter is there, it will pull the observation very specific to the form. If not, it falls back to the existing behaviour (as per the inputs provided by community in the last PAT call)

@angshuonline @gsluthra @swedhan @buvaneswariarun @vmalini @matirp235 @tarunshettygari @muhima08 @michaelbontyes @megkmcguire

Just validating my understanding.

  1. You are wanting to enhance the Observation Display Control (documented in wiki here). Is this right?

  2. There is also a Forms Display control (type="forms"), which shows previously filled forms for a patient (see documentation in wiki here). This form doesn’t fit your usecase?

  3. If you do plan to enhance the Obs Display Control (point 1 above), then you can consider introducing maybe something (optional) like: filterConceptByFormName. Will you introduce this only in dashboardConfig section? What about expandedViewConfig section?

  4. Is form-name unique enough? Or is there some other Form attribute that can be used to indicate the exact Form? Also - i am not sure, but is Form Name the same across all languages? Is there a form identification attribute that will work which doesn’t change irrespective of the locale in which the form was filled?

  5. If the same form is published with a new version, and the concept is dropped from this version – i guess the display control will still need to show the older values, which was filled in previous form (without making any changes to the display control configuration). What do you think?

  6. Looks like the type field is not used in Obs Display Control. I wonder why is this the case?

yes…you are right

We are already using this Form Display Control as part of our implementations. The advantages of configuring Observation display control over form display controls are,

  • Separate display control for each form, and directly visible on the patient dashboard.
  • We can configure only specific concepts as part of the display control where as Form display control will show all the observation filled for the form.

sorry that i missed to mention the specific details here…the new parameter would be configured for both dashboardConfig and expandedViewConfig.

The forms that created from implemeter-interface should have unique form names. FormFieldPath is unique across forms in an implementation. Bahmni allows us to give different form names for different locales. But FormFieldPath is unique irrespective of the locale that we choose.

This scenarios is working fine with existing configuration and will still work fine with latest configuration.

The existing ODC API call returns all the observation captured against the concept, with the formFieldPath for each observation. We will use “conceptFilterByFormName” values to filter the form specific observations from existing list.

yes… type is not mandatory in the obs display control. If a display control has a config parameter “isRequired” then it will consider that as observation display control.

Thanks @binduak. All my questions above got answered.

  1. So, this means you will likely use formFieldPath to specify the exact form. Can you give an example of how this looks? Should we consider calling the attribute: filterConceptsByFormFieldPath:, so there is no confusion?

  2. This new attribute is optional and will be ignored for backward compatibility, or for cases where people want current behaviour.

  3. [Side Note] I feel like it was a design miss from our side to not support type=observations. It would have made for clearer display control documentation that using the type attribute itself, one can figure out which control is being used. Just for this control, the type field seems to be ignored. Shall we create a JIRA ticket for newer Bahmni versions to support type attribute for this control too? Is there any unexpected side-effect if we do that? Even in future i think, if we create a UI for designing dashboard, it will look for one attribute to detect display control types.

  4. [Side Note] Does it make sense to have some “settings icon” which when clicked on a display control, it will show the controls current JSON configuration? I feel that will make it easy to see what is setup, and why a control is behaving a certain way (will be useful for implementers to debug / copy behavior). This might need to be privilege controlled, so only power users can see it (for reducing visual overload of icons).

as per PAT call discussion yesterday, we can use the attribute name as "filterByFormName". And the below is the sample configuration

yes @gsluthra its for the existing behaviour.

yes @gsluthra i feel the same. When it comes to observation display control, type doesn’t have any significance. Without type attribute, observation control will work the same. Where as type attribute is very important for other display controls in Bahmni. We can create a JIRA card to add type as mandatory field in the configuration. But this would require minor changes in the bahmniapps. @angshuonline what do you suggest ?

yes @gsluthra this is very nice idea. But we should restrict edit option as much as possible. Only the view option. Because editing might bring some syntax errors and page will not be able to load.

@angshuonline @gsluthra @buvaneswariarun @swedhan As per yesterday’s PAT discussion, we will be going ahead with the dev effort and raise the PR to product. We will keep this thread updated.