Cohort Module Enhancements

1 - What I am saying is that we wouldn’t be needing a mockup it the layout is going to remain just about the same…

Perfect then. The idea of sharing images was to make sure that UI based on different type of Cohort (Single Person or Multiple Person) is not missed somewhere in redesigning.

2- Also, I see that you have also added Integrate with Report module. Is that a high priority?

No, its not high priority if we can search data for existing cohorts. Also, I guess Burke`s module includes this feature.

Do tell me if you would want the old one redone, how in context of my first point

Bootstraping would automatically make UI better.

I guess I now have enough things to go on to make a proposal. I’ll go ahead and make one, after clearing these doubts

Yes, please go ahead and the proposal can be changed until last date and also adding comments to document would be much easier

I have a doubt here: What data are we searching for exactly? If we want to see the patient and we know which cohort he/she is in, we simply go to view cohort and see patient details

Seaching could be on any parameter including cohort or program. We should be able to search by patient data or by cohort data as a cohort can have 1000 patients and a patient can be part of multiple cohorts…

As Burke suggested, we would keep the UI and API separate (as currently it is). Also we would fing out if we are able to all type of serach and crud operations via REST on cohorts/members.

2 Likes

So we can divide our search into Patient Search and Cohort Search correct? Can we keep this as the base? That means that the search is primarily in these 2 categories. We can design separate mockups for both

Also, did you like the new UI mockups?

Yeh. New mockups are good and looks promising.

Yes. Spliting it b/w two different part would make it easier and better managed.

Consider two different scenarios: 1- Search a person xyz with attribute D. Result should be all cohorts person belongs to and details of this person.

2- Search a cohort (household) with attrubute 123, address province abc, and or household head name matches Rid. The resultset should be households matching to given criteria and on clicking one household a details page should open that displays the HH details, members in HH and details of each member, and HH head info

1 Like

Thank you so much for all the guidance. I’m actually in the process of typing out a proposal. Do give me a couple of days.

I believe that we should coordinate our efforts with @burke on the ‘Expanding Cohorts Module’ over a design call on a suitable date. The main objective would be to diligently split the work between them

Thanks @burke and @jdick for your valuable inputs and its a great idea @burke for taking up expanded cohort :slight_smile: @maimoonak and @bholagabbar great to see the discussion being taken forward and @bholagabbar I hope to see your proposal soon and as @maimoonak said we would be giving you our feedback on the same :slight_smile:

2 Likes

Thanks @sharonvarghese! Won’t disappoint :slight_smile:

Hello @maimoonak and @sharonvarghese. I have prepared a proposal and PMed you the same. Awaiting your suggestions :slight_smile:

2 Likes

I am Shekhar Reddy pursuing third year BTech from Keshav Memorial Institute of Technology, Hyderabad, India. I have been contributing to OpenMRS for the past 3 months :slight_smile: and I am interested to work on this project.

I have submitted my proposal(draft), I would like you people to review it and suggest if any changes to be made.

@maimoonak I’ve updated the draft as you suggested. :slight_smile: Thank you

1 Like

@shekhar , Please start a new topic with subject ‘Cohort Module Enhancements’ and share your proposal there… This would help in organizing feedback better. Also tag @maimoonak , @sharonvarghese, @burke, @darius

Hi @burke @jdick @darius , Sorry for not responding earlier on this. Please provide time feasible for you to discuss these. Thanks…

Hi @bholagabbar and @shekhar I have gone through the proposals and I must say that it’s a good effort :slight_smile: @maimoonak @burke @darius awaiting your responses on the same :slight_smile:

2 Likes

@michael Could we have @sharonvarghese listed as the Backup Mentor on the OpenMRS GSoC page here? She is the official backup mentor according to the final proposal page on the GSoC page here but the changes are still to be made. :slight_smile:

Sorry I am jumping on this late but it has piqued my interest, and I am coming from a point of ignorance - will this build on the Reporting Framework Cohorts?

Why I am asking is that in the current implementation there is the cohort builder and the reporting module cohorts and we are wondering what path to take when migrating from the cohort builder for ad-hoc reporting to cohorts built on top of the reporting framework.

Please put me on the right track if I am way off?

@bholagabbar will leveraging the reporting module cohort API reduce the amount of work you have to do.

Hi @ssmusoke thanks for showing interest. The idea of cohort module is to include it as a part of openmrs unlike the existing cohort builder which is a part of the reporting module. The cohort builder under reporting module has minimal features like statically adding patients to a cohort and every run gives a different set of patient names which is not what we are looking for. In our module, we have created strong API’s for creation of cohorts and addition of patients into cohorts. The other objective we want to satisfy is for utilizing HTML form entry module to create cohort encounters and observations unlike patient encounters and observations in openmrs-core.This cohort module is on top of openmrs-core.

@sharonvarghese My question is why not leverage the work done cohort definitions of the “new” reporting module & rest services, with the proposed UI for a different use case - which further improves what has been done before rather than having to build querying infrastructure from the ground up?

Thanks for input on this @ssmusoke. Hope you have fairly good idea of existing cohort module. Some initial discussion is here:

This was build as a GSoC 2015 project by @sharonvarghese. What Platform does not provide is capturing encounters and obs for non-patients or group of people, i.e., households, participants for a cohort etc.

This included adding additional tables for encounter, and obs specifically for cohorts (with best efforts to utilize existing tables for individual patient`s data management). This all was achieved, i.e., architecture and REST based services for that. But due to shortage of time, work on UI i.e. allowing data entry (Through HFE module) and management (with good and appealing UI) was planned to be done as a next phase i.e. GSoC 2016.

We are not aiming for reporting but on providing best possible UI for data managment (insertion, view, update) for cohorts (ex households) and cohort members (patients) as well. We have integration with reporting module in plan but that is last priority (extra credit feature). I hope we would be able to achieve this as well in current project.

You are right that for building querying and data export infrastructure we should build it on top of existing reporting module. This is something we can look into 2nd phase i.e. post midterm evaluation.

1 Like

As @maimoonak has already mentioned. We would build it on existing reporting module but the issue I noticed is that the values it returns (different patients) even though the query is the same like I mentioned in my previous post. As it is under extra credit we are not focusing on it right now. :slight_smile:

@ssmusoke, the primary purpose of the Cohort Module is to provide new features for cohorts that we would like to migrate into core so all aspects of OpenMRS (reporting, programs, orders, scheduling, etc.) can take advantage of them:

  • Support for both static & dynamic cohorts as two flavors of Cohort – i.e., cohorts can be manually defined/managed or can be dynamically/programmatically defined like reporting’s cohort definitions.
  • Allow for implementations to define different types of cohorts. Examples could include households, treatment groups, research cohorts, or just about any other purpose for grouping patients. What is done with the cohort will vary by use case, but they all share the need to define a group of persons.
  • Allow for encounters & observations of cohorts (groups of people) just like we do for individuals. We do not want to dual-purpose the existing encounter & obs tables, since doing so would over-complicate their use. Being able to gather observations about groups would be incredibly helpful, for example, for community health workers going into households and for data collections about treatment groups.

The old cohort builders was designed to allow users to define (build) cohorts by applying filters & constraints through a UI without programming. Such a tool could leverage the Cohort Module to persist its cohorts. I would not expect the Cohort Module itself to try to provide this functionality. If it did, I would want to ensure that this functionality is cleanly separated from the parts we want to move into core.

The cohort definitions within the reporting module were created for lack of having dynamic cohorts in core, do not share a parent “Cohort” class with static cohorts, and were targeting the needs of reporting. The Cohort Module should aim to provide a Cohort interface that underlies both static & dynamic cohorts (so clients can work with a cohort without having to know or care whether the cohort was manually or programmatically defined). Also, providing dynamic cohorts in core allows them to be used & incorporated into parts of the EMR that have nothing to do with reporting.

Please continue in discussion #software:add-on-modules, #dev or request a new category

Just bringing this discussion back to life, is there a link to the Cohort Module - can’t find it in the OpenMRS organisation