Modeling Groups of Patients, Group Encounters & Linking Patient Encounters to Groups

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:

  1. 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.

  2. 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.
  1. 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?

See attached group encounter form

Happy to provide more information as I keep thinking through this in a more generic manner

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.

@darius Thank you - seems like the cohort module ticks all the boxes, will start with that.

@maimoonak please do share any experiences, gotchas and planned enhancements to the module

@dkayiwa I am looking for steps on how to ensure that a module can be added to the OpenMRS BinTray as it seems openmrs-module-cohort is not there.

Is this helpful?

@dkayiwa Unfortunately not since it does not tell me what I need to publish a module to BinTray

Does that mean those steps are already done for this module?

@dkayiwa Nope these steps would happen only after the module is published to BinTray not before

Try to release and see if it does not automatically go to bintray.

Is this of help?


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).

@maimoonak Thanks

@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

I have just enabled travis for it.

Thanks @dkayiwa (good morning). Another strange thing, my tests (a dummy one does not run)

You would need to point us to the test. :slight_smile:

@dkayiwa oops I have grown sloppy :disappointed:

Your test should be in api/src/test/java/org/openmrs/module/cohort/api/

That is, move the test folder to the parent folder. Same level as “main” instead of under it

@dkayiwa I looked a that for over an hour, and failed to see it … Thanks

@ssmusoke are you aware of this CI failure?

It was reported during today’s scrum. :slight_smile:

@dkayiwa Fix is in this PR review