Cohort Modules Categorization/Typing

[burke (Burke Mamlin)]

@jdick

I’m not sure we have exact consensus on the definition of a a System list. Examples of system lists might be a service delivery queue, a list of patients who missed their appointments, etc.

A User list would be one created and managed by a user.

These sound like alternative names for what I believe Cohort Types was originally intended:

• Static Cohort – manually defined
• Dynamic Cohort – calculated from a definition

It would seem a user or the system could (eventually) use either/both of these types of list, so I’m not sure the names “System List” and “User List” are useful – i.e., not all user-managed lists need to be manually managed and not all system-generated lists need to be calculated (e.g., the “system” through an automated process could generate a static list).

I would suggest Cohort Type be used to distinguish between dynamic (aka calculated) vs static (aka manually managed) lists and address ownership/access separately.

@jdick

On a separate but related note, @samuel34 would like to introduce a new feature which allows one to define a set of cohorts in which a member may only be permitted membership to one. The backend would automatically remove a patient from any other lists in the same set when added to any cohort within the set. He is experimenting with using the CohortType for this and would like to add a column to the table to do so. Please see here: Comparing openmrs:master…samuelmale:cohort_types · openmrs/openmrs-module-cohort · GitHub . However, perhaps this is best achieved by a CohortAttributeType?

Complicated business rules around sets of lists sound like a specialized use case and might be better implemented on top of cohorts – e.g., allow a module to subscribe to changes on specific cohorts, which it could use to apply its business rules. Is this capability being discussed somewhere?