For referrals from an outreach worker to a clinic, opening a child case into a different app

Users
21

Big thanks for these responses (Sheel and also Jeremy), this helps so much.
I'll probably have more questions later but this helps...

For now, just a couple fast notes to point out how silly 2 of my questions
were:

-- My question 5 (how to get the user's userID to appear in each row of
data) was clearly foolish -- it's already there by default. :slight_smile:

-- Also, I had found that one of my phone number fields was only allowing 9
digits... but I then realized that field was not designated as Phone
Number type but rather as integer. Whoops...

Thanks again -- I'll try out the methods in both of your replies. --Eric

22

Here is another question. Just a pretty obvious clarification about the
working of case sharing groups...

-- Of course, my app is composed of outreach workers that interview clients
with the outreach reg. and outreach follow-up forms. And of course in some
circumstances, a referral is created using a child case and case sharing
groups.

-- What if we were hoping that it would be possible for the outreach worker
named John to create a new outreach case about the client named Zack....
but then, that it would also be possible for a second outreach worker
(named Jerry) to also be able to meet that same Zack client and add an
additional follow-up form for his outreach case, and potentially create a
new referral also?
If both of these workers were indeed sending their referral cases to
the same clinic, I believe this would make sense if both John and Jerry
(and maybe even a few other outreach workers that refer their clients to
that same clinic) were all in one single large case sharing group. Each of
them is in one and only one case sharing group... so there is no ambiguity
about what group the child cases get put into... It would just mean that
the case lists that each person would see would be much longer, right?
Because they would see all the group's cases there available for issuing
follow-ups on?
Is that a workable and fairly normal method? No worries created by
that? I got my head so used to these little "just one outreach worker"
groups that I forgot if groups could allow for many workers that could grab
each other's cases and issue follow-ups and referrals for also.

Thanks
Eric

23

Sorry, the more I look at this, it seems obvious that that is the normal intended use of a case sharing group. :grinning:

24

Hey Eric!

Yup, that's the standard use case for a case sharing group. Let me know if
you have trouble setting it up.

Thanks,
Sheel

··· On Thu, Nov 13, 2014 at 5:51 AM, Eric Stephan wrote:

Sorry, the more I look at this, it seems obvious that that is the normal
intended use of a case sharing group. :grinning:

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

25

Hello folks --

I now have reached the level where I've got a clearer picture of our needs
regarding the case sharing groups in the application that I have been
discussing above, and they do wind up running into a bit of a problem with
regards to the "If a user needs to create new cases, they must be in one
and only one case sharing group." I'll describe two aspects below and maybe
you can tell me your recommendations.

-- As mentioned before, we have peer outreach workers that interview many
people about their health and behavior. In their commcare "Outreach" app,
these outreach workers create new cases of type Client, and use case
management when they re-engage with a given client over time.

-- When the client proves to a need to be referred to a clinic, then that
outreach app winds up creating new child cases of type Referral.

-- We use case sharing groups so that those Referral cases can then be
accessed on a separate "Clinic" app that sits on the phone of the staff
within a clinic. So our planned groups scheme will be like that "flower
petal" method where there are many groups with just two members: One
outreach worker (who is out in the end of the petal and in no other groups)
and one clinic worker (who is at the hub of the flower and is actually
simultaneously in many different two-person groups.)

-- Tricky issue #1: I have found that those of our outreach workers that
are associated with a certain organization will need their referrals to
appear on the phones of not one but in fact two clinics, because the client
will need to have the ability to go to either of the two clinics that
organization runs. **** I think that this in itself is not a major issue,
but maybe you can confirm that to me... I believe it's not an issue in
itself because we can simply put two clinic users in each of the sharing
groups... so each of the groups will actually have three members: One
outreach worker that creates the referrals, and then the two clinic users
(and those two clinic users will be in that hub role where they are
simultaneously in many other groups.)

-- Tricky issue #2: It turns out that we do actually want those clinic
users, in that hub position, to be able to create new cases by themselves
also. (That's of course the problem.) This is because we realized that
they needed to enter the drop-in clients that came into the clinic without
some peer educator having referred them and having created a case for them.
But of course I know the problem is that if you are in more than one
sharing group (as these clinic workers will be), they can't create new
cases of type Referral, because the system would need to know which of
their many case sharing groups to assign that case to. For the record, we
would probably be OK if that walk-in case created by the clinic worker was
in no sharing group, because there is no outreach worker that will have a
need to access that case. (it would be nice if both of those two clinics
in that hub zone could see that newly created walk-in 'referral' case,
possibly, but that may not be important.)
... So, do you have any advice for how I can still allow those clinic
workers, that are in multiple sharing groups, to create new cases? Ideally
the "which group should it go into" question is moot, because the outreach
guys won't need to know about those walk-in cases...

Any tips on these? Huge thanks!

Eric

26

Hi Eric,

Thanks for your questions!

Issue #1: Yup, you're right. You can just add both clinic users to the
case sharing groups and the referral cases will appear on both clinic
users' tablets. However, you'll need to make sure that both users
regularly sync so that referrals followed up by one user are removed from
the other's device.

Issue #2: That's a bit trickier to handle. If the clinics are creating
new cases, you can have them create cases of type "Client" and assign them
to the appropriate outreach worker using the functionality described here (
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups).
Alternatively, if you have Case Sharing OFF for your clinic application,
any newly created cases will automatically just be created for the clinic
worker and not shared.

Thanks!
Sheel

··· On Tue, Nov 25, 2014 at 9:25 PM, Eric Stephan wrote:

Hello folks --

I now have reached the level where I've got a clearer picture of our needs
regarding the case sharing groups in the application that I have been
discussing above, and they do wind up running into a bit of a problem with
regards to the "If a user needs to create new cases, they must be in one
and only one case sharing group." I'll describe two aspects below and maybe
you can tell me your recommendations.

-- As mentioned before, we have peer outreach workers that interview many
people about their health and behavior. In their commcare "Outreach" app,
these outreach workers create new cases of type Client, and use case
management when they re-engage with a given client over time.

-- When the client proves to a need to be referred to a clinic, then that
outreach app winds up creating new child cases of type Referral.

-- We use case sharing groups so that those Referral cases can then be
accessed on a separate "Clinic" app that sits on the phone of the staff
within a clinic. So our planned groups scheme will be like that "flower
petal" method where there are many groups with just two members: One
outreach worker (who is out in the end of the petal and in no other groups)
and one clinic worker (who is at the hub of the flower and is actually
simultaneously in many different two-person groups.)

-- Tricky issue #1: I have found that those of our outreach workers that
are associated with a certain organization will need their referrals to
appear on the phones of not one but in fact two clinics, because the client
will need to have the ability to go to either of the two clinics that
organization runs. **** I think that this in itself is not a major issue,
but maybe you can confirm that to me... I believe it's not an issue in
itself because we can simply put two clinic users in each of the sharing
groups... so each of the groups will actually have three members: One
outreach worker that creates the referrals, and then the two clinic users
(and those two clinic users will be in that hub role where they are
simultaneously in many other groups.)

-- Tricky issue #2: It turns out that we do actually want those clinic
users, in that hub position, to be able to create new cases by themselves
also. (That's of course the problem.) This is because we realized that
they needed to enter the drop-in clients that came into the clinic without
some peer educator having referred them and having created a case for them.
But of course I know the problem is that if you are in more than one
sharing group (as these clinic workers will be), they can't create new
cases of type Referral, because the system would need to know which of
their many case sharing groups to assign that case to. For the record, we
would probably be OK if that walk-in case created by the clinic worker was
in no sharing group, because there is no outreach worker that will have a
need to access that case. (it would be nice if both of those two clinics
in that hub zone could see that newly created walk-in 'referral' case,
possibly, but that may not be important.)
... So, do you have any advice for how I can still allow those clinic
workers, that are in multiple sharing groups, to create new cases? Ideally
the "which group should it go into" question is moot, because the outreach
guys won't need to know about those walk-in cases...

Any tips on these? Huge thanks!

Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

27

Hi Sheel -- I have finally found time to work on this issue again.

Thanks much for your input above about my need to make it so that *clinic *workers,
who will be in multiple sharing groups, still also have the ability to
create a NEW case in those certain occasions when a client walks directly
into the clinic (as opposed to the majority of times when clients are
referred by outreach workers using the Outreach app.)

In your reply to that issue -- called "Issue #2" above -- you gave two
possible approaches: One, I could adjust XML to implement the "assigning
cases to one of multiple groups" method, or two, I could simply turn Case
Sharing to OFF for the clinic application, which would allow the clinic
worker to create new cases but those created by the clinic worker would not
be shared at all, only usable by them only.

Here are three questions.

(1) I am most interested in the second method above, as you described it
yourself: "Alternatively, if you have Case Sharing OFF for your clinic
application, any newly created cases will automatically just be created for
the clinic worker and not shared." This seems like it would be OK because
as I mentioned, cases that get created right in the clinic don't need to be
visible by any of the outreach workers. But I am a little bit unclear on
this approach. You are saying that I would turn off case sharing for the
entire Clinic application, which will still spend much of its time being on
the receiving end of child-case referrals created by the outreach workers
over in the Outreach app, that arrive at the Clinic app by means of case
sharing. So -- wouldn't turning off case sharing for the Clinic app
interfere or block the inward case sharing flow that will be very important
for much of its work? Or are you saying that for those referrals from the
outreach workers in the outreach app to work OK, case sharing only needs to
be turned on over in the Outreach app because it is only the "creating" app
that matters if you want cases to be shared?

(2) My next two questions are related to the more complex method described
at the help page you pointed out, where I adjust the XML to assign to one
of the case sharing groups. First question on that: When I read those
instructions, in the numbered steps, item 1 is "turn case sharing OFF."
Naturally, I assume that they obviously mean "turn case sharing off for
the [clinic] application, not in all applications in the project and also
not turning off case sharing for the groups that are assigned. Is that
right?

(3) I think in those instructions, they never tell you to turn case sharing
back ON again when one is done with the tinkering they describe. Is that
true? that method involves turning off case sharing for the clinic app
totally? If yes, then can you confirm that it would remain ON for the
other application (Outreach) and also in the case sharing groups that I set
up to handle the referrals that will still be coming in from peer educators?

Thanks much!

Eric

28

Hey Eric,

See my response below:

Case Sharing Settings For App
Yup, you're correct - turning on Case Sharing really makes the most
difference when the application is creating cases. This will cause
created cases to be assigned to a case sharing group instead of directly to
a mobile worker. However, if the mobile worker in a case sharing group
logs into another application in the same project, they'll still see the
cases assigned to the case sharing group, even if case sharing is off.

Assigning Cases to Case Sharing Group (Complex Method)
Those instructions are a bit out of date - you don't need to turn off case
sharing for the Clinic application. However, the app will show an error if
hte user is in more than one case sharing group and you don't follow the
instructions to allow the mobile worker to choose the case sharing group in
the form.

Generally, turning on case sharing just forces CommCare to assign newly
created cases to the mobile worker's case sharing group instead of directly
to the mobile worker. If the user is in more than one case sharing group,
then you need to follow the complex method (Assigning Cases to a Case
Sharing Group) I linked to. So I would figure out which applications need
case sharing functionality for created cases and only turn it on for them.

Sheel

··· On Tue, Dec 30, 2014 at 3:20 AM, Eric Stephan wrote:

Hi Sheel -- I have finally found time to work on this issue again.

Thanks much for your input above about my need to make it so that
*clinic *workers, who will be in multiple sharing groups, still also have
the ability to create a NEW case in those certain occasions when a client
walks directly into the clinic (as opposed to the majority of times when
clients are referred by outreach workers using the Outreach app.)

In your reply to that issue -- called "Issue #2" above -- you gave two
possible approaches: One, I could adjust XML to implement the "assigning
cases to one of multiple groups" method, or two, I could simply turn Case
Sharing to OFF for the clinic application, which would allow the clinic
worker to create new cases but those created by the clinic worker would not
be shared at all, only usable by them only.

Here are three questions.

(1) I am most interested in the second method above, as you described it
yourself: "Alternatively, if you have Case Sharing OFF for your clinic
application, any newly created cases will automatically just be created for
the clinic worker and not shared." This seems like it would be OK
because as I mentioned, cases that get created right in the clinic don't
need to be visible by any of the outreach workers. But I am a little bit
unclear on this approach. You are saying that I would turn off case
sharing for the entire Clinic application, which will still spend much of
its time being on the receiving end of child-case referrals created by the
outreach workers over in the Outreach app, that arrive at the Clinic app by
means of case sharing. So -- wouldn't turning off case sharing for the
Clinic app interfere or block the inward case sharing flow that will be
very important for much of its work? Or are you saying that for those
referrals from the outreach workers in the outreach app to work OK, case
sharing only needs to be turned on over in the Outreach app because it is
only the "creating" app that matters if you want cases to be shared?

(2) My next two questions are related to the more complex method described
at the help page you pointed out, where I adjust the XML to assign to one
of the case sharing groups. First question on that: When I read those
instructions, in the numbered steps, item 1 is "turn case sharing OFF."
Naturally, I assume that they obviously mean "turn case sharing off for
the [clinic] application, not in all applications in the project and also
not turning off case sharing for the groups that are assigned. Is that
right?

(3) I think in those instructions, they never tell you to turn case
sharing back ON again when one is done with the tinkering they describe. Is
that true? that method involves turning off case sharing for the clinic
app totally? If yes, then can you confirm that it would remain ON for the
other application (Outreach) and also in the case sharing groups that I set
up to handle the referrals that will still be coming in from peer educators?

Thanks much!

Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

29

Hi Sheel --

Thanks much for the info... the solution above, where I simply have case
sharing turned off for the clinical app, seems to work just fine.

Here's a new question in this epic thread about my outreach and referral
app.

We are happy that the app will of course not only collect the data related
to the outreach interactions that the outreach workers do, but will also
track the success rate of the various referrals. Our current plan is that
the referral case will be closed when the referred client arrives at the
clinic, thus signaling that they showed up and tallying it as a success.
(If there are better methods, or issues with that method, let me know.)

However we were also wondering the best way to make it so that the outreach
workers would be able to peek into the success and status of the referrals
that they had made. Naturally, getting a nice clear view of that status
will be important to them as they carry out their duties and decide to keep
after someone that hasn't fulfilled the referral.

I realized that one possible answer to getting that kind of info about the
status of the referrals is, in fact, that "dummy" form that I was forced to
place into a separate module in the Outreach app, in order for it to allow
me to create a case of a different Case Type (referral instead of client)
in the case of referrals. I put that dummy form into a separate module
that was configured to deal with case type referral, and I gave that module
the name of simply "-" since it served no purpose. BUT, now I see that
venturing into that form will cause the case list to appear for Referral,
which at least gives the outreach worker the ability to know if one of the
referrals they've made has been closed or not.

  • Is using that form the most normal way to give information to the
    outreach worker about the referrals' progress?
  • Is there some other method that might be better or different, in order
    to get that kind of info to the outreach worker?
  • There is no way to provide some kind of actual tally or aggregate
    listing of the number of completed or non-completed referrals, is there? I
    know that's pretty pie in the sky.
  • Is there anything I should know about the possibility of creating an
    info page, with simple commands, as the only item inside that
    form, which would then somehow remind the outreach worker about other
    variables about that referral, to refresh their memory?
  • If I did that, what would happen if the outreach worker looked at that
    info page, but then swiped past it and closed the form, thus submitting
    info? Would that be a problem?
  • Any other risks or caveats pop to mind?

Thanks much for your thoughts on this. As usual, I feel like some of this
is likely obvious basic use of the tool... but there's no accounting for
the way the information eventually sinks into my head --

Eric

30

Hi Eric,

Thanks for the great question. The way that I've seen this referral
success pattern (also called a counter-referral) handled is by not
closing the
referral case in the clinic application. You'll then need to add
filtering in your clinic and regular application to show the correct
referrals in each.

Here's what you'd need to setup:

  • Add a case property to your referral case called referral_completed or
    something
  • In your clinic application, add a Case List Filter
    https://confluence.dimagi.com/display/commcarepublic/Case+List+and+Case+Detail+Configuration#CaseListandCaseDetailConfiguration-FilteringtheCaseList
    so
    that it only shows cases where referral_completed != 'yes'
  • In your clinic application, make sure the referral case is not being
    closed and that when a referral is completed, you instead set the case
    property *referral_completed *to 'yes'
  • In your normal application, add a module for referrals and set the
    case list filter so that it only shows cases where referral_completed =
    'yes'
  • You can then have a form in your normal application that allows the
    user to review the completed referral (information can be in the case
    detail screen or within the form using s). This form will then
    close the referral.

I think that addresses your concerns and questions at the end of your mail,
but let me know if anything is unclear!

Thanks,
Sheel

··· On Thu, Jan 15, 2015 at 3:29 AM, Eric Stephan wrote:

Hi Sheel --

Thanks much for the info... the solution above, where I simply have case
sharing turned off for the clinical app, seems to work just fine.

Here's a new question in this epic thread about my outreach and referral
app.

We are happy that the app will of course not only collect the data related
to the outreach interactions that the outreach workers do, but will also
track the success rate of the various referrals. Our current plan is that
the referral case will be closed when the referred client arrives at the
clinic, thus signaling that they showed up and tallying it as a success.
(If there are better methods, or issues with that method, let me know.)

However we were also wondering the best way to make it so that the
outreach workers would be able to peek into the success and status of the
referrals that they had made. Naturally, getting a nice clear view of that
status will be important to them as they carry out their duties and decide
to keep after someone that hasn't fulfilled the referral.

I realized that one possible answer to getting that kind of info about the
status of the referrals is, in fact, that "dummy" form that I was forced to
place into a separate module in the Outreach app, in order for it to allow
me to create a case of a different Case Type (referral instead of client)
in the case of referrals. I put that dummy form into a separate module
that was configured to deal with case type referral, and I gave that module
the name of simply "-" since it served no purpose. BUT, now I see that
venturing into that form will cause the case list to appear for Referral,
which at least gives the outreach worker the ability to know if one of the
referrals they've made has been closed or not.

  • Is using that form the most normal way to give information to the
    outreach worker about the referrals' progress?
  • Is there some other method that might be better or different, in
    order to get that kind of info to the outreach worker?
  • There is no way to provide some kind of actual tally or aggregate
    listing of the number of completed or non-completed referrals, is there? I
    know that's pretty pie in the sky.
  • Is there anything I should know about the possibility of creating an
    info page, with simple commands, as the only item inside that
    form, which would then somehow remind the outreach worker about other
    variables about that referral, to refresh their memory?
  • If I did that, what would happen if the outreach worker looked at
    that info page, but then swiped past it and closed the form, thus
    submitting info? Would that be a problem?
  • Any other risks or caveats pop to mind?

Thanks much for your thoughts on this. As usual, I feel like some of this
is likely obvious basic use of the tool... but there's no accounting for
the way the information eventually sinks into my head --

Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

31

Hi Sheel -- Thanks as usual for the great info above about setting up the
method where you don't close cases, but rather keep them alive and instead
use a case property to tag them as completed or not. That actually feels
more comfortable to me.

Two questions:

1-- About the method discussed above, where I don't close cases but just
tag them as "closed" with a case property -- would there be anything bad
about me leaving them open quite a long time? perhaps only closing cases
after more than a year had passed (i.e. after certain M&E reports had been
written) etc? Or would the accumulation of lots of open cases, although
hidden from view owing to the filtering case lists, cause something to bog
down in the app?

2-- And this second question is totally unrelated. Its answer may be
obvious but I'm a bit slammed and didn't see it right away in the
documentation. This question is about Web users and the ability to give
some web users the ability to only see data related to some mobile users
(or groups of mobile users) and not others..
Imagine that my project, which is doing outreach work related to HIV,
actually has outreach workers from three different local organizations. so,
for example, maybe 10 mobile users are from local organization A, 10 from
local org B, and 10 from local org C.
Now, I want to give the manager staff at those three local
organizations web user logins so they can review data and also see data
about worker performance. But they don't feel comfortable with a web user
from local org. B being able to see data and stats from the other two
orgs...
So, a few questions:
(A) Is it possible to configure the web users so that the view of the
outreach *DATA *that they have is only limited to that collected by certain
mobile users (namely, the ones from their own org?)
(B) Is it possible to configure the web users so that the view of the mobile
user stats... forms submission duration, time, etc... is similarly
segmented to only show those certain users?

Thanks much!
Eric

32

Hey Eric,

Keeping Cases Open
This will cause any syncs for users who have those cases to take longer and
longer, so its not recommended. Extremely large case lists make also take
longer to display on the mobile (even with filtering).

Web User Data Access Restrictions To Specific Groups
Its not currently possible to segment the data that web users can see to
specific groups or certain users. You can limit the type of data (a web
user can see certain reports vs. other types of reports). However,
segmenting the data to specific users or groups is something that you
should definitely suggest on our Uservoice site (dimagi.uservoice.com).

Sheel

··· On Sun, Feb 8, 2015 at 11:28 PM, Eric Stephan wrote:

Hi Sheel -- Thanks as usual for the great info above about setting up the
method where you don't close cases, but rather keep them alive and instead
use a case property to tag them as completed or not. That actually feels
more comfortable to me.

Two questions:

1-- About the method discussed above, where I don't close cases but
just tag them as "closed" with a case property -- would there be anything
bad about me leaving them open quite a long time? perhaps only closing
cases after more than a year had passed (i.e. after certain M&E reports had
been written) etc? Or would the accumulation of lots of open cases,
although hidden from view owing to the filtering case lists, cause
something to bog down in the app?

2-- And this second question is totally unrelated. Its answer may be
obvious but I'm a bit slammed and didn't see it right away in the
documentation. This question is about Web users and the ability to give
some web users the ability to only see data related to some mobile users
(or groups of mobile users) and not others..
Imagine that my project, which is doing outreach work related to HIV,
actually has outreach workers from three different local organizations. so,
for example, maybe 10 mobile users are from local organization A, 10 from
local org B, and 10 from local org C.
Now, I want to give the manager staff at those three local
organizations web user logins so they can review data and also see data
about worker performance. But they don't feel comfortable with a web user
from local org. B being able to see data and stats from the other two
orgs...
So, a few questions:
(A) Is it possible to configure the web users so that the view of the
outreach *DATA *that they have is only limited to that collected by
certain mobile users (namely, the ones from their own org?)
(B) Is it possible to configure the web users so that the view of the mobile
user stats... forms submission duration, time, etc... is similarly
segmented to only show those certain users?

Thanks much!
Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

33

Hi Sheel --

Hmm, it's smart for me to investigate this "don't keep cases open" question
more, because the application I have built has an element that will
maintain a case for all of the people that our outreach workers reach out
to on an ongoing basis. For instance, our outreach worker, john, goes out
on his job to do HIV outreach. He meets a cleint, named fred, for the first
time and interviews them about their habits, and the form determines that
no clinic referral is needed for fred, based on his answers. However, two
months later, john goes out on his rounds and runs into Fred again, and
wants to do another outreach interview that will add another form to his
case. so he finds Fred's case in the case list and fills out another
outreach form. Hey, this time, fred's answers indicate that he should get a
clinic referral because it's been too long since he's gotten an HIV test.
So, a child case called "referral" is created. Later on, that child case
referral will be dealt with and closed, definitely.

However, of course, for the outreach clients themselves, we are of course
leaving those open, so that we can find Fred again, and other clients
again, and attach the new data to them.

So, how many of these "always open client cases" would be too many?

Eric

34

Hey Eric,

There's not a hard answer on how many open client cases is too many. As
you have more and more cases on your phone, you'll notice that:

  • Loading a list of cases will take longer and longer (and that's also
    affected by how fast the phone is). I've had reasonable results with a
    case list of 500+ cases, but that was on a Nexus 5.
  • Syncing will take longer - this is both a factor how long it takes us
    to compute the case list to send down to a phone and just how much data
    you're downloading. As your number of cases grows, you may start to notice
    timeout areas (your sync will fail but if you try again, will start to
    succeed)

I've had reasonable performance with case lists of around 1500 cases, but I
definitely recommend testing it out (potentially using the case importer to
generate a lot of representative cases).

Regards,
Sheel

··· On Thu, Feb 12, 2015 at 8:28 PM, Eric Stephan wrote:

Hi Sheel --

Hmm, it's smart for me to investigate this "don't keep cases open"
question more, because the application I have built has an element that
will maintain a case for all of the people that our outreach workers reach
out to on an ongoing basis. For instance, our outreach worker, john, goes
out on his job to do HIV outreach. He meets a cleint, named fred, for the
first time and interviews them about their habits, and the form determines
that no clinic referral is needed for fred, based on his answers. However,
two months later, john goes out on his rounds and runs into Fred again, and
wants to do another outreach interview that will add another form to his
case. so he finds Fred's case in the case list and fills out another
outreach form. Hey, this time, fred's answers indicate that he should get a
clinic referral because it's been too long since he's gotten an HIV test.
So, a child case called "referral" is created. Later on, that child case
referral will be dealt with and closed, definitely.

However, of course, for the outreach clients themselves, we are of course
leaving those open, so that we can find Fred again, and other clients
again, and attach the new data to them.

So, how many of these "always open client cases" would be too many?

Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

35

Thanks much for this info about "how many open cases is too many." I am
starting to test this. To begin with, I succeeded in creating 400 open
cases (for our basic outreach clients, who will remain open indefinitely.)
I will keep working with that testing.

But, can you tell me:

-- Am I right that if I had a very large number of open CLIENT cases...
like 1500 or something... but one of my apps (the clinic one) actually has
the job of only loading REFERRAL cases... then naturally that clinic phone
would not be affected by the large number of cases, right?

-- Also, let's say that I have 1500 client cases overall... but of course
those client cases are owned by a variety of case sharing groups. For the
sake of understanding, let's imagine that 1450 of those cases are in case
sharing group A, and the remaining 50 cases are in case sharing group B.
Am I right that if I am logged into the client outreach app, but I am
logged in as a user that is in group B and not A, then that person's phone
will not be subject to the possible sluggishness, since their phone never
synced the large number of cases? (This is different from the "filtering
won't influence this" comment that you made earlier.) In other words,
would the concern be that a given PHONE had a lot of cases loaded onto
it... not that the overall case type had many records on it within the
cloud database?

Thanks!
Eric

36

Hi Sheel -- I am shifting my mind back to this question of how many open
cases we can hope to maintain on a phone --

I am looking at your comment above and realizing that I'm not 100% clear on
what you said about 500 cases, relative to your later comment about 1500
cases... you said:

  • Loading a list of cases will take longer and longer (and that's also
    affected by how fast the phone is). I've had reasonable results with a
    case list of 500+ cases, but that was on a Nexus 5.

... and then a little later you commented that:

  • I've had reasonable performance with case lists of around 1500
    cases, but I definitely recommend testing it out (potentially using the
    case importer to generate a lot of representative cases).

-- So I was wondering... was there some difference in the examples that you
gave with your experiences with 500 cases and then 1500 cases? (In
general, of course, I am eager to gain optimism from your
reasonable-performance-with-1500 example! )

-- And I did indeed create 400 test cases and load them into a phone... but
deep down I am wondering if my fake-test-cases wasn't doing a greet job of
really modeling the strain on the phone -- for example, they all listed in
the long case list, but among those fake cases, very few had been opened,
followed up on, etc... so, perhaps in "real use," the strain on the phone
will be more.

Eric

37

P.S. My apologies that that question is sort of common-sense and I am
suspecting that I know the answer. But it's good for me to change all the
"I'm pretty sure that"s into things that I definitely know. --Eric

38

Sorry, here is a related question to go along with the one above about "big
numbers of open cases." I bet this question is super common.

One one of our case types is our first candidate for "worrying about how
many cases," and that's our referral-to-clinic-from-outreach worker.

My question: Naturally, over time, many of those referral cases will not
get closed because the client will simply not show up and the referral case
will just sit there. Therefore, more and more cases of this type will
accumulate in the system.

What is the most efficient, commonsense way for us (or the system) to
periodically apply a rule that says "considering all of the referral cases
sitting un-closed in the system, take all of those that are greater than 5
months old and force-close them?" Would that be an administrative task
applied every once in a while by the admin... and if so, what is the rough
method I'd apply? Or could that
apply-number-of-months-criteria-and-closing be automated?

THANKS! --Eric

39

Hey Eric,

Sending Only Referral Cases
CommCare won't distinguish to download only specific types of cases to the
phone - when a mobile user is logging in, we download all the cases for
that user, irrespective of which case types the application uses. As long
as the user logging into the clinic app only has access to referral cases,
then we'll only send those (even if there are a large number of other
cases). To figure out which cases a user will get when logging in, you can
use the Case List report and filter by the user.

Case Sharing
You're right - just because a project has a lot of cases, it doesn't mean
that syncing or the phone will be slow. The number that matters is the
number of cases that a given user has access to (based on which case
sharing groups they are in).

Thanks!
Sheel

··· On Wed, Feb 18, 2015 at 12:30 AM, Eric Stephan wrote:

P.S. My apologies that that question is sort of common-sense and I am
suspecting that I know the answer. But it's good for me to change all the
"I'm pretty sure that"s into things that I definitely know. --Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sheel Shah
Project Manager | Dimagi
m: +1.781.428.5419 | skype: sheel_shah

40

Hi Eric,
Some more details on performance with large numbers of open cases on a
phone. This creates two problems:

  1. slow performance loading the case list
  2. slow sync with server

The phone is great at filtering cases for a case list based on case type or
based on parent-child case relationships. For example, if you have 500
mothers with 10 children each, the case list for the mothers can load in a
reasonable amount of time. Displaying a mother's 10 child cases should be
even faster. However, showing all children would take an order of magnitude
more time.

Case list load time is negatively affected by how much case data gets
displayed on the case list or used in sorting. Additional filtering based
on case properties will also negatively affect how long it takes to load a
case list. Basically, you want the smallest number of case properties to be
accessed when building the case list as is possible, if performance is your
primary concern.

In general, our recommendation is to test out your particular scenario with
cases created using the case import. Your test seems appropriate; there's
no reason to expect worse performance under "real" use.

The sync time with the server is affected by the total number of cases on
the phone. The first sync may time out; subsequent syncs should succeed. To
understand what's happening, the server is calculating what needs to be
sent to the phone during the first sync request and will cache it for
subsequent requests even if the first sync times out. There's ongoing work
to improve this experience.

··· -- On your question of closing old cases, some projects will train their users to periodically go through their case lists and manually close referrals that did not show up. Other projects perform this action manually on the server side. This can be done either through the case importer or through the case list. Finally, if you have software developers available, you could write a script that periodically closes these cases using our API access. Using the case importer is likely the fastest.

On Thu, Mar 26, 2015 at 6:33 AM, Eric Stephan estephan@fhi360.org wrote:

Sorry, here is a related question to go along with the one above about
"big numbers of open cases." I bet this question is super common.

One one of our case types is our first candidate for "worrying about how
many cases," and that's our referral-to-clinic-from-outreach worker.

My question: Naturally, over time, many of those referral cases will not
get closed because the client will simply not show up and the referral case
will just sit there. Therefore, more and more cases of this type will
accumulate in the system.

What is the most efficient, commonsense way for us (or the system) to
periodically apply a rule that says "considering all of the referral cases
sitting un-closed in the system, take all of those that are greater than 5
months old and force-close them?" Would that be an administrative task
applied every once in a while by the admin... and if so, what is the rough
method I'd apply? Or could that
apply-number-of-months-criteria-and-closing be automated?

THANKS! --Eric

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.