| Info | ||
|---|---|---|
| ||
This project is being considered as a potential project for Google Summer of Code 2015. If you are a potential intern and are interested in working on this project, please discuss it in detail with the mentor(s) listed here before submitting your internship proposal. |
Primary mentor | |
Backup mentor | |
GSoC student | TBA |
Abstract
GSoC student | TBD |
Primary mentor | |
Backup mentor | TBD |
Background
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.
Objectives
- Expand cohort to include "start date" when patient met the cohort criteria, "end date" when cohort members no longer met the criteria.
- Create a scheduler task in OpenMRS that enables users to define a cohort. The task periodically then executes the definition to get list of cohort members, and adds it to the original cohort (without removing).
Extra Credit
- TBD
Suggested timeline
April ?? – May ?? (Community Bonding Period):
- Get to know my fellow peers and co-workers
- Throughout this period, I will as always be available on IRC to further discuss the proposal with members of the OpenMRS community so that I will be able to adjust or add things that I may have not thought of before.
- I will be actively engaged in discussions with my mentor to further understand and agree on the scope and requirements of the project.
May ?? – August ??:
- Development phase (to be broken down into detailed steps)
Resources
...
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"
Interested Implementers
Extra Credit
- Apply changes as needed to the /wiki/spaces/~sharonvarghese/pages/19530323 so it complements/leverages the expanded Cohort capabilities of OpenMRS Core
Resources
Requirements
- Java web application development
- Experience in:with Spring, Hibernate, MySQL, Tomcat, Git, Maven
- UI development skills including AJAX, JQuery, AngularJS, SASS
- Test-Driven Development or Behavior-Driven DevelopmentExperience 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