Cohort Builder Sprint 17 Demo Announcement

Hello Everyone,

Please accept this invitation to our Demo happening tomorrow (Friday 22nd December 2017) between 4: 00pm - 5 : 00pm EAT.

In this sprint, we worked on testing the implementation and fixing arising bugs, some final house cleaning of the codebase and project, and documentation.

Please find more details regarding the demo and the tasks we worked on in this sprint below:-


Date : 22/12/2017

Time : 4 : 00 PM - 5 : 00 PM (EAT)

Sprint Announcement : Cohort Builder Sprint 17 Announcement

Video Call Link : Hangouts Link


Sprint Wiki :

Jira Board :

Github Repository :

Cohort Builder Demo App Link :

cc @dkayiwa

1 Like

For everyone who did not make it for the demo call, you can view the recording here ==>

Thank you so much for sharing the demo. You are ALL awesome!

  • Why is description a required field for composition queries? While it’s great to have the option to provide a more detailed description, I would expect the system to use the composition as the description by default.

  • The naming of sections and table columns under the “Saved” tab (seen here) is confusing to me as an end user: “Query Definitions” and “Cohort Definitions”. I would expect to be able to save my queries (what to search for) and cohorts (the list of people returned from a query).

    • What’s the difference between a “Query” and a “Query Definition”? If these are synonymous, could we simply refer to these as saved queries?
    • What’s the difference between a “Query” and a “Cohort Definition”? I thought a cohort definition == query (i.e., the “definition” of a cohort was the query used to retrieve the cohort).

    Based on the input labels on the page, I’m assuming queries were called “Definitions” and the section titles should actually be “Search Saved Definitions” and “Search Saved Cohorts” and the table columns “Definition Options” and “Cohort Options”.


-Burke :burke:

1 Like

Hello @burke,

I hope you are well.

First, I would like to say that I am honoured by your compliment, thank you, and YOU are awesome too!

Glad to know you watched the video, and thank you for your feedback.

In response to your concern over the required description field in the composition tab, the thought process behind it is that using the Composition as a description was not so user friendly.

Context : Let’s assume we have a long list of results in the search history. And we had performed a Composition query for 1 AND 3. Now consider that we later wanted to revisit the composition query, and its description was 1 AND 3, and there were other similar descriptions for other compositions.

I believe you would have to scroll down the whole list in order to figure out what the query was in reference to.

We had also considered using the existing descriptions albeit with the logical operator applied in the query, however, the lengthy descriptions would also make the column too wordy.

I believe the description here is just a memory marker ie if our query was for patients with Patients with FIRST Weight (kg) < 500 AND Patients with Encounter of Types Admission. The user could simply put Earliest <500KG; Admission in the description, or how best they can remember it. Which would also be a good thing, if they were required to send someone else to check the data on their behalf.

Also, should they have per chance cleared their search history, and done a whole new set of composition queries with different results; it would be easy to recognize the missing results, rather than if they were certain the results for their previous query were still on the list.

I would love to hear your reflections in this regard.

In regard to the section and table column naming in the Saved tab. I have revisited the tab and I understand and agree with your concerns. I will be raising a ticket to resolve that. Thank you.

Lastly, thank you for that tip on Hangouts on Air, I will definitely put it into practice and share it with others.



I guess it depends, in part, how long these compositions are going to be around. Perhaps we’re considering different use cases for the Cohort Builder. I would agree that a composition named “1 AND 3” from 2 months ago would be an unhelpful name. On the other hand, if it’s a composition I created a few minutes ago, then “1 AND 3” is more than adequate, especially if I’m trying out a few compositions to reach my final cohort or just to perform some quick validation on the system.

I would suggest leaving the description optional and using simple descriptions (like “1 AND 3”) by default. When users are testing out some queries, they won’t be bothered by a requirement that forces them to make up names like “asdf” just to meet the requirement for a description on compositions that are either only needed for a few minutes or are a step along the way to their final cohort. Anyone who finds the descriptions inadequate is free to enter an (optional) description more suitable to their needs.