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
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?
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
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
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
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
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?
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
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.
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
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?
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
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.
Makes sense. Actually the DataSet holds information about PeriodType, assigned OrganisationUnits and locking which should be equal for all the sub-elements. So we need a sub-element which has a DimensionSet and a set of DataElements. Maybe Form and FormSection.
On XForms I don’t believe it is a silver bullet regarding form design. The same issues will be present regarding composing the FormData…
Agreed. And even if we have the mozilla xforms project I don’t think any browser natively supports xforms yet?
Not sure exactly how it will affect your design suggestions, but I would like to see the forms to be as flexible as possible, mainly concerned with presentation and not so much with the underlying data. E.g it would be great if we could start to support multiple orgunits and/or periods in our data entry forms. No need to restrict a form instance to use only one orgunit and one period. Data values saved in a form will have those restrictions of course, but being able to compose forms that combine different sources and periods makes a lot of sense, e.g. when registering one or a few data elements (e.g. population data) for many orgunits, or when a community health worker needs to manage facility, household and patient/client data at the same time.
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.
Makes sense. Actually the DataSet holds information about PeriodType, assigned OrganisationUnits and locking which should be equal for all the sub-elements. So we need a sub-element which has a DimensionSet and a set of DataElements. Maybe Form and FormSection.
On XForms I don’t believe it is a silver bullet regarding form design. The same issues will be present regarding composing the FormData…
Agreed. And even if we have the mozilla xforms project I don’t think any browser natively supports xforms yet?
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.
Makes sense. Actually the DataSet holds information about PeriodType, assigned OrganisationUnits and locking which should be equal for all the sub-elements. So we need a sub-element which has a DimensionSet and a set of DataElements. Maybe Form and FormSection.
Not sure exactly how it will affect your design suggestions, but I would like to see the forms to be as flexible as possible, mainly concerned with presentation and not so much with the underlying data. E.g it would be great if we could start to support multiple orgunits and/or periods in our data entry forms. No need to restrict a form instance to use only one orgunit and one period. Data values saved in a form will have those restrictions of course, but being able to compose forms that combine different sources and periods makes a lot of sense, e.g. when registering one or a few data elements (e.g. population data) for many orgunits, or when a community health worker needs to manage facility, household and patient/client data at the same time.
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.
Makes sense. Actually the DataSet holds information about PeriodType, assigned OrganisationUnits and locking which should be equal for all the sub-elements. So we need a sub-element which has a DimensionSet and a set of DataElements. Maybe Form and FormSection.
Not sure exactly how it will affect your design suggestions, but I would like to see the forms to be as flexible as possible, mainly concerned with presentation and not so much with the underlying data. E.g it would be great if we could start to support multiple orgunits and/or periods in our data entry forms. No need to restrict a form instance to use only one orgunit and one period. Data values saved in a form will have those restrictions of course, but being able to compose forms that combine different sources and periods makes a lot of sense, e.g. when registering one or a few data elements (e.g. population data) for many orgunits, or when a community health worker needs to manage facility, household and patient/client data at the same time.
OK but this increases complexity exponentially…
We have indeed erred on the side of too much flexibility earlier, which costs a lot (e.g. the hyperflexible periods and period aggregation, the use of source etc), and introducing unneeded generality goes against agile principles.
Still, I do agree with Ola on the need for alternative input mechanisms, a bit like the Openhealth functional prototype was able to generate different input grids based on the cube structure and user preferences (e.g. one facility or all facilities in a province). But let us not try to be too ambitious here, though it is hard to find the right balance.
I see that. Still, I think we should consider how can we try to make our model (and cross cutting functions that goes with data registration e.g. min/max, validation) support various ways of registering data in electronic forms. I am not saying that we need to put all this functionality into one data entry module, but through the model open up for other ways of doing data entry that are not necessarily defined within the boundaries of 1 orgunit, 1 period, multiple data elements, and 1 dimension set.
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.
Makes sense. Actually the DataSet holds information about PeriodType, assigned OrganisationUnits and locking which should be equal for all the sub-elements. So we need a sub-element which has a DimensionSet and a set of DataElements. Maybe Form and FormSection.
Not sure exactly how it will affect your design suggestions, but I would like to see the forms to be as flexible as possible, mainly concerned with presentation and not so much with the underlying data. E.g it would be great if we could start to support multiple orgunits and/or periods in our data entry forms. No need to restrict a form instance to use only one orgunit and one period. Data values saved in a form will have those restrictions of course, but being able to compose forms that combine different sources and periods makes a lot of sense, e.g. when registering one or a few data elements (e.g. population data) for many orgunits, or when a community health worker needs to manage facility, household and patient/client data at the same time.
Fortunately that’s not really the problem anymore. This is what is really great about Daniel’s implementation. The xforms are rendered using javascript so there is no need for “native” browser support. My point is that we still don’t escape from the problem of deciding on how to group the elements which are to be included in the form.
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.
Makes sense. Actually the DataSet holds information about PeriodType, assigned OrganisationUnits and locking which should be equal for all the sub-elements. So we need a sub-element which has a DimensionSet and a set of DataElements. Maybe Form and FormSection.
On XForms I don’t believe it is a silver bullet regarding form design. The same issues will be present regarding composing the FormData…
Agreed. And even if we have the mozilla xforms project I don’t think any browser natively supports xforms yet?