A "Cohort" defines a group of patients. The need to define groups of patients comes up frequently in clinical care. Grouping of patients can be used during treatment (e.g., an HIV support group), for research (e.g., look at 'all males age 18-30 with diagnosis X' for shared risk factors), in population health (e.g., defining households in an outreach program), and many other scenarios. To date, OpenMRS has had a simple model for defining cohorts (the cohort – i.e., group of patients – has a name and description, patients are added to a cohort by adding an entry to the cohort_member table (there's a corresponding Java model for Cohort in openmrs-core). In the Reporting Module, cohorts were extended to include "evaluated cohorts," which are cohorts defined by a set of criteria – i.e., a list of patients determined by comparing patients to a set of criteria instead of a manually-managed, static list of patients.
Currently, Program/Workflow is not functioning as it intends to. In order to track patient list with certain characteristics, cohort builder and reporting definitions have been used. Limitation for cohort builder : it is static. Whenever a cohort definition is re-run, the list will be different (some from original list might no longer meet the criteria due to change of data and some new ones will be added). Limitation for report definition: it is dynamic. The list of patients changes.
There is need to enhance Cohorts to add new cohort members who meet criteria WITHOUT removing those who no longer meet the same criteria.
As the usage of OpenMRS grows, we need to expand the capabilities of an OpenMRS Cohort to meet the need of implementations. The goal of this project is to add two specific features to Cohorts within OpenMRS Core:
- Refactor org.openmrs.Cohort to serve as the foundation for both Static and Dynamic cohorts within OpenMRS Core, trying to maintain as much backwards-compatibility as possible.
- For static cohorts, add a date range to membership (i.e., start & end dates)
By the end of this project:
- Existing code built against the core API can continue to use Cohorts (through both Java API & REST API) much like it has without needing to be refactored except where it makes assumptions that all cohorts are static.
- For instances of "StaticCohort", clients will be able to ask the API "how has this cohort changed between Date X and Date Y" and "what was the list of members as of Date Z"
- OpenMRS Core will have the foundation to support dynamic cohorts so this functionally can begin to migrate from the Reporting Module's EvaluatedCohort into core's new "DynamicCohort"
- Apply changes as needed to the Cohort Module so it complements/leverages the expanded Cohort capabilities of OpenMRS Core
- Java web application development
- Experience with Spring, Hibernate, MySQL, Git, Maven
- Experience with (or willingness to learn) test-driven development or behavior-driven development
- Experience with (or willingness to learn) RESTful API development
- Willingness to learn and follow design patterns and best practices of the OpenMRS platform