Thanks @sharonvarghese! Won’t disappoint 
Hello @maimoonak and @sharonvarghese. I have prepared a proposal and PMed you the same. Awaiting your suggestions
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 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. 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 @maimoonak @burke @darius awaiting your responses on the same
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.
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.
@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.
Just bringing this discussion back to life, is there a link to the Cohort Module - can’t find it in the OpenMRS organisation