Great discussion here. I would urge you to consider creating a separate module for the enhanced feature or at least being careful to make a very clean separation between the API functionality and these additional features.
Part of our vision for cohorts, and the reason for generalizing the household module into a cohort module, was to work toward enhancing the cohort features of the platform:
- The ability to capture visits, encounters, and obs on cohorts just like we do now for patients – i.e., migrating these features from Cohort Module into core.
- The ability to define different types of cohorts (household, treatment group, research cohort, etc.) – migrating this feature from Cohort Module into core.
-
StaticCohort
andDynamicCohort
as extensions ofCohort
- Static cohorts are manually managed lists of patients (all we have in core now)
- Dynamic cohorts are calculated lists of patients. To date, these have been implemented as part of reporting, but we’d like to make them a first-class feature of cohorts.
- Clients that just need to consume cohorts (don’t need to know or care how the list is generated) could inspect members via base Cohort class methods without needing to worry about static vs dynamic implementation details.
- For static cohorts, the ability to track membership over time (i.e., start & end dates on membership). This has been implemented in the Cohorts module.
- Cohort resources & operations accessible via REST API.
I think the design ideas in this thread look great, but I want everyone to be aware that there a a myriad of use cases for cohorts and its unlikely that all will be addressed through a single UI. In other words, we want to make sure that the API is solid and work toward getting those features into the platform. The cohort management UI(s) will continued to be supplied by modules like this one, but we’d expect there to be many different approaches & use cases. For example:
- Users could use a tool like the Cohort Builder to define dynamic and/or static cohorts.
- An outreach program might use a mobile application that creates cohorts for thousands of distinct households.
- A treatment program may use cohorts to record snapshots of who was in the treatment program at a given point in time
- A module could leverage cohorts to allow providers to define their own personal “patient groups” (e.g., “my diabetic patients” or “the list of patients I want to keep a close eye on over the next month”)
These are just some random examples, but should help make it clear that a single, unified, cohort management UI will not meet everyone’s needs. That said, there are definitely use cases for such management tools, so please don’t let my comments slow you down; rather, just understand that yours are just the beginning of great ideas on how the community could leverage a robust cohorts API.
I’ve created an Expanded Cohort Features project to add support for static & dynamic cohorts and bring the Cohort module’s date range for static cohorts into core as a first step toward achieving the vision mentioned above. It would be great to have a some real-time discussion (in a design forum) to coordinate these efforts.