Expanded Cohorts Module

Software Add-on Modules
1

I am working on an Expanded Cohorts module, which would provide a third implementation of cohorts - besides static and dynamic cohorts provide by cohort builder and reporting modules respectively.

See brief description below.

Is there anyone working on similar project, has seen it before, or has any comments?

I welcome any feedback.

Thanks!

-Simon Savai

Background Description

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.

Cohort Builder The Cohort Builder allows definition of cohort criteria, which it uses to query the database to produce a patient list, which then can be stored as a cohort. This transaction updates cohort and cohort_member tables in database. Limitation for cohort builder :

  • It is static - the cohort list remains the same.
  • Whenever a cohort is re-run, it is saved as a new cohort (with new cohort id) in database.
  • The criteria used is not saved alongside a cohort

Reporting module The reporting module is used to generate a dynamic cohort list. Limitation for report definition:

  • It does not update cohort_member table in database, but exports the list as a report

  • It is dynamic, such that for a patient who no longer meets criteria at the time of rerunning a cohort, this member would not be part of resulting cohort list.

Expanded cohort An expanded cohort would be a third option for cohorts that enables adding new cohort members who meet criteria WITHOUT removing those who no longer meet the same criteria. Every time the cohort is re-run, the cohort_member table is updated to include new members.

Proposed module

A proposed implementation of expanded cohorts will provide a way for users to decide which type of list they need, i.e choose between static, dynamic or expanded. It would include a scheduler task that uses stored cohort definition to generate additional patient list and update cohort_member table in database.

The initial version would:-

  • Introduce a new database table for storing cohort criteria. This will have three key columns, namely
  • cohort_id : This is a foreign key to the cohort tablet
  • cohort_criteria: a text field that stores an sql script defining the cohort
  • last_run_date: Date when cohort was last generated
  • Provide a simple interface with a text field to input/update cohort definition in sql for a selected cohort
  • Create a scheduler task that runs through the database table to retrieve cohort id and sql cohort definition for every record, generate cohort list and update cohort_member
1 Like
2

@mssavai I suppose this is intended to keep track of all members who have ever belonged to a particular cohort over time.

Possible challenges/issues

  1. Since you are only keeping track of last_run_date at any point in time you can always know the members who have ever qualified to belong to a particular cohort. But how do you tell whether a member still belongs to that cohort without having to rerun the query and compare the results?

  2. Since some apps expects a particular cohort to be a set of patients who qualify to be included at a particular point in time, it is possible these apps may not be able to function properly when run against a table that aggregate the members over time.