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

Eric_Stephan2 · February 20, 2015, 3:05am

Hi Sheel -- thanks for the info. I think, in short, I will nee to be
mindful of open cases as I move forward.

But for now, I have one small follow-up question and then one larger
question about the structure of an application.

1-- The little follow-up question: above, when you point out that what
matters when determining how many cases get downloaded into the phone is
how many cases that USER has access to, it will download all the cases of
all types that that user has rights to, and it doesn't matter if that app
only has the ability to work with one case type. You then say "To figure
out which cases a user will get when logging in, you can use the Case List
report and filter by the user." My question is ... based on what you've
said, when I go to that Case List report and filter by user, I obviously do
not limit that report by the other options that case list report offers:
(A) I will leave that report on "Case Type = All" , correct, because of
what you've said above?
(B) However, this case list report also allows me to choose to view opened
vs. closed cases. Am I right that if cases were fully CLOSED, they would
not be synced to the phone, therefore in simulating the case load using
this report, I should set Opened/Closed to only Open?

2-- Here is my bigger question. My initial version of my HIV outreach and
referrals application, which I've been bugging you about in the thread
above, limited the scope of what CommCare would be tracking so that its
tracking halted the moment that a client successfully appeared at a clinic
to fulfill the referral they had been given by the outreach worker. In
that early version, we did *not *plan to use CommCare to continue to track
the continued engagement of people that went deeper into the clinical
system when they tested HIV Positive and therefore joined an ART program on
a fairly permanent basis and therefore came to the clinic for many visits
over time to obtain this or that treatment or service.
But, in a nutshell, I am now being told that we should extend
CommCare's tracking so that it does do that "fuller reach into tracking the
ongoing services gained through entry into the ART program."
Therefore, I have written up an initial understanding of the way that
CommCare could handle that. In fact I've built that first version and
tested it and it functions. BUT, I could imagine there could be any number
of things about the plan that might raise concerns from you experts, or
that might be less ideal about it.
So, could you look at the attached diagram, which shows the method
I've been considering? As you will see, it now has extended into three
case types. The first is for the permanent relationship with an outreach
client over time -- just meeting them in a bar or venue over time, having
screening discussions, etc. The second is for when a referral is made to a
clinic, which is then marked as "completed" if the client successfully
appears (valuable data there.) Now, the new third case type is for IF the
client tests HIV positive and therefore is enrolled in an ART program, the
third case type tracks their ongoing engagement with, and services from,
that program over time.
(A) First of all, what impressions do you have of this plan -- does it make
sense, and any problems or worries rise from it?
(B) Second, I have to admit that it feels cleaner to have broken the
ongoing-ART-program aspect out into its own third case type... BUT, I
wonder if, for the reasons of worrying less about too many open cases, that
it would be smart to combine that ART-program engagement into that second
case type, the regular "referral" case type... so that, if a person tested
HIV negative, then that case would just be closed normally, BUT if the
person tested HIV positive, you would basically keep it open indefinitely
and just start to use that "referral" case type to record the ongoing ART
program participation. Would that be better? If yes, is it emphatically
better, or just mildly?
(C) What other structure might be best for this goal?

THANKS! --Eric

Eric_Stephan2 · April 2, 2015, 9:45am

*** First off, thanks to Derek for the cases info we provided above -- I'm
slowly building an understanding on that.

*** Now I'd like to ask a new question, which is a follow-on question to
earlier feedback that you guys gave me on my new "three levels of case
types" structure for my app which now tracks these three levels: cases for
HIV outreach, cases for referrals for HIV testing, and cases for
ongoing-care-for-HIV-positive people.

If you first look at the attached diagram and ignore the purple text boxes,
it shows the basic, "normal" function of my app: (1) An outreach worker
creates and follows up on "client" cases (and in some occasions, creates a
child case of type "referral.") (2) a clinic worker opens a follow-up form
on those referral cases and in some cases the client tests HIV positive, so
it creates a child cases of the type "ART-client" so the client can be
registered for the ongoing care and ART treatment. Dimagi staff had
previously told me that that basic structure made pretty good sense (but,
of course, any additional input on that basic function is welcome.)

But, my new questions are shown in the purple text boxes on the diagram.
These boxes describe two specific situations that we anticipate will happen
sometimes, which involve a new case being created in a way other than that
"normal" scenario... and, as a result, that new case would not be assigned
to a case sharing group that contains an outreach worker... which would be
not very good, because we're eager for those newly created cases to always
have a dedicated outreach worker responsible for continuing support to that
person!

So, regarding those two "purple box" scenarios in the diagram... can you
tell me the recommended method that we would use to, later on after it was
created, access that newly made case and manually assign it to a case
sharing group (I assume) so that it's attributed to an outreach worker? I
can imagine that your reply might echo a concept that I have read about
here or there in CommCare documentation, but it's better for me to get
pointed in the right direction by you guys first.

THANKS as usual for your great help!

Eric

Sheel_Shah · February 20, 2015, 4:25pm

Hi Eric,

See my responses below:

Options in the Report Filter
That's correct, you'd want to choose the Case Type option as All and then
choose only Open cases to see what would be sent down to the phone.

Design for the Application
I think the application structure you have is correct (its how I would have
done it). Some caveats:

Having a separate ART case is the right approach. You're not reducing
the case load by re-using the referral case (since it will be closed as
soon as you create an ART case).
Ideally the ART case would be a child of the patient case, not the
referral case. You can do those by having the user fill out a form closes
the referral case. They can then fill out another form where they choose
the patient and fill out a form to enroll them in ART.
- You can also make the ART case a child of the referral - you just
  then need to be aware that to access the client case, you would
  have to use
  parent/parent/client_case_property

Thanks!
Sheel

···

On Thu, Feb 19, 2015 at 10:05 PM, Eric Stephan wrote:

Hi Sheel -- thanks for the info. I think, in short, I will nee to be
mindful of open cases as I move forward.

But for now, I have one small follow-up question and then one larger
question about the structure of an application.

1-- The little follow-up question: above, when you point out that what
matters when determining how many cases get downloaded into the phone is
how many cases that USER has access to, it will download all the cases of
all types that that user has rights to, and it doesn't matter if that app
only has the ability to work with one case type. You then say "To figure
out which cases a user will get when logging in, you can use the Case List
report and filter by the user." My question is ... based on what you've
said, when I go to that Case List report and filter by user, I obviously do
not limit that report by the other options that case list report offers:
(A) I will leave that report on "Case Type = All" , correct, because of
what you've said above?
(B) However, this case list report also allows me to choose to view
opened vs. closed cases. Am I right that if cases were fully CLOSED, they
would not be synced to the phone, therefore in simulating the case load
using this report, I should set Opened/Closed to only Open?

2-- Here is my bigger question. My initial version of my HIV outreach
and referrals application, which I've been bugging you about in the thread
above, limited the scope of what CommCare would be tracking so that its
tracking halted the moment that a client successfully appeared at a clinic
to fulfill the referral they had been given by the outreach worker. In
that early version, we did *not *plan to use CommCare to continue to
track the continued engagement of people that went deeper into the clinical
system when they tested HIV Positive and therefore joined an ART program on
a fairly permanent basis and therefore came to the clinic for many visits
over time to obtain this or that treatment or service.
But, in a nutshell, I am now being told that we should extend
CommCare's tracking so that it does do that "fuller reach into tracking the
ongoing services gained through entry into the ART program."
Therefore, I have written up an initial understanding of the way that
CommCare could handle that. In fact I've built that first version and
tested it and it functions. BUT, I could imagine there could be any number
of things about the plan that might raise concerns from you experts, or
that might be less ideal about it.
So, could you look at the attached diagram, which shows the method
I've been considering? As you will see, it now has extended into three
case types. The first is for the permanent relationship with an outreach
client over time -- just meeting them in a bar or venue over time, having
screening discussions, etc. The second is for when a referral is made to a
clinic, which is then marked as "completed" if the client successfully
appears (valuable data there.) Now, the new third case type is for IF the
client tests HIV positive and therefore is enrolled in an ART program, the
third case type tracks their ongoing engagement with, and services from,
that program over time.
(A) First of all, what impressions do you have of this plan -- does it
make sense, and any problems or worries rise from it?
(B) Second, I have to admit that it feels cleaner to have broken the
ongoing-ART-program aspect out into its own third case type... BUT, I
wonder if, for the reasons of worrying less about too many open cases, that
it would be smart to combine that ART-program engagement into that second
case type, the regular "referral" case type... so that, if a person tested
HIV negative, then that case would just be closed normally, BUT if the
person tested HIV positive, you would basically keep it open indefinitely
and just start to use that "referral" case type to record the ongoing ART
program participation. Would that be better? If yes, is it emphatically
better, or just mildly?
(C) What other structure might be best for this goal?

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

Sheel_Shah · April 6, 2015, 12:50am

Hey Eric,

Some quick thoughts:

*Parentage of ART Case: *I think you should consider whether you want to
make this a child of the referral OR the child of the original client case.
In the clinic app, you'll need to have users manually select a client
case if you want to make the ART case a child of the client (instead of
directly creating the art case when a referral related form is filled out).

(This is an important point because you ALSO want to register ART cases
directly at the client - details below).

Registering a Client or ART Case Directly at the Clinic
This is definitely possible. There are a few options:

You can directly register an ART case with all the information. This
will work, as long as you're not relying on any information on a parent
case (i.e. the referral or the client case)
You can alternatively, register a client case and then in the same
registration form, optionally create an ART case that's the client case's
child.

To assign a case registered at the clinic to a particular CHW, you can
follow the procedures listed on this page (
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups).

My general recommendation is that you setup each ART case to be
independent - that is, its not dependent on there being a parent case
that is a client or referral. That way, you can create ART cases
independently at the clinic as needed. If you have client cases being
registered at the clinic, you may want to also create a referral case at
the same time, so that when their test is complete, an ART case can be
created if needed.

Sheel

···

On Thu, Apr 2, 2015 at 5:45 AM, Eric Stephan wrote:

*** First off, thanks to Derek for the cases info we provided above -- I'm
slowly building an understanding on that.

*** Now I'd like to ask a new question, which is a follow-on question to
earlier feedback that you guys gave me on my new "three levels of case
types" structure for my app which now tracks these three levels: cases for
HIV outreach, cases for referrals for HIV testing, and cases for
ongoing-care-for-HIV-positive people.

If you first look at the attached diagram and ignore the purple text
boxes, it shows the basic, "normal" function of my app: (1) An outreach
worker creates and follows up on "client" cases (and in some occasions,
creates a child case of type "referral.") (2) a clinic worker opens a
follow-up form on those referral cases and in some cases the client tests
HIV positive, so it creates a child cases of the type "ART-client" so the
client can be registered for the ongoing care and ART treatment. Dimagi
staff had previously told me that that basic structure made pretty good
sense (but, of course, any additional input on that basic function is
welcome.)

But, my new questions are shown in the purple text boxes on the diagram.
These boxes describe two specific situations that we anticipate will happen
sometimes, which involve a new case being created in a way other than that
"normal" scenario... and, as a result, that new case would not be assigned
to a case sharing group that contains an outreach worker... which would be
not very good, because we're eager for those newly created cases to always
have a dedicated outreach worker responsible for continuing support to that
person!

So, regarding those two "purple box" scenarios in the diagram... can you
tell me the recommended method that we would use to, later on after it was
created, access that newly made case and manually assign it to a case
sharing group (I assume) so that it's attributed to an outreach worker? I
can imagine that your reply might echo a concept that I have read about
here or there in CommCare documentation, but it's better for me to get
pointed in the right direction by you guys first.

THANKS as usual for your great help!

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

Eric_Stephan2 · April 6, 2015, 10:10am

Hi Sheel -- thanks so much for your input. This is tricky stuff. I have
some first impressions (I'm guessing I will have more after your reply
also...)

-- You've mentioned the process to make the form allow the user assign the
cases to one of multiple groups. You know, giving a bit more detail about
this project, we have an interesting complication. This will be one
district in Laos, and in that district there might be five independent
outreach workers, but who do not have clear geographic regions. So,
actually, when the clinic worker does go to register a "walk-in" client, if
we did configure the feature to let them assign the case to one of multiple
groups, in truth that clinic worker would not have enough info to decide
which worker was best, at that point in time. The workers' workloads, or
other considerations, could ultimately bear on that and the clinic worker
would have no idea which one to choose...

Before I go on, note that I tend to look at my two purple-box scenarios as
both being "walk-in" situations. If every client we had always started
perfectly from the outreach worker, who then perfectly created a child-case
referral to the testing clinic, and then the testing clinic's app always
perfectly created a child-case referral to the ART program, then this
wouldn't be an issue. But it's the person that "just walks in" to that
second level (a testing clinic,) or the person that just walks in to our
third level (a ART facility), that creates this snag about "after the fact"
assigning this new record to an outreach worker that has never laid eyes on
this new person yet.

Therefore, a couple questions, none of which will fully answer my situation
but will help assemble possibilities:

(1) In addition to that feature you proposed, where a registration form
allows the choice of multiple case sharing groups, is there any other
method that would make it so that a day or two AFTER the new case was
created, a person that's administering on CommCareHQ could locate that new
case and use CommCareHQ to re-assign that case (which would be floating
free not under any given case sharing group) and manually re-assign it to
be in a given case sharing group, because she had determined that the
outreach worker named Lenny is the best suited for handling that client
case moving forward?
... This would seem to work well with a "stand alone registration form
for ART cases" that would be used when the person being registered was a
"walk-in" ...

(2) Here is a possible solution that might make sense in a couple ways, and
I'd like to know if it sounds odd to you. Imagine that there is a walk-in
to the testing clinic. For this walk-in situation, I make a registration
form that (weirdly) creates a new blank "referral" case for this person,
and it allows the same data to be collected as the referrals that are
created in the "natural" way springing from the outreach work. This
"miraculously born" new referral form for this walk-in person would even
have the ability to create a child case for the ART program if the person
did indeed test HIV positive. BUT in this walk-in referral case we put a
very clear flag into a field that shows very clearly that it was for a
WALK-IN and therefore is not associated with any CBS. NOW, to handle
this, we would make some case list somewhere that collected these walk-ins
that had happened, and the person that runs our outreach program would see
those and would give very specific directions to the most appropriate
outreach worker, saying "Hey, here is a walk-in guy that needs to be
registered as a client case -- go to this guy and do your full initial
interview with the person, and he'll be correctly existing in your case
group as he should be. The only downside is that there is that "floating"
walk-in case out there that is recording that that same person got an HIV
test with such-and-such results... and possibly even a "floating" ART case
that might have been created. One of two ways could account for that so
that out data and tallying of our cases doesn't get too screwed up. I
guess that when the outreach worker did the after the fact "real"
registration of this person that had been a walk-in, they would click a
check box flagging that that was the situation and logging key information
about whether they had been HIV positive or negative, whether they had an
ART case created, etc.
... One thing that makes this method quite appealing is that, in
truth, the only form in our project that is quite long and involved is the
first outreach client registration form. And asking a clinic person to go
through all that will result in some not-high-quality outreach being done.
So, the idea of "flagging" the person to go and get a subsequent interview
by our REAL outreach worker is very appealing.

Any thoughts on all this? I hope I'm not wandering off into truly insane or
inaccurate ideas --

Thanks!
Eric

Eric_Stephan2 · April 7, 2015, 10:32am

Hi Sheel... While I have you (I'm sorry I'm entering into another "many
questions" phase) I will raise a separate concern that I have found in the
app we've been talking about.

This is separate from the "how to handle walk-ins" that we discuss above.

This new question has to do with case sharing groups and the goal that I
described in my previous chart, where, typically, a client case creates a
referral case which creates an ART case. (Maybe some of the possibilities
we discuss above will be relevant for this issue.)

Here is the issue. As you know, even in our most normal use, if a client
shows up for his "referral" case and is HIV positive, then the system is
supposed to create a new "ART case" that will be used to track the
subsequent history of that client's activities in the ART program. But,
if you look at the attached diagram of my case sharing groups, you'll see
that that new case is being created within a zone that is in multiple case
sharing groups. This only gives two possibilities: (1) I turn off case
sharing, which I can't do because then the ART user/app won't get the new
case shared with them... or (2) I turn on case sharing, in which case the
clinic worker will have to use the method to "choose one of multiple case
sharing groups." In that case, they will simply want to automatically
choose the one that contains the outreach worker that actually created the
original client case. Is it technically possible that the app could
automatically detect who that was, and automatically choose that case
sharing group without asking the mobile user? ... perhaps by using
consistent naming of the case sharing groups? Since it seems like direct
logic to identify which one it is.

This is a good time to mention that I believe you were earlier suggesting
that ART cases could be registered "independently" rather than being
created as child case of another case. My main concern here is two things:
(1) The overall major concern of the project that I am working on is that
we are able to collect data about the "HIV Cascade," which basically means
knowing about each "successful jump" to the next level. In other words,
that we are able to collect exact numbers of how many of our outreach cases
did successfully complete the next step (completing a referral to testing)
... and how many of our HCT referrals were successfully turned into ART
cases... etc. So -- as long as we could clearly report from the data the
number of each of those successful "jumps," then I am OK with the ART reg
form being "independent." But in my mind right now, I'd like to get your
sense of that would indeed be possible with an independent form like that.
Note also that our project will indeed be using a "UIC Code" that will be
assembled for each of our "client" cases, where we will ask 5-8 questions
(like birth year, birth order within their family, gender, first initial,
last initial) and paste together the coded answers into a single string of
12-15 characters that will "quite uniquely" identify that person. That will
be useful in crunching the numbers discussed above, but I haven't practiced
that all out yet.
By the way, I admit that in earlier emails, I am a little confused when
you say that I should decide "whether I want to make the ART case be a
child of the referral OR the child of the original client case." Since
that ART case would be created by the action of a person that is filling
out a form of type "referral," wouldn't that automatically mean that it
would be a child of the Referral case? Not sure how I could have it be
created when a person clicked in a "referral case" form that the person had
tested HIV positive, but I could somehow have it be a child of the
higher-up "client" case.
Another point in our app -- our goal is that, when a person is entered as
a new ART user, that that case is indeed shared with the outreach worker.
Because the outreach worker ALSO has the job of providing help in the
"Care, Support and Treatment" phase -- staying in touch with the person,
helping them with their needs, etc.
If we find that the case sharing groups methods are just too
complicated... how normal could it be that ALL of the outreach workers in
that province are ALL in the one large case sharing group? That might
simplify things. We would have to ensure that each one know they they could
not "grab" the other workers' clients... etc. Is that ever done? Would it
create grave questions of "too many cases on the phones"? Seems like it
would be the same number of cases as the Clinic phone had.
Even stranger, I noticed that while the "referral" case must indeed be
treated as a separate case, because for one client there might be many
separate referrals, it seems like it is NOT the case that there could be
more than one "ART client" cases for a given "client" case. It is simple
one-to-one attributes of that one unique person, not some "one to many"
situation. Therefore, is there some way I could set this up so that "ART
case" is actually just elements of the original "client case?" If yes,
then a few words might help to orient my head on how that would be done...
Just one notch below confident on the best way in all this.

THANKS again, and I promise that there will be another "quiet phase" when I
don't harrass you horribly so much...

Eric

Sheel_Shah · April 7, 2015, 5:39pm

Hey Eric,

I'm going to create a separate thread with you to discuss these issues.
Please let me know if anyone would like to be included.

Sheel

···

On Tue, Apr 7, 2015 at 6:32 AM, Eric Stephan wrote:

Hi Sheel... While I have you (I'm sorry I'm entering into another "many
questions" phase) I will raise a separate concern that I have found in the
app we've been talking about.

This is separate from the "how to handle walk-ins" that we discuss above.

This new question has to do with case sharing groups and the goal that I
described in my previous chart, where, typically, a client case creates a
referral case which creates an ART case. (Maybe some of the possibilities
we discuss above will be relevant for this issue.)

Here is the issue. As you know, even in our most normal use, if a client
shows up for his "referral" case and is HIV positive, then the system is
supposed to create a new "ART case" that will be used to track the
subsequent history of that client's activities in the ART program. But,
if you look at the attached diagram of my case sharing groups, you'll see
that that new case is being created within a zone that is in multiple case
sharing groups. This only gives two possibilities: (1) I turn off case
sharing, which I can't do because then the ART user/app won't get the new
case shared with them... or (2) I turn on case sharing, in which case the
clinic worker will have to use the method to "choose one of multiple case
sharing groups." In that case, they will simply want to automatically
choose the one that contains the outreach worker that actually created the
original client case. Is it technically possible that the app could
automatically detect who that was, and automatically choose that case
sharing group without asking the mobile user? ... perhaps by using
consistent naming of the case sharing groups? Since it seems like direct
logic to identify which one it is.

This is a good time to mention that I believe you were earlier
suggesting that ART cases could be registered "independently" rather than
being created as child case of another case. My main concern here is two
things: (1) The overall major concern of the project that I am working on
is that we are able to collect data about the "HIV Cascade," which
basically means knowing about each "successful jump" to the next level. In
other words, that we are able to collect exact numbers of how many of our
outreach cases did successfully complete the next step (completing a
referral to testing) ... and how many of our HCT referrals were
successfully turned into ART cases... etc. So -- as long as we could
clearly report from the data the number of each of those successful
"jumps," then I am OK with the ART reg form being "independent." But in my
mind right now, I'd like to get your sense of that would indeed be possible
with an independent form like that.

Note also that our project will indeed be using a "UIC Code" that will
be assembled for each of our "client" cases, where we will ask 5-8
questions (like birth year, birth order within their family, gender, first
initial, last initial) and paste together the coded answers into a single
string of 12-15 characters that will "quite uniquely" identify that person.
That will be useful in crunching the numbers discussed above, but I haven't
practiced that all out yet.

By the way, I admit that in earlier emails, I am a little confused when
you say that I should decide "whether I want to make the ART case be a
child of the referral OR the child of the original client case." Since
that ART case would be created by the action of a person that is filling
out a form of type "referral," wouldn't that automatically mean that it
would be a child of the Referral case? Not sure how I could have it be
created when a person clicked in a "referral case" form that the person had
tested HIV positive, but I could somehow have it be a child of the
higher-up "client" case.

Another point in our app -- our goal is that, when a person is entered
as a new ART user, that that case is indeed shared with the outreach
worker. Because the outreach worker ALSO has the job of providing help in
the "Care, Support and Treatment" phase -- staying in touch with the
person, helping them with their needs, etc.

If we find that the case sharing groups methods are just too
complicated... how normal could it be that ALL of the outreach workers in
that province are ALL in the one large case sharing group? That might
simplify things. We would have to ensure that each one know they they could
not "grab" the other workers' clients... etc. Is that ever done? Would it
create grave questions of "too many cases on the phones"? Seems like it
would be the same number of cases as the Clinic phone had.

Even stranger, I noticed that while the "referral" case must indeed be
treated as a separate case, because for one client there might be many
separate referrals, it seems like it is NOT the case that there could be
more than one "ART client" cases for a given "client" case. It is simple
one-to-one attributes of that one unique person, not some "one to many"
situation. Therefore, is there some way I could set this up so that "ART
case" is actually just elements of the original "client case?" If yes,
then a few words might help to orient my head on how that would be done...
Just one notch below confident on the best way in all this.

THANKS again, and I promise that there will be another "quiet phase" when
I don't harrass you horribly so 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