Encounter Search cohort builder

Development
1

My team has been working on giving cohort builder a new look and an improved user experience, on the encounter tab search, we have a form that users can use to select patients who have had encounter based on the values specified in the field. Below is an image of the form

image.png1898×870 65.4 KB
Screen Shot 2017-05-08 at 2.52.03 PM There is a field “from form” that is used to select the form (e.g. Basic Form, Admission form (simple), AMPATH Adult Initial Visit Form etc.). We’re making use of the EncounterCohortDefinition via the encounterSearchAdvanced in BuiltInCohortDefinitionLibrary. But when a request body like the one below is sent

{ “type”: “org.openmrs.module.reporting.dataset.definition.PatientDataSetDefinition”, “customRowFilterCombination”: “1”, “rowFilters”: [ { “type”: “org.openmrs.module.reporting.cohort.definition.PatientDataDefinition”, “key”: “reporting.library.cohortDefinition.builtIn.encounterSearchAdvanced”, “parameterValues”: { “forms”: [“Admission (Simple)”] } } ] }

it generates an error that can be found here. I don’t know what the issue could be cc @mseaton @darius

2

Is this something you can consistently reproduce? For instance are you able to reproduce it at https://modules-refapp.openmrs.org/openmrs

3

Yes, if you go to the cohort builder in https://modules-refapp.openmrs.org/openmrs and select the encounter tab. Select any option for “from form” field and click on search. Then check the browser console. Or you can use postman to make a POST request to the endpoint https://modules-refapp.openmrs.org/openmrs/ws/rest/v1/reportingrest/adhocquery?v=preview

{
  "type": "org.openmrs.module.reporting.dataset.definition.PatientDataSetDefinition",
  "columns": [
    {
      "type": "org.openmrs.module.reporting.data.patient.definition.PatientDataDefinition",
      "name": "Given Name",
      "key": "reporting.library.patientDataDefinition.builtIn.preferredName.givenName"
    },
    {
      "type": "org.openmrs.module.reporting.data.patient.definition.PatientDataDefinition",
      "name": "Family Name",
      "key": "reporting.library.patientDataDefinition.builtIn.preferredName.familyName"
    }
  ],
  "customRowFilterCombination": "1",
  "rowFilters": [
    {
    	"type": "org.openmrs.module.reporting.cohort.definition.PatientDataDefinition",
    	"key": "reporting.library.cohortDefinition.builtIn.encounterSearchAdvanced",
    	"parameterValues": {
    		"forms": ["Admission (Simple)"]
    	}
    }
  ]
}
4

@femi, is the “forms” property meant to accept form names, and not just uuids or references to forms?

5

Yaaay! It worked. It should have been the UUID. I just tried it with that and it worked. Thanks. But just a quick question, there are some cases where we have used names as the value and it worked does that mean some fields accept names while some accept UUIDs strictly.

6

@femi, I would think it should always be uuid. Do you have an example of where you have successfully used names?

7

Actually this will depend on the implementation of getByUniqueId(String) for that domain object’s resources in the webservices.rest module. E.g. for encountertype we do accept UUID or name: https://github.com/openmrs/openmrs-module-webservices.rest/blob/2.19.0/omod-1.8/src/main/java/org/openmrs/module/webservices/rest/web/v1_0/resource/openmrs1_8/EncounterTypeResource1_8.java#L66

(So, UUID will always work, and name will sometimes work, and you probably have to peek at the code to see when it will.)

8

Just as @darius pointed out. Also on personWithAttribute library key. I can send the attributeType field as the name of the attribute. So should we change those implementations to make use of UUID?

9

I would generally use the uuid in all these cases, for consistency, for the next person who looks at the code without the context of this conversation.

-Darius (by phone)

1 Like