Creating a case in one module for a different module

We are currently designing our application to have one module to register
communities (where each community is modeled as a case),and separate
’clinical’ modules for pregnancies, infants and general patient visits.

The application currently works as follows:

  • Each CHW registers each community they are responsible for using the
    ’communities’ module. Each community ‘case’ has the following properties:
    district name, community name, community code, latitude and longitude.
    This approach allows each CHW to have a ‘custom’ list of communities on
    their phones, and keeps us from needing to hard-code district/community
    lists in the application itself. It also allows us to track the approximate
    GPS location of each clinical case.
  • We have one form for each case type (ie. pregnancy, infant, general) that
    exists in the the communities module, and is used to register a new
    clinical case in any of the configured communities. Specifically, each
    form loads the community details from the selected community 'case’
    properties and copies these properties into the new clinical case
  • We have separate modules for each clinical case type, with forms specific
    to each case type (ie. pregnancy module and prenatal and postpartum forms,
    infant module had neonatal form, etc.)

The overall approach seems quite usable, and has the advantage of
immediately bringing up the case list when the pregnancy, infant or general
module is selected on the phone. (apparently the CC client works this way
when the module only includes forms that require a case).

To implement this design, I needed to hand-craft the xforms used to create
the pregnancy, infant and general cases. In particular, I needed to embed
some casexml and binds to enable the form to both load properties from the
’community’ case and create a new pregnancy case with a different case
type. This was done based on an example that Clayton showed me (thanks
Clayton).

Having thought about this a bit, I wonder if it would be generally useful
and feasible to extend CCHQ to support this use case by:
a) Allowing forms to both require and create a case (currently only
’create’ or ‘require’ is supported, but not both)
b) When ‘create case’ is selected, allowing a form to create a case with a
different case type (ie. by overriding the case type of the module)

I realize such a change may be a relatively low priority, and perhaps not
even desired, but thought I’d share the use case and potential solution to
see what others think.
(there was a somewhat related question a while ago about being able to both
create and update a case using a single form).

Cheers, Ray

Ray,

Thanks for sharing your use case! This seems pretty similar to what other
people would like to do with shared cases, it’s good to get a feel for what
people’s requirements look like.

We’re currently hard at work on a revision to the CommCare CaseXML spec
which will make using and manipulating multiple cases in single forms much
more straightforward. The current plan is for the spec and mobile
implementation to be done by the end of December, at which point we’ll
start working on improving/updating the capacities of the CommCareHQ
application builder.

We’ll keep you guys up to date with these updates, and in the mean time
it’s good to see that these applications are coming together still, even if
they take a bit of hackery.

-Clayton

··· On Wed, Nov 23, 2011 at 1:27 PM, Ray Brunsting wrote:

We are currently designing our application to have one module to register
communities (where each community is modeled as a case),and separate
’clinical’ modules for pregnancies, infants and general patient visits.

The application currently works as follows:

  • Each CHW registers each community they are responsible for using the
    ’communities’ module. Each community ‘case’ has the following properties:
    district name, community name, community code, latitude and longitude.
    This approach allows each CHW to have a ‘custom’ list of communities on
    their phones, and keeps us from needing to hard-code district/community
    lists in the application itself. It also allows us to track the approximate
    GPS location of each clinical case.
  • We have one form for each case type (ie. pregnancy, infant, general)
    that exists in the the communities module, and is used to register a new
    clinical case in any of the configured communities. Specifically, each
    form loads the community details from the selected community 'case’
    properties and copies these properties into the new clinical case
  • We have separate modules for each clinical case type, with forms
    specific to each case type (ie. pregnancy module and prenatal and
    postpartum forms, infant module had neonatal form, etc.)

The overall approach seems quite usable, and has the advantage of
immediately bringing up the case list when the pregnancy, infant or general
module is selected on the phone. (apparently the CC client works this way
when the module only includes forms that require a case).

To implement this design, I needed to hand-craft the xforms used to create
the pregnancy, infant and general cases. In particular, I needed to embed
some casexml and binds to enable the form to both load properties from the
’community’ case and create a new pregnancy case with a different case
type. This was done based on an example that Clayton showed me (thanks
Clayton).

Having thought about this a bit, I wonder if it would be generally useful
and feasible to extend CCHQ to support this use case by:
a) Allowing forms to both require and create a case (currently only
’create’ or ‘require’ is supported, but not both)
b) When ‘create case’ is selected, allowing a form to create a case with a
different case type (ie. by overriding the case type of the module)

I realize such a change may be a relatively low priority, and perhaps not
even desired, but thought I’d share the use case and potential solution to
see what others think.
(there was a somewhat related question a while ago about being able to
both create and update a case using a single form).

Cheers, Ray