dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

Hi,

Although it is probably not the time for further shaking up the code
suggestions I would like to throw out some ideas for future improvements in
relation to data sets and forms.

The data set and data entry form has been tied together in a 1-1
relationship for a long time both 1.4 and 2 yes, and that is a good argument
for keeping it that way.

However, with more or and more complex data entry scenarios being requested,
and with more flexible tools to design data entry forms available the
underlying requirements are also changing. There is also an argument for
clearer separation of how we organise data elements in the model and how we
present/view them when entering data.

With the multidimensionality of data elements we have a logical grouping of
data elements sharing the same categorycombo (dimensionset), and right now
there is no way to do/enforce this directly (as Lars mentions). What I am
proposing is to decouple data set and data entry forms and allow multiple
data sets to be part of a data entry form. Multidimensional data sets can be
viewed as tables in a form, and most paper forms have multiple tables with
different columns. By allowing multiple data sets in a form we could have
auto-generated forms with multiple tables in them, one for each dataset,
without having to do teh custom design as we have to today. Another more
complex data entry form, which Saptarshi and I came across when we were
brainstorming use cases for a community and household system is a form that
combines data about a client (patient) and data about a house. Basically
data belonging to different sources in the same form, which makes perfect
sense to the person registering the data. This was further strengthened by
the idea of using xforms (see Bob's post to the list some weeks back) as a
more flexible form designer tools, and then link the form to multiple data
sets.

Another reason for keeping data sets as smaller and more coherent groupings
of data elements is related to exporting data to other systems using a more
typical multidimensional model, like the SDMX-HD. Then you have to group
data by their dimensionality, and a data set with restriction to have only
one categorycombo would meet that need.

I know the data set section is there, but I think that rather complicated
than simplifies this picture. We could keep it down to having only data
entry forms and data sets if we decouple them a bit, and allow multiple
datasets to be part of one form.


Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@xxxxxxx|Tel:
+41 788216897
Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.


2009/9/30 Lars Helge Øverland <larshelge@xxxxxxxxx>

>
>
> 2009/9/30 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>
>> Hi Lars
>>
>> Does this confirm then that a DataSet is meant to be the set of elements
>> which make up a particular entry screen?  So we need something else to
>> describe dataelements with the same dimensionality which form part of the
>> dataset.
>>
>> Perhaps we call it a DataSubSet?  Restriction being that DataSets are a
>> superset of DataSubSet and that DataSubSet has only elements of the same
>> dimensionality.
>>
>> Regards
>> Bob
>
>
>
> At least the DataSet object has been and is representing a data entry form
> in both DHIS  2 and 1.4. We actually have a Section object in the
> API (org.hisp.dhis.dataset) which represents a subset of a DataSet, but the
> single dimensionality is not enforced.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>
>