dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

On Sun, Oct 25, 2009 at 2:18 PM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>wrote:

> 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?*
> *


Have no idea about xforms .... but agree that it would be nice if we could
link custom forms with group of dataelements not datasets.


> *
>
> 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?
>

Reusing datasets in community systems, I don't think that is the
easiest/cleanest thing to do. Because the closest the concept of datasets
could come in community system is program. But again the whole link with
patients/individuals and having set of visits or stages will complicate
things. Infact initially dataset was treated as an encounter or program
stage form ... but again extending it with attribtues such as due date,
stage(for example 1st or 2nd or 3rd in ANC and in other similar tracking
programs....) will complicate things....... you can have a look to the model
of the community system from

http://docs.google.com/Doc?docid=0AfhDQuGFI-A_ZGNjNW1waHhfOWc0eGh2cGht&hl=en

Abyot.



>
> 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
>>
>>
>