I'd appreciate inputs on this use-case as I'm trying to sort out my
case-hierarchy:
I'm considering using these case types:
*Family *- surname, GPS location, household income
*Patient *(child-case of Family) - name, date of birth, medical info
We have 2 routes to sign up patients:
1. Door to door:
a) First fill out Family Profile Form
b) For family members present, fill out General Screening form
2. At a screening campaign:
a) Fill out General Screening form
Ideally I would like to have all patients of the same case type.
As I understand my Patient case can't be created without a parent Family
case.
At a Screening Campaign, there is no parent Family case already created
when creating the Patient case from the General Screening form.
Possible soluitions:
-
Use 2 different Patient case types, with only one type having an
associated parent Family case.
This means having to filter for "PatientA OR PatientB" case types in
any case lists or reports.
-
At a campaign, use the General Screening form to create a bare-minimum
Family case type that only has one or two fields filled out.
From your experience, what is the best route to go? Do you have other
better suggestions for me?
With thanks,
Andrew Cawood
Hi Andrew,
Thanks for your question!
I would definitely suggest keeping the patients from the two registration
activities as the same case type. This way they will look the same during
any follow-up activities. It is not possible to include cases from
multiple case-types in the same case list, so I would only create separate
case types if the follow-up was completely isolated for the two types of
patients.
It is also probably safest to keep the same case structure (family ->
patient) for all patients, so that you don't run into any issues of
accessing a family case that doesn't exist. I think your idea of
registering a bare minimum family case at screening campaigns sounds like a
great one. You could then have an "Edit Family" form so that your mobile
worker can fill in more details at a later date.
If you only want mobile workers to fill a single registration form at the
screening campaign, you could have a Registration form in a module of type
"family" and then register the "family" and the child "patient" at the same
time. The only downside to this strategy is that if you have multiple
people from the same family at the campaign, you would end up with separate
families for each of them. You could instead have 2 forms, a family
registration with only 1 or 2 questions and then a patient registration
form. To make the decision to have a single registration form or separate
ones for family and patient, you will need to weigh the importance for your
project of having accurate family groups to the importance of having a
streamlined registration process at the screening campaigns.
Best of luck! -Jennifer
···
On Tuesday, November 29, 2016 at 11:44:39 AM UTC+2, Andrew Cawood wrote:
>
> I'd appreciate inputs on this use-case as I'm trying to sort out my
> case-hierarchy:
>
> I'm considering using these case types:
>
> *Family *- surname, GPS location, household income
> *Patient *(child-case of Family) - name, date of birth, medical info
>
>
> We have 2 routes to sign up patients:
> *1. Door to door:*
> a) First fill out Family Profile Form
> b) For family members present, fill out General Screening form
>
> *2. At a screening campaign:*
> a) Fill out General Screening form
>
> Ideally I would like to have all patients of the same case type.
> As I understand my Patient case can't be created without a parent Family
> case.
> At a Screening Campaign, there is no parent Family case already created
> when creating the Patient case from the General Screening form.
>
> *Possible soluitions:*
> 1. Use 2 different Patient case types, with only one type having an
> associated parent Family case.
> This means having to filter for "PatientA OR PatientB" case types in
> any case lists or reports.
>
> 2. At a campaign, use the General Screening form to create a bare-minimum
> Family case type that only has one or two fields filled out.
>
>
> From your experience, what is the best route to go? Do you have other
> better suggestions for me?
>
> With thanks,
> Andrew Cawood
>
Hi Jennifer,
Thanks very much for your inputs, that helps with the decisions.
Do you have suggestions for how to deal with duplicates when they occur?
Is it "easy" (and possible) for a data administrator to change the
parent_id field to re-assign a case to a different parent case?
Is it possible to create a form for a non-technical user to merge
duplicates?
Thanks and regards,
Andrew
···
On Tuesday, 29 November 2016 12:02:29 UTC+2, jharlow wrote:
>
> Hi Andrew,
>
> Thanks for your question!
>
> I would definitely suggest keeping the patients from the two registration
> activities as the same case type. This way they will look the same during
> any follow-up activities. It is not possible to include cases from
> multiple case-types in the same case list, so I would only create separate
> case types if the follow-up was completely isolated for the two types of
> patients.
>
> It is also probably safest to keep the same case structure (family ->
> patient) for all patients, so that you don't run into any issues of
> accessing a family case that doesn't exist. I think your idea of
> registering a bare minimum family case at screening campaigns sounds like a
> great one. You could then have an "Edit Family" form so that your mobile
> worker can fill in more details at a later date.
>
> If you only want mobile workers to fill a single registration form at the
> screening campaign, you could have a Registration form in a module of type
> "family" and then register the "family" and the child "patient" at the same
> time. The only downside to this strategy is that if you have multiple
> people from the same family at the campaign, you would end up with separate
> families for each of them. You could instead have 2 forms, a family
> registration with only 1 or 2 questions and then a patient registration
> form. To make the decision to have a single registration form or separate
> ones for family and patient, you will need to weigh the importance for your
> project of having accurate family groups to the importance of having a
> streamlined registration process at the screening campaigns.
>
> Best of luck! -Jennifer
>
>
> On Tuesday, November 29, 2016 at 11:44:39 AM UTC+2, Andrew Cawood wrote:
>>
>> I'd appreciate inputs on this use-case as I'm trying to sort out my
>> case-hierarchy:
>>
>> I'm considering using these case types:
>>
>> *Family *- surname, GPS location, household income
>> *Patient *(child-case of Family) - name, date of birth, medical info
>>
>>
>> We have 2 routes to sign up patients:
>> *1. Door to door:*
>> a) First fill out Family Profile Form
>> b) For family members present, fill out General Screening form
>>
>> *2. At a screening campaign:*
>> a) Fill out General Screening form
>>
>> Ideally I would like to have all patients of the same case type.
>> As I understand my Patient case can't be created without a parent Family
>> case.
>> At a Screening Campaign, there is no parent Family case already created
>> when creating the Patient case from the General Screening form.
>>
>> *Possible soluitions:*
>> 1. Use 2 different Patient case types, with only one type having an
>> associated parent Family case.
>> This means having to filter for "PatientA OR PatientB" case types in
>> any case lists or reports.
>>
>> 2. At a campaign, use the General Screening form to create a bare-minimum
>> Family case type that only has one or two fields filled out.
>>
>>
>> From your experience, what is the best route to go? Do you have other
>> better suggestions for me?
>>
>> With thanks,
>> Andrew Cawood
>>
>
Hi Andrew,
Duplicates are definitely a concern in any mobile application that we
build, so I'm glad you're thinking about them.
Unfortunately, it is not possible to change the parent_id field to change
the parent-child relationship of a case (either on mobile or CommCareHQ).
Merging duplicates is also not easy.
The best way to deal with duplicates is to try to prevent them in the first
place. Our best tool for doing that is registration from the case list
(https://confluence.dimagi.com/display/commcarepublic/Minimize+Duplicates).
This forces the mobile worker to search for a case before being able to
register a new one. For your application, you would want them to search
for the familyfirst before registering a new family. Once they find or
create the appropriate family, you would then show the user the patients in
the family with the option to register another patient. This process
modifies my previous recommendation for what to do at screening campaigns -
I would have the family and patient registrations be separate.
Even if you do implement and train your users to prevent duplicates, there
will inevitably be ones that come through. At minimum, I would give the
mobile worker the power to close a case with the close_reason "This
patient/family is a duplicate" (this could just be added to whatever close
forms you currently have, if you have any).
If you want a more thorough elimination or merging process, you can
periodically export the case data on CommCareHQ into excel and then look
for duplicates. Sometimes searching for duplicate IDs or phone numbers is
easier than searching for duplicate names. If there are only a few to
close, you can close them on CommCareHQ by finding the appropriate case in
the Case List
(https://confluence.dimagi.com/display/commcarepublic/Data+Inspection) and
closing it. If you need to do many or want to merge cases in some way, you
would need to use the case importer to update cases
(Importing Cases Using Excel - CommCare Public - CommCare Public)
and/or close them
(Closing Cases - CommCare Public - CommCare Public). I've
done this duplicate removal process before and it's pretty painful, so
you'll have to weigh the impact vs. effort required.
I hope this is helpful.
-Jen
···
On Tuesday, November 29, 2016 at 12:22:22 PM UTC+2, Andrew Cawood wrote:
>
> Hi Jennifer,
>
> Thanks very much for your inputs, that helps with the decisions.
>
> Do you have suggestions for how to deal with duplicates when they occur?
> Is it "easy" (and possible) for a data administrator to change the
> parent_id field to re-assign a case to a different parent case?
> Is it possible to create a form for a non-technical user to merge
> duplicates?
>
> Thanks and regards,
> Andrew
>
> On Tuesday, 29 November 2016 12:02:29 UTC+2, jharlow wrote:
>>
>> Hi Andrew,
>>
>> Thanks for your question!
>>
>> I would definitely suggest keeping the patients from the two registration
>> activities as the same case type. This way they will look the same during
>> any follow-up activities. It is not possible to include cases from
>> multiple case-types in the same case list, so I would only create separate
>> case types if the follow-up was completely isolated for the two types of
>> patients.
>>
>> It is also probably safest to keep the same case structure (family ->
>> patient) for all patients, so that you don't run into any issues of
>> accessing a family case that doesn't exist. I think your idea of
>> registering a bare minimum family case at screening campaigns sounds like a
>> great one. You could then have an "Edit Family" form so that your mobile
>> worker can fill in more details at a later date.
>>
>> If you only want mobile workers to fill a single registration form at the
>> screening campaign, you could have a Registration form in a module of type
>> "family" and then register the "family" and the child "patient" at the same
>> time. The only downside to this strategy is that if you have multiple
>> people from the same family at the campaign, you would end up with separate
>> families for each of them. You could instead have 2 forms, a family
>> registration with only 1 or 2 questions and then a patient registration
>> form. To make the decision to have a single registration form or separate
>> ones for family and patient, you will need to weigh the importance for your
>> project of having accurate family groups to the importance of having a
>> streamlined registration process at the screening campaigns.
>>
>> Best of luck! -Jennifer
>>
>>
>> On Tuesday, November 29, 2016 at 11:44:39 AM UTC+2, Andrew Cawood wrote:
>>>
>>> I'd appreciate inputs on this use-case as I'm trying to sort out my
>>> case-hierarchy:
>>>
>>> I'm considering using these case types:
>>>
>>> *Family *- surname, GPS location, household income
>>> *Patient *(child-case of Family) - name, date of birth, medical info
>>>
>>>
>>> We have 2 routes to sign up patients:
>>> *1. Door to door:*
>>> a) First fill out Family Profile Form
>>> b) For family members present, fill out General Screening form
>>>
>>> *2. At a screening campaign:*
>>> a) Fill out General Screening form
>>>
>>> Ideally I would like to have all patients of the same case type.
>>> As I understand my Patient case can't be created without a parent Family
>>> case.
>>> At a Screening Campaign, there is no parent Family case already created
>>> when creating the Patient case from the General Screening form.
>>>
>>> *Possible soluitions:*
>>> 1. Use 2 different Patient case types, with only one type having an
>>> associated parent Family case.
>>> This means having to filter for "PatientA OR PatientB" case types in
>>> any case lists or reports.
>>>
>>> 2. At a campaign, use the General Screening form to create a
>>> bare-minimum Family case type that only has one or two fields filled out.
>>>
>>>
>>> From your experience, what is the best route to go? Do you have other
>>> better suggestions for me?
>>>
>>> With thanks,
>>> Andrew Cawood
>>>
>>
Hi Jen,
Thanks, great inputs - glad you pointed out that I can't re-assign to a
different parent case.
As you say, duplicates are inevitable so minimising is the way to go. I'll
also consider the actual impact of duplicates when making the final
decision on how to set this up.
Regards,
Andrew
···
On Wednesday, 30 November 2016 11:03:16 UTC+2, jharlow wrote:
>
> Hi Andrew,
>
> Duplicates are definitely a concern in any mobile application that we
> build, so I'm glad you're thinking about them.
>
> Unfortunately, it is not possible to change the parent_id field to change
> the parent-child relationship of a case (either on mobile or CommCareHQ).
> Merging duplicates is also not easy.
>
> The best way to deal with duplicates is to try to prevent them in the
> first place. Our best tool for doing that is registration from the case
> list (
> https://confluence.dimagi.com/display/commcarepublic/Minimize+Duplicates).
> This forces the mobile worker to search for a case before being able to
> register a new one. For your application, you would want them to search
> for the familyfirst before registering a new family. Once they find or
> create the appropriate family, you would then show the user the patients in
> the family with the option to register another patient. This process
> modifies my previous recommendation for what to do at screening campaigns -
> I would have the family and patient registrations be separate.
>
> Even if you do implement and train your users to prevent duplicates, there
> will inevitably be ones that come through. At minimum, I would give the
> mobile worker the power to close a case with the close_reason "This
> patient/family is a duplicate" (this could just be added to whatever close
> forms you currently have, if you have any).
>
> If you want a more thorough elimination or merging process, you can
> periodically export the case data on CommCareHQ into excel and then look
> for duplicates. Sometimes searching for duplicate IDs or phone numbers is
> easier than searching for duplicate names. If there are only a few to
> close, you can close them on CommCareHQ by finding the appropriate case in
> the Case List (
> https://confluence.dimagi.com/display/commcarepublic/Data+Inspection) and
> closing it. If you need to do many or want to merge cases in some way, you
> would need to use the case importer to update cases (
> https://confluence.dimagi.com/display/commcarepublic/Importing+Cases+Using+Excel)
> and/or close them (
> https://confluence.dimagi.com/display/commcarepublic/Closing+Cases).
> I've done this duplicate removal process before and it's pretty painful,
> so you'll have to weigh the impact vs. effort required.
>
> I hope this is helpful.
>
> -Jen
>
>
>
> On Tuesday, November 29, 2016 at 12:22:22 PM UTC+2, Andrew Cawood wrote:
>>
>> Hi Jennifer,
>>
>> Thanks very much for your inputs, that helps with the decisions.
>>
>> Do you have suggestions for how to deal with duplicates when they occur?
>> Is it "easy" (and possible) for a data administrator to change the
>> parent_id field to re-assign a case to a different parent case?
>> Is it possible to create a form for a non-technical user to merge
>> duplicates?
>>
>> Thanks and regards,
>> Andrew
>>
>> On Tuesday, 29 November 2016 12:02:29 UTC+2, jharlow wrote:
>>>
>>> Hi Andrew,
>>>
>>> Thanks for your question!
>>>
>>> I would definitely suggest keeping the patients from the two
>>> registration activities as the same case type. This way they will look the
>>> same during any follow-up activities. It is not possible to include cases
>>> from multiple case-types in the same case list, so I would only create
>>> separate case types if the follow-up was completely isolated for the two
>>> types of patients.
>>>
>>> It is also probably safest to keep the same case structure (family ->
>>> patient) for all patients, so that you don't run into any issues of
>>> accessing a family case that doesn't exist. I think your idea of
>>> registering a bare minimum family case at screening campaigns sounds like a
>>> great one. You could then have an "Edit Family" form so that your mobile
>>> worker can fill in more details at a later date.
>>>
>>> If you only want mobile workers to fill a single registration form at
>>> the screening campaign, you could have a Registration form in a module of
>>> type "family" and then register the "family" and the child "patient" at the
>>> same time. The only downside to this strategy is that if you have multiple
>>> people from the same family at the campaign, you would end up with separate
>>> families for each of them. You could instead have 2 forms, a family
>>> registration with only 1 or 2 questions and then a patient registration
>>> form. To make the decision to have a single registration form or separate
>>> ones for family and patient, you will need to weigh the importance for your
>>> project of having accurate family groups to the importance of having a
>>> streamlined registration process at the screening campaigns.
>>>
>>> Best of luck! -Jennifer
>>>
>>>
>>> On Tuesday, November 29, 2016 at 11:44:39 AM UTC+2, Andrew Cawood wrote:
>>>>
>>>> I'd appreciate inputs on this use-case as I'm trying to sort out my
>>>> case-hierarchy:
>>>>
>>>> I'm considering using these case types:
>>>>
>>>> *Family *- surname, GPS location, household income
>>>> *Patient *(child-case of Family) - name, date of birth, medical
>>>> info
>>>>
>>>>
>>>> We have 2 routes to sign up patients:
>>>> *1. Door to door:*
>>>> a) First fill out Family Profile Form
>>>> b) For family members present, fill out General Screening form
>>>>
>>>> *2. At a screening campaign:*
>>>> a) Fill out General Screening form
>>>>
>>>> Ideally I would like to have all patients of the same case type.
>>>> As I understand my Patient case can't be created without a parent
>>>> Family case.
>>>> At a Screening Campaign, there is no parent Family case already created
>>>> when creating the Patient case from the General Screening form.
>>>>
>>>> *Possible soluitions:*
>>>> 1. Use 2 different Patient case types, with only one type having an
>>>> associated parent Family case.
>>>> This means having to filter for "PatientA OR PatientB" case types
>>>> in any case lists or reports.
>>>>
>>>> 2. At a campaign, use the General Screening form to create a
>>>> bare-minimum Family case type that only has one or two fields filled out.
>>>>
>>>>
>>>> From your experience, what is the best route to go? Do you have other
>>>> better suggestions for me?
>>>>
>>>> With thanks,
>>>> Andrew Cawood
>>>>
>>>
Hi Jen,
Under *Limitations *on the *Minimize Duplicates *page it says:
···
-----------
The minimize duplicates setting cannot be used for modules that have any of
the following:
- Parent/Child Case Selection turned on.
- Menu Mode is configured as "Display module and then forms"
I'm assuming the first point refers to the *Parent Child Selection ->
Select Parent First *checkbox.
Was the "Parent/Child Case Selection" something you had in mind when you
said this:
For your application, you would want them to search for the family
first before registering a new family.
Once they find or create the appropriate family, you would then show
the user the patients in the family with the option to register another
patient.
Or is there another way to take the user from a family selection/creation
into a patient selection/creation? (Seeing as I can't use Minimize
Duplicates with this)
Thanks and regards,
Andrew
On Wednesday, 30 November 2016 11:52:51 UTC+2, Andrew Cawood wrote:
Hi Jen,
Thanks, great inputs - glad you pointed out that I can't re-assign to a
different parent case.
As you say, duplicates are inevitable so minimising is the way to go. I'll
also consider the actual impact of duplicates when making the final
decision on how to set this up.
Regards,
Andrew
On Wednesday, 30 November 2016 11:03:16 UTC+2, jharlow wrote:
Hi Andrew,
Duplicates are definitely a concern in any mobile application that we
build, so I'm glad you're thinking about them.
Unfortunately, it is not possible to change the parent_id field to change
the parent-child relationship of a case (either on mobile or CommCareHQ).
Merging duplicates is also not easy.
The best way to deal with duplicates is to try to prevent them in the
first place. Our best tool for doing that is registration from the case
list (
https://confluence.dimagi.com/display/commcarepublic/Minimize+Duplicates).
This forces the mobile worker to search for a case before being able to
register a new one. For your application, you would want them to search
for the familyfirst before registering a new family. Once they find or
create the appropriate family, you would then show the user the patients in
the family with the option to register another patient. This process
modifies my previous recommendation for what to do at screening campaigns -
I would have the family and patient registrations be separate.
Even if you do implement and train your users to prevent duplicates,
there will inevitably be ones that come through. At minimum, I would give
the mobile worker the power to close a case with the close_reason "This
patient/family is a duplicate" (this could just be added to whatever close
forms you currently have, if you have any).
If you want a more thorough elimination or merging process, you can
periodically export the case data on CommCareHQ into excel and then look
for duplicates. Sometimes searching for duplicate IDs or phone numbers is
easier than searching for duplicate names. If there are only a few to
close, you can close them on CommCareHQ by finding the appropriate case in
the Case List (
https://confluence.dimagi.com/display/commcarepublic/Data+Inspection)
and closing it. If you need to do many or want to merge cases in some way,
you would need to use the case importer to update cases (
Importing Cases Using Excel - CommCare Public - CommCare Public)
and/or close them (
Closing Cases - CommCare Public - CommCare Public).
I've done this duplicate removal process before and it's pretty painful,
so you'll have to weigh the impact vs. effort required.
I hope this is helpful.
-Jen
On Tuesday, November 29, 2016 at 12:22:22 PM UTC+2, Andrew Cawood wrote:
Hi Jennifer,
Thanks very much for your inputs, that helps with the decisions.
Do you have suggestions for how to deal with duplicates when they occur?
Is it "easy" (and possible) for a data administrator to change the
parent_id field to re-assign a case to a different parent case?
Is it possible to create a form for a non-technical user to merge
duplicates?
Thanks and regards,
Andrew
On Tuesday, 29 November 2016 12:02:29 UTC+2, jharlow wrote:
Hi Andrew,
Thanks for your question!
I would definitely suggest keeping the patients from the two
registration activities as the same case type. This way they will look the
same during any follow-up activities. It is not possible to include cases
from multiple case-types in the same case list, so I would only create
separate case types if the follow-up was completely isolated for the two
types of patients.
It is also probably safest to keep the same case structure (family ->
patient) for all patients, so that you don't run into any issues of
accessing a family case that doesn't exist. I think your idea of
registering a bare minimum family case at screening campaigns sounds like a
great one. You could then have an "Edit Family" form so that your mobile
worker can fill in more details at a later date.
If you only want mobile workers to fill a single registration form at
the screening campaign, you could have a Registration form in a module of
type "family" and then register the "family" and the child "patient" at the
same time. The only downside to this strategy is that if you have multiple
people from the same family at the campaign, you would end up with separate
families for each of them. You could instead have 2 forms, a family
registration with only 1 or 2 questions and then a patient registration
form. To make the decision to have a single registration form or separate
ones for family and patient, you will need to weigh the importance for your
project of having accurate family groups to the importance of having a
streamlined registration process at the screening campaigns.
Best of luck! -Jennifer
On Tuesday, November 29, 2016 at 11:44:39 AM UTC+2, Andrew Cawood wrote:
I'd appreciate inputs on this use-case as I'm trying to sort out my
case-hierarchy:
I'm considering using these case types:
*Family *- surname, GPS location, household income
*Patient *(child-case of Family) - name, date of birth, medical
info
We have 2 routes to sign up patients:
1. Door to door:
a) First fill out Family Profile Form
b) For family members present, fill out General Screening form
2. At a screening campaign:
a) Fill out General Screening form
Ideally I would like to have all patients of the same case type.
As I understand my Patient case can't be created without a parent
Family case.
At a Screening Campaign, there is no parent Family case already
created when creating the Patient case from the General Screening form.
Possible soluitions:
-
Use 2 different Patient case types, with only one type having an
associated parent Family case.
This means having to filter for "PatientA OR PatientB" case types
in any case lists or reports.
-
At a campaign, use the General Screening form to create a
bare-minimum Family case type that only has one or two fields filled out.
From your experience, what is the best route to go? Do you have other
better suggestions for me?
With thanks,
Andrew Cawood