dhis2-devs team mailing list archive

["Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rdf4@xxxxxxx>]

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.

 

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.  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.