dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 23 May 2010 11:23, Jo Størset <storset@xxxxxxxxx> wrote:
>
> Den 23. mai 2010 kl. 09.36 skrev Ola Hodne Titlestad:
>>
>> What is  the implication?  At design time, when you are coding the
>> expression, you probably should not include the categoryoptioncombo at
>> all.  The indicator is just expressed in terms of dataelements (I
>> guess traditional DHIS14 style).  But when you are generating for
>> example, the reporttable, the first pass analyzes the data you have
>> selected and suggests - would you like the indicator data
>> disaggregated by sex? Or age+sex?  Or no disaggregation.  So what you
>> can report on is determined by the data you've got.  I think that's a
>> sound principle.
>>
> I can see a few challenges with this principle. In typical implementations
> of DHIS you would design forms and canned/fixed reports at the same time
> before rolling out the installations. If it is impossible to design reports
> before you have any data values I can see a problem with this approach. But
> I guess you would know, from the forms information the potential
> datavaluesets and therefore could allow some disaggregated reports to be
> prepared even before you have any data values?
>
> I'm not sure I see the "principled" difference here. Changing the workflow
> to require categoryoptioncombo specification at report generation time
> sounds interesting, but, as Ola says, you would not want to require human
> interaction for every report generation.

Agreed.

>So then we end up with more a case
> of workflow changes and storing the same information in a different way?
> This could give more automated support for doing reporting that today is
> hard to manage manually, but would also give a more complex data model and
> workflow to keep track of.

Yes you might be right.  I am trying to resolve one complex model with
another and factor the differences.  In the process exposing some
alternatives to the way we do things.  And I think some gaps - which
largely have to do with keeping track of data and metadata changes.
Will try and sift some of this once I'm done with mapping our
datamodel to the sdmx one.

Regards
Bob



> Still interesting, though :)
> Jo