dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Thu, Dec 10, 2009 at 7:02 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> 2009/12/10 Ola Hodne Titlestad <olatitle@xxxxxxxxx>
>
>> Hi,
>>
>> After some more testing of data set, data set section and data entry forms
>> and Bob's more relaxed attitude on sdmx vs DHIS models I am a bit more
>> positive and have some suggestions (from an implementer's perspective) on
>> short and long term improvements to data sets and forms.
>>
>> *Some general thought on this:
>> ** For the time being the data set sections seem like a suitable object
>> were we can group data elements that belong to the same catcombo, for use in
>> data entry forms, and for data export purposes. They play the role of form
>> sections.
>>
>> * I managed to create a dataset with mutliple catcombos, put these in
>> separate sections, and then designed a custom form for data entry that
>> included multiple tables/catcombos. I can even combine multiple combos into
>> one monster table if I like, it's all flexible down to the "data element +
>> catoptioncombo" level. So for entering in custom forms and storing
>> dimensional data the current model seem to work ok (not thinking of sdmx).
>> *
>> Some short term improvements (by early January latest to support new forms
>> for next year):
>> *
>> * Right now the data set sections are not supported in the default data
>> entry forms, which means you have to design custom forms to make use of
>> them. This should be fixed as it should be possible to have default forms
>> with more than 1 catcombo/table. A simple version would be to list these
>> tables 1 by 1, under each other with a table heading taken from the data set
>> section label property (which already exists for some reason).
>>
>> * (Bob's) Sections on a form should have the constraint that they only
>> allow dataelements of similar dimensionality. (Ola's): Right now there is no
>> such constraint. If not, it will all be chaos in default tabular forms and
>> messy for sdmx I assume.
>>
>> * When creating a new dataset with data elements from different catcombos
>> the data set sections should automatically be created, one per catcombo and
>> data elements allocated to these sections.
>>
>> * Same as above for data set reports (forms with data for any level and
>> period), so that these static reports look exactly like the forms.
>>
>> *Long term (3-4 months maybe?):
>> ** Find a better name for data set section, possibly remodel a dataset,
>> form, data value set model (to cater for data entry in default and custom
>> mode, import/export dhis2dhis, and reporting via sdmx)
>>
>> * It should be possible to make minor adjustments to what the default data
>> entry forms look like (not completely custom form). Default data entry form
>> view properties should include things like adding headings to each table
>> (catcombo), selecting which fields to grey out (make inactive), freely
>> select whether to put data element or catoptions on columns/rows (pivot the
>> table). In a more advanced version (>3 months) even be able to position
>> these tables on a screen grid e.g. 3x3 or 2x2, like the drag and drop portal
>> stuff that's around, e.g iGoogle.
>>
>> * Data set reports should make use of the view properties to default forms
>> (the previous point) so that they look exactly like the forms
>>
>> * Even more flexible data entry forms with multiple orgunits or periods
>> and possibility to pivot these around in a table
>>
>> * It should be possible to create forms that combine data for a facility,
>> a household and a patient/client. Saptarshi had some ideas on how Xforms
>> might support that.
>>
>
> I didn't get to that discussion with Saptarshi in Cape Town but an
> important point underlying this is that XForms has an instance model to
> represent the form data which can be more flexible and forms-oriented than
> the underlying persistence model.
>

I hope the good work that Abyot and Saptarshi are currently doing on the
community module is done with the whole system in mind - it seems natural to
me that most of the data entry form functionality should be common. And
ideally we could take lessons and libraries from what OpenMRS and OpenXData
are doing with xforms (purcforms).

Knut


>
> Bob
>
>
>>
>>