dhis2-devs team mailing list archive

[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
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>