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. 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. Still interesting, though :) Jo
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
