dhis2-devs team mailing list archive

[Johan Ivar Sæbø <johansa@xxxxxxxxxx>]

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.