search

medic / cht-core

The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
https://communityhealthtoolkit.org
GNU Affero General Public License v3.0
436 stars 204 forks source link

Support variable target goals for different CHWs / Areas etc #4771

Open SCdF opened 5 years ago

SCdF commented 5 years ago

Currently our target config looks like this:

{
  "items": [
    {
      "type": "count",
      "id": "pregnancy-registrations",
      "icon": "pregnancy-4",
      "goal": 7,
      "name": [
        {
          "locale": "en",
          "content": "Pregnancies Registered"
        }
      ]
    }]
}

etc.

There is an interest in supporting different targets (the 7 in the above example) for different regions in a configurable way.

One reasonably simple way of supporting this is modifying goal to be a list of goals attached to place _ids. When rendering the target page, work upward through the CHW's lineage and use the first one they find (ie the CHW's id, or the area id, or the branch id…), falling back on the system level default.

Three downsides:

This ticket has not been prioritised. It is a note for discussion about how we'd best achieve this when the time came to do so.

SCdF commented 5 years ago

An example, where for one CHW we want a goal of 5, for everyone under a branch we want a goal of 10, and otherwise we want a goal of 7.

{
  "items": [
    {
      "type": "count",
      "id": "pregnancy-registrations",
      "icon": "pregnancy-4",
      "goal": [{
        "for": "system",
        "goal": 7
      }, {
        "for": "a-chws-_id",
        "goal": 5
      }, {
        "for": "a-branches-_id",
        "goal": 10
      }],
      "name": [
        {
          "locale": "en",
          "content": "Pregnancies Registered"
        }
      ]
    }]
}
SCdF commented 5 years ago

Actually it's slightly easier to implement if it looks like this:

{
  "goal": {
    "system": 7,
    "a-chws-_id": 5,
    "a-branches-_id": 10
  }
}
SCdF commented 5 years ago

Basic change–ignoring moving config to a better location, fixing the edit UI that currently exists in admin (or dropping it), tests etc:

diff --git a/webapp/src/js/services/target-generator.js b/webapp/src/js/services/target-generator.js
index 8957d569c..f99a1ed20 100644
--- a/webapp/src/js/services/target-generator.js
+++ b/webapp/src/js/services/target-generator.js
@@ -73,12 +73,43 @@ var moment = require('moment'),
         target.value = calculateValue(target);
       };

+      // Correctly determine item goals based on the logged in user
+      var determineItemGoals = function(items, userContact) {
+        items.forEach(function(item) {
+          // Support both
+          //   "goal": 10
+          // or
+          //   "goal": {...}
+          if (typeof items.goal !== 'number') {
+            var contact = userContact;
+            var goal;
+
+            // Find the most specific goal for the contact
+            while (goal === undefined && contact !== undefined) {
+              goal = item.goal[contact._id];
+              contact = contact.parent;
+            }
+
+            // Or use the global system goal if there isn't one
+            if (goal === undefined) {
+              goal = goal['system'];
+            }
+
+            item.goal = goal;
+          }
+        });
+      };
+
       var init = $q.all([ Settings(), UserContact() ])
         .then(function(results) {
           var items = results[0].tasks &&
                       results[0].tasks.targets &&
                       results[0].tasks.targets.items;
+
           var userContact = results[1];
+
+          determineItemGoals(items, userContact);
+
           if (!items) {
             targets = [];
             return;
kennsippell commented 4 years ago

@SCdF As we are re-examining tasks and targets in v3.8, would you be able to share details related to the user stories that brought about this feature request? Who expressed interest in it? Or concrete examples of the targets they were trying to create?

SCdF commented 4 years ago

@kennsippell this was over a year ago, so I don't recall much more than what I've already written: target goals should be able to be different depending on the place a CHW is under. The one example I remember is that the average amount of families that CHWs take on isn't constant, and the structure of communities they care for isn't constant, so stuff like "N pregnancies registered a month" isn't a target that works globally.

I one thing I'm unsure of / have forgotten, is how static the differences would want to be. For example, is it "we have 10 regions and they all have slight variations based on regional blah", or is it "we want to be able to tweak targets per CHW at arbitrary moments" (which is obviously a very different thing).

I think Amanda Yembrick brought it up (github ain't doing autocomplete for me here), maybe chat to her?

yembrick commented 4 years ago

Good memory @SCdF ! Yep, this was me. We are (still) exploring a data science initiative with PIH in Malawi that this requirement came from. The idea is to use a number of datasources, some external to our tool, and data from the application to come up with individualized targets for a number of activities CHWs undertake, for example TB screenings. In the future, this might be all calculated in the app, but this feature request was to enable a pilot in which all calculations would be done elsewhere, and then the resulting targets entered/uploaded into the application (1-2 times in the pilot period). We do now have dedicated funding for this initiative, so its possible we want to consider an expanded scope and do this differently. The exploratory work is likely to start in January for this, and @ecsalomon is leading it.

ecsalomon commented 4 years ago

Per discussion among me, @kennsippell, @MaxDiz, and @garethbowen yesterday: The need for this is still undefined. We may choose a different approach ultimately for the intended implementation (e.g., a predictive model that targets both who to screen as well as how many to reach a specific recall target).

However, the proposed implementation here makes sense, and I believe it would be good to eventually implement it (or at least ensure that tasks and targets are compatible with it) because we know that burdens of specific conditions vary at the very least among districts. But it is not a priority for the immediate the future.

If we do go this route, I expect to know in January, and we would be looking to implement in April. Is that sufficient lead time?

garethbowen commented 4 years ago

@ecsalomon That's just enough time if everything goes well. If you can get us a decision any earlier that'd be greatly appreciated!

ecsalomon commented 4 years ago

@garethbowen Ok. Timeline isn't fully set right now, but I will keep that in mind and try to get scoping discussion to happen with more lead time before implementation. Will stay in touch about possible pathways and timelines.

kennsippell commented 4 years ago

I've seen a few more requirements in this vein from DTree and @MaxDiz. We can discuss implementation in-depth if/when this gets scheduled, but could we consider supporting a more generic mechanic like having the "goal" attribute be a function which is passed the current user (among other inputs)? This would be a more generic, more powerful, and more consistent interface to how we handle this in other areas of the config. It might also be less costly to build.

{
      "type": "count",
      "id": "pregnancy-registrations",
      "icon": "pregnancy-4",
      "goal": function(user) {
        return {
          system: 7,
          chw: 8,
          supervisor: 10,
        }[user.contact.type];
      },
      "name": [
        {
          "locale": "en",
          "content": "Pregnancies Registered"
        }
      ]
    }
MaxDiz commented 4 years ago

@kennsippell feedback from the team is supportive of moving this issue up in priority. How does it fit with the next round of task and target improvements that you're working on?

SCdF commented 4 years ago

but could we consider supporting a more generic mechanic like having the "goal" attribute be a function which is passed the current user

Sorry I missed this when you wrote it!

So, if the different goals are either very statically allocated (eg parent X means 80%, parent Y means 90%) or statically defined (eg chws with the X flag on their user record are 80%, those without are 90%, or even the % is a value on their user record) making the goal a function that takes the user context is a great idea IMO. The thing to avoid would be situations where the function itself is forced to change a lot (as it would be pushed to everyone), so idk if that covers all cases

garethbowen commented 4 years ago

I wonder if this is another thing that should be emitted from nools...

garethbowen commented 4 years ago

Bumped to 3.11 due to later project kick off.

ranjuts commented 4 years ago

@katanu @PhilipNgari @nnbhandari1 requesting your input here regarding the priority of this feature. Do we have any projects that would implement this feature if it was available now or within the next 6 months? Any specific information would be very helpful + general thoughts on user need.

katanu commented 4 years ago

I heard this request where the supervisors want to change targets for CHWs based on one or several fixed or changing metrics such as the total number of population-could be HHs served by the CHW and their catchment area- to support the pay for performance approach with DTree. They wanted these targets to either be set by the supervisor (or someone with admin rights) through the user interface (ideal) or have a way to provide for that flexibility through configuration. It is still part of the current DTree work. @ranjuts . I am not sure, about this, but I also think LG had a similar request at one time.

PhilipNgari commented 4 years ago

I see this as a request to come when you look at it from the rising need of supervisor and target setting. The targets may vary from one person to another. Not sure how immediate this Ask would be but worth exploring.

nnbhandari1 commented 4 years ago

Given the tool we are using in MoH Nepal, I am not sure if there has been a request for this in the past. However, having a reliable estimate in-terms of user goal would be very helpful.
One way to get the targets could be the HMIS data where we can get HF level projection but how that will trickle down to the FCHV level is something that is challenging.

joyannee commented 4 years ago

@kennsippell as per our discussion, here are more details on the "why" For big deployments like LG and D Tree, their CHVs work in diverse areas so you may have some in peri urban areas with relatively dense populations and others where the areas are more spread out. Ideally these areas would have different demographics. Having uniform targets in these areas isn't fair/ doesn't work very well for incentives etc.. so ideally each CHV area should have customizable targets. This would also help when the population changes or the deployment scales up. I would classify them into urban, peri urban and rural for a start with a set range of population size for example. For the goals it would depend on how many targets the deployment has but without going into the field( disclaimer) I would say you can have it set as 4 pregnancies per population size x or based on x number of HHs registered per CHV.

ecsalomon commented 4 years ago

Just to ensure we don'e make an implementation that precludes other use cases: One of the initial motivations for this issue was to support, e.g., epidemiological or machine learning models to set custom screening targets per catchment area. Inputs to such models might include:

leah-ngaari commented 4 years ago

@ranjuts As part of D-Tree's supervisor feature requests we received the following user story:- "As a supervisor, I would like to see key health indicators for my supervisory area benchmarked against my district, in order to assess the topics that my CHVs should give special focus to Display visualizations of a few key, high-level health indicators in comparison to district-level or national-level benchmarks" They are requesting for the ability of a supervisor to compare targets in his/her area with that of a peer group.

Cc @PhilipNgari @korirm @kitsao @katanu @maremegaye

PhilipNgari commented 4 years ago

Thanks team! Do we have an estimate of when this feature will be out? cc @MaxDiz

MaxDiz commented 4 years ago

Hi @PhilipNgari this issue has not been scheduled yet. It requires further scoping before it can be scheduled for development.

PhilipNgari commented 4 years ago

Hey @MaxDiz . This thread suggests to me we have numerous and somehow different Asks. I.e the PIH,Dtree and LG. Which one do we need further scoping on it so that I can rally teams for support? Most grateful. cc @ranjuts

PhilipNgari commented 4 years ago

how are we doing on this @MaxDiz on this Dtree request.

ranjuts commented 4 years ago

@MaxDiz It looks like this request could benefit from a PrO looking at requirements from across the deployments to ensure that we're covering each. I see a variety of user stories being brought forward for each kind of partner alongside the research and learning requirements. Has that already been planned by any chance? We could also have a service designer support if needed.

In terms of contractual requirements, this is not a blocker and D-Tree is aware and okay with what is coming with the first set of supervisor features but with the understanding that this is coming soon after (and despite it being a part of SOW due March 2020). This is high in the list of features that they are looking forward to as a Technical Partner and something we should deliver on in good faith.

MaxDiz commented 4 years ago

This issue has been added to 3.10 to fulfill contractual obligations. It needs additional scoping to clarify requirements from project deployment and R&L team perspectives. If ready in time, eng can pick up, but it should not be a blocker for the release.

assigning myself to continue scoping

MaxDiz commented 4 years ago

From discussion with @ecsalomon and @sacul-git , R&L minimum requirement is to create a feature MVP that does not need to be completely re-engineered to be able to incorporate:

Timeline for deployment is 6(ish) months - planned work with PIH has been delayed due to Covid redirect

MaxDiz commented 4 years ago

From discussion with @ranjuts , project implementation minimum requirement is to create a feature that incorporates the ability to:

Timing for deployment is Q3/4 2020 - feature is a contractual obligation

SCdF commented 4 years ago

@MaxDiz and I have a conversation about this from a technical perspective. I confess I don't completely understand the requirements as talked about in Max's past two comments, so @ecsalomon / @sacul-git / @ranjuts please read this comment carefully and let me know if what I'm saying is accurate. I apologise in advance for how wrong I'm about to get everything (and how long this has ended up being):

@ranjuts 's minimum requirements:

@ecsalomon and @sacul-git 's future requirements:

Right, so presuming I understand what's going on, a MVP piece of work could be:

Later on we are able to extend the goal function to also allow for passing in all contacts and reports that chw has access to (if that's what "Individualized targets for activities CHWs undertake"` means) if we need to. Since this is potentially expensive we can also detect if your function asks for those values and only pull them in if we need to.

Having this will let you have goals that are:

Does this make sense? Am I on the right track?

dianabarsan commented 4 years ago

Later on we are able to extend the goal function to also allow for passing in all contacts and reports that chw has access to ... this is potentially expensive ....

I would drop "potentially" and just say expensive. As of 3.8, we no longer hold all these records in memory and request them on a need-to-know basis.

ecsalomon commented 4 years ago

@SCdF Happy to clarify.

ranjuts commented 4 years ago

Thanks for the questions @SCdF

  • set targets at a branch level in the deployment hierarchy

    • So this is fine, though if I understand the next bullet point we'll need to modify replication so that offline users get read access to places documents that are higher than their attached place

As I'm re-reading this alongside your questions, I'm realizing this requirement is missing a few pieces. The supervisor should only be changing targets at the place that they belong to or lower (i.e. CHV area) and the ability to change targets would be needed by the user at the supervisor level or above only (so not at the CHV level).

  • manually change targets at the supervisor field level (ie not in config only)

    • I am understanding this to mean that supervisors get to personally change goals on the fly, presumably for the place that they are a supervisor of.

Yes, basically. Although it could be a potential requirement to limit how often this gets updated and whether this limit is configurable.

  • update targets without syncing to server (current timing expectation is quarterly)

    • If this means that the progress of a targets updated without a server (like it does now) then that's fine. If you mean something else I need more clarification.

This would be both the progress of targets like you state above. For setting new targets (e.g. if a Supervisor updates them for the CHV areas) I am assuming they would need to sync.

  • store historical target data for offline access for 3-months, and for server-side analytics access for a tbd amt of time (clarifying with partners)

    • I believe this is either already done or shouldn't be a problem, but regardless it sounds like a different ticket entirely (ie it's not about configurable goals, it's about target storage)

Yes, that sounds right.

dianabarsan commented 4 years ago

Does activities in this context mean reports that CHWs have created via tasks or other actions? Or does this mean reports about CHWs?

The former

Later on we are able to extend the goal function to also allow for passing in all contacts and reports that chw has access to ... this is potentially expensive ....

I was thinking about a solution for this that won't have high negative impact on device performance and I had the idea that we could use auxiliary "invisible" targets (https://github.com/medic/cht-core/issues/6211) to track metrics or markers that are relevant to other targets' goals calculations and, in the context of "goal" being a function, it would receive the "target" document as a parameter to gain access to this data.

For example: A target that should have a variable goal depending on the number of malaria cases reported in the previous month, fe: more cases results in a higher goal. Let's call this target number_of_malaria_tests. Instead of passing all reports that have been submitted to the goal function, we could have an auxiliary target that calculates the number of malaria cases reported in the last month. Let's call this target malaria_cases_last_month. The goal function of number_of_malaria_tests receives the whole target document, that will include the values for malaria_cases_last_month (pass and total) and can use that to calculate an increased goal value. We don't have to limit to a single "auxiliary"("helper"?) target. This is just a crude example.

How does this sound?

MaxDiz commented 4 years ago

Removed Blocked label - scoping to clarify requirements from project deployment and R&L team perspectives has been completed.

Bumped to v3.12 for development

ecsalomon commented 3 years ago

Was thinking about this in the context of UHC work and am curious how this would interact with aggregate targets for supervisors? If, say, each CHW has a target set based on cases observed at a facility, would it be possible for a supervisor to have an aggregate view into coverage percentage of all CHWs and drill down by CHW to see what each CHW's target is and how they are doing at meeting it? (see this doc for some brainstorming)

MaxDiz commented 3 years ago

Cleared up the ^^ question with @ecsalomon today, and we should be ok as is

benkags commented 3 years ago

The product team is trying to understand the contractual obligations and user requirements for this issue.

From conversations with teammates, it looks like this is really not contractually obliged this year. For PIH Malawi, the immediate need for this feature is for us to better support the partner in our DDI process. For DTree, it was in scope last year, was not done, is not in scope this year but we are committed to delivering. Does that sound about right? cc @korirm @MaxDiz

Secondly, in a bid to understand the requirements better, for DTree the following user story from the supervisor features requirements 2020, is what we were hoping to address with this feature(?)

As a supervisor, I would like to see key health indicators for my supervisory area benchmarked against my district, in order to assess the topics that my CHVs should give special focus to Display visualizations of a few key, high-level health indicators in comparison to district-level or national-level benchmarks

Could someone please help expound on this? Specifically, how does the partner/we hope to use variable targets to support supervisors bench-marking against their districts? More examples here are welcome cc @leah

For PIH Malawi, what I have gathered so far is that while we initially hoped to use this feature together with predictive modelling, that is likely not going to be the case in the near future. A facility integration that informs different target goals is likely what the partner will deploy in the near future. cc @ecsalomon. And this as part of a DDI process we are in the middle of (? @korir). Some documentation or more detail here will help understand the need better. For a start maybe, how will the partner use a facility integration to deploy varying targets?

leah-ngaari commented 3 years ago

@benkags D-Tree team user story was focused ability to support varying targets for different CHWs as opposed to the current design whereby all the CHVs share a “common” target for different indicators. For example targets for CHWs in area A can be different from those of CHWs in area B due to factors such as location (rural vs urban), population size(some CHWs serve more HHs than others)etc.

korirm commented 3 years ago

@benkags For D-tree, it was in the previous contract but since Supervisor app conversations were still ongoing before the release of v3.9.0 this was just factored in the current scope as enhancement to the product. Even though the issue itself was not specifically called out, It was lumped up together with other product improvement features

benkags commented 3 years ago

Thanks @leah-ngaari @korirm. Do we know if there is any preference, informed by their process perhaps, on the setting of targets would happen? For example, supervisor's ability to set the targets for the CHWs is one such option that has been mentioned in this ticket. Any idea on how frequent this would happen? And expectations that this could be done dynamically? All these are to try and bring out, if any, discussions that may have happened on how to go about it and it is ok if there is no preference.

benkags commented 3 years ago

@korirm are you able to comment on PIH Malawi?

ecsalomon commented 3 years ago

@korirm and team discussed the PiH use case and the technical requirements are quite complex (would require an entity matching service that does not currently exist) and we don't yet know about partner interest + facility consent for data use for this purpose. So this feature is unlikely to be needed prior to Q2 2020 at the earliest and we have not fully scoped out what configuration would look like.

benkags commented 3 years ago

Thanks @ecsalomon!

Did you mean Q2 2020?

ecsalomon commented 3 years ago

Q3 is more likely. And, again, there is currently no commitment to doing this work. It is in scoping.

Oh, and, yes, got the year wrong! 2021!

joyannee commented 3 years ago

Phase one- https://docs.google.com/presentation/d/1uecOMqNB8LuI1lvnvZNbRUYQHisfdR4R403PK86IeV4/edit#slide=id.gb0b92fbdd6_0_298