← Back to team overview

dhis2-users team mailing list archive

Re: Calculated variables

 

Roger,

On Wed, 27 Apr 2011 08:22:46 -0400, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rdf4@xxxxxxx> wrote:
OK, we have two more use cases of calculated variables. 

At present certain information is collected by diagnosis from the
inpatient and outpatient clinics.  The malaria information is copied
to the malaria form, along with other information which does have to
be entered.  We want to enter this information only once, from the
diagnosis records, but we want it to show up on the malaria form, we
think it's marginally acceptable to not show totals, but to not show
the malaria people "their" data is bad customer relations.

As I understand the case, this can be done by including the same data elements, like "Malaria xyz", in both data sets. This is what we did in Sierra Leone, where some forms had an data element overlap of 25%+. Data entered in for example "Malaria <1 male" in one form would then show up when you opened the data entry screen for the same month and clinic for the "twin-form". I believe the same can be done when you have calculated data elements. Making a calculated element visible in the data entry screen would be possible by assigning it to a cell in a custom form, while the sub-elements can be hidden by not assigning them. Using a standard form would all the elements visible.

The clinics keep daily logs of birth control products dispensed, for
which the patients pay at a reduced rate.  This form is turned in
along with the cash receipts, serving as a financial control.  It
needs receipts by item (quantity x price) and total.

I think it would be good enough if the calculated variables were not
stored or aggregated and only existed while the dataset form was being
displayed, for input or as a  report.  It would also be reasonable
to limit variables in the calculations to those in the dataset (so in
the malaria case, the variable would be in the dataset, it would not
appear on the form, only the calculated variable equal to its value).

Our users exist in a form-based world, where the form designers do not
necessarily think systematically. 

This is very typical, and the change from paper-logic to computer-logic is a long process. Subtotals, double entry, and huge tables are typical for paper forms. Unfortunately, since paper come in fixed sizes, they are populated so that all free space is used. Automatically populating different forms by sharing the same data elements was used in Sierra Leone as a first step to highlight the possibilities of computer-based data entry and storage, and has since led to a certain degree of harmonization of the forms.

Regards,
Johan

 Where we can make a closer
correspondence between the form and data entry/printing, we add to
their comfort with the system.  While I may think the forms they are
using are don't make informatic sense, and that differences in
rendering call for different strategies on screens than on paper, I
can't impose these changes on them.  Cross-foot totals do contribute
to accuracy in manual forms, they don't in computer forms; double
entry accounting contributes to accuracy in manual bookkeeping, it
doesn't in computer bookkeeping; but the habits of generations don't
change in a day.



References