We are looking at implementing Differentiated Service Delivery Models (DSDM) for HIV Service delivery, where clients do not need to come to the facility for every refill but join groups which are assessed together.
I looking for some information on how to design the following:
DSDM Models - there are 4 different models, so I think I will leverage programs to capture these to enable analysis of the groups & patients in each model at a point in time.
Groups
can this be leveraged via the Cohorts & Cohort membership - I think that I may need to extend the model to include the additional columns that I have. Does the cohort have attributes that can be leveraged instead?
A patient can be enrolled in a group for a period of time, then leave it later, then return. Is this supported by the Cohort membership?
Any chance that there can be a hierarchy of programs (say sub-programs) so that instead of using Cohorts, I can use the child programs as my groups. The programs already have enrollment, and exits so I can leverage these.
Group Encounters -
The drug refills are done at a group level, so we shall have capture group level encounters
Also how do we link the patient level encounters for refills to a group so that analysis can be done both at a group & individual level. How has this been approached?
Cohorts don’t have attributes now, but this would be a welcome addition.
Since platform 2.1, CohortMembership support this.
Programs don’t support this now. You could make a case for it.
If in real life a group is a sub-program (e.g. there are few) you would probably want to pursue this route. If a group is more like a treatment group (and there are many) then cohorts make more sense.
The cohort module adds support for group-level encounters. I believe this is actively used in OpenSRP, so is production-tested. @maimoonak can comment on this.
That said, it may not be in your best interest to approach “group encounters” in a generic way if this is your only use case for it. An alternative would be to add something like a group_drug_dispensing_encounter table where you capture the group-level data about this, but you’d actually store the patient-level data in an obs group, which includes a complex obs that uses its complex value to store a reference to the group_drug_dispensing_encounter.
Yeah, seems like cohort module fits this usecase. The module has tested and working services, API (for capturing patient and cohort encounters), and REST services as well. The UI on top of this was developed later on and might require tweaks for your usecase. However, you have option to build an OWA for this for fully customized UI. Here is the list of issues we identified during our QA (Some improvements to REST were also planned).
@dkayiwa Looks like I do not have permission to add the module to travls, and I am trying to release using Bamboo, as that is better in the long haul - I have struggled with mvn release in the past