dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

It seems to me we are missing a level of grouping.  We need to group
dataelements which have similar dimensionality (presumably using a DataSet)
and we also need to group the dataelements which might appear on a form.
The two are not necessarily the same.

Do we need a FormData abstraction which perhaps contains a set of DataSets?
I suspect this is tyhe right way to go.

On XForms I don't believe it is a silver bullet regarding form design.  The
same issues will be present regarding composing the FormData..  Of course
what is really nice is the way that this process is decoupled from the
rendering of forms which is XForms outstanding merit.  What it would also
allow (by representing form instance data as xml) is a way to make use of a
common data entry point into the application via dxf - it could be
transparent whether data comes off a form or an import process or an SMS -
it would always arrive at the application in through the same route.  I
think there is much to be said for this but also some caveats.

Regards
Bob

2009/10/25 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>

> I agree with Ola completely.. We had discussed this in South Africa and the
> main reason why xforms can make life easier in this case is because we can
> have bindings to anything. The UI/layout is separate from the data binding
> part and that can be any data element, part of one dataset, different
> datasets... or even OpenMRS database for that matter...
>
> One single form for patient data (diarrhea case), household data (unclean
> water), village data (water table with lead) and facility data (total number
> of diarrhea cases.. from automatic from reporting aggregation)
>
> ---
> Regards,
> Saptarshi PURKAYASTHA
> Director R & D, HISP India
> Health Information Systems Programme
>
> My Tech Blog:  http://sunnytalkstech.blogspot.com
> You Live by CHOICE, Not by CHANCE
>
>
> 2009/10/25 Ola Hodne Titlestad <olatitle@xxxxxxxxx>
>
> Hi,
>>
>> Since Abyot brought up redesign of how we do forms I would like to use
>> this opportunity to discuss some ideas I have been playing around with
>> lately.*
>>
>> General comment on redesign of data entry forms*
>> I'd like to see data entry forms more decoupled from data sets in general.
>> There are many use cases where you would like to be able to use multiple
>> datasets in one form, e.g. a form with multiple tables (multiple dimension
>> sets or categorycombos). Moving towards a more clearly defined dimensional
>> structure of our data, and towards supporting dimensional data exports to
>> formats like SDMX it seems we need to restrict the use of dimensions in
>> datasets to ONE dimensionset (categorycombo) per dataset. A paper form
>> typically has more than one dimensionset, e.g. with EPI, ANC and nutrition
>> in the same RCH form. With the use of multiple datasets in one form we could
>> easily generate the form by generating one table for each dimensionset, and
>> not like today where we need to design a custom form in the FcK Editor to
>> support mulitple dimensionsets (tables) in one form (although we actually
>> have the autogenerate table functionality in place).
>>
>> Another reason for more decoupling between datasets and forms would be to
>> be able to to "visual" edits to the datasets, meaning edit how they appear
>> in a form. Often some of the fields in a tabular form needs to be disabled
>> or grey'd out in the entry form, e.g. to be able to block certain
>> combinations of data elements and categoryoptions in the form, like
>> "Neonatal death >5 years" or Pregnancy Male <5 or some other combination
>> that does not make sense. I would like to be able to do this without having
>> to design the whole form in a custom designer, but simply use a automatic
>> table generator for each dataset and then through the GUI disable some of
>> the fields in those generated tables. We could also add some heading fields
>> etc. between the tables to organise the form better. The idea is to as far
>> as possible be able to use auto generated tables in the data entry forms
>> instead of having to go trough the tedious process in the FCK editor for
>> custom forms. Having some visualisation properties for each dataset/table in
>> the form, would allow for this I guess.
>>
>> From a GUI perspective I would like to see data entry forms as a separate
>> menu item in Data Elements and Indicators "module" and not as one of many
>> operations on dta sets like it is today.
>>
>> On the more extreme such a decoupling would also allow for combining data
>> sets that are very different in one form, e.g. patient data, household data
>> and facility data in the same form, when that is necessary. From what I have
>> heard the use of xforms would make such a scenario easier, is that right?
>> *
>>
>>
>> Comment on patient/community data entry forms*
>> Wouldn't it be easier for the patient/community module if we somehow could
>> reuse the concept of datasets? I mean since you would need data sets for
>> data entry and import/export, and probably other exisiting DHIS
>> functionality, it seems there is a lot to gain by doing this. If not
>> possible, then why don't we expand the data set model to cater for the needs
>> of patient data, so that all dataset dependent functionality could be reused
>> in the community system? Is this not possible?
>>
>> Ola
>> ------------
>>
>>
>> 2009/10/24 Abyot Gizaw <abyota@xxxxxxxxx>
>>
>>>  Hi dears,
>>>
>>> I just want to make a suggestions to changes in the model have for
>>> DataEntryForm.
>>>
>>> What we have currently is a DataEntryForm *has DataSet and this
>>> restricts custom forms to be used only by datasets. In my case I also want
>>> to have custom forms for encounters or specific program visits (program
>>> stages). So I am suggesting for*
>>>
>>> *Currently*
>>> DataEntryForm(id,name,htmlCode,dataSet)
>>>
>>> *New proposal*
>>> DataEntryForm(id,name,htmlCode)
>>> DataSet(......,dataEntryForm)
>>> ProgramStage(.....,dataEntryForm)
>>>
>>>
>>> your comments ...
>>>
>>> Thank you
>>> Abyot.
>>> *
>>> *
>>> *
>>> *
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>