Hello,
we are going to make section in implementer-interface as add-more. The add-more feature is available only for obsControl and ObsGroupContnrol.
Approach:
- Each section will have a control id and addMore property
- Store all the parent sections ids in form_namespace_and_path of obs table so that it used to distinguish which observation should render in which section.
Eg: Suppose there is a section(control id is 1) marked as addMore and an obsControl(control id 2) inside that section. Observations are saved into form_namespace_and_path of obs table like this.
FormName.Version/1-0/2-0, FormName.Version/1-1/2-0, etc
We had a discussion with @angshuonline around this and we see other controls rendering(code) will be affected since form_namespace_and_path is updated to store section ids also(currently its is FormName.Version/2-0).
This is the only approach we can think of and we would like to hear any other approaches/suggestions.
@angshuonline, @dimitar
I have a question regarding the data structure when the form will be submitted.
Lets say I want a grouping to show something like complaints which is combined of the following elements.
I want multiple such complain groups to be captured through a form.
(e.g. Fever for 5 days, Rash for 2 days)
As you suggested, I can put that under a section and enable properties “add more”.
How will the data be stored? A Section does not have grouping in the obs table. All the inner element data are stored directly without any parent obsgroup reference.
- For reporting purpose, the grouping is important. I am assuming that while programatically this maybe possible (e.g. a display control) by processing the “form_namespace_and_path” element, but doing that from SQL would be extremely tough.
- I am not sure if the obs model allows that (maybe it does) - i.e. at the same level, multiple obs for the same concept and encounter. (attn: @darius, @burke, @dkayiwa)
- As per the scenario as shown in the image below
the observations can be grouped like this, say Symptoms(section) control id is 1, Conmplain control id is 2 and Duration control id is 3.
- Disease.1/1-0/2-0
- Disease.1/1-0/3-0
- Disease.1/1-1/2-0
- Disease.1/1-1/3-0
- Yes, SQL string processing required for grouping in reporting.
@angshuonline How about restricting section add-more to only 2 or 3 levels? This will reduce the complexity of string processing in SQL since the maximum length of “form_namespace_and_path” won’t be more than the length of Disease.1/1-0/2-0/3-0
Hi,
We have also thought about storing form_namespace_path into a separate table to limit the string processing in SQL by limiting nested sections to some number, say 3
Approach:
- A new table will be created like this where obs_id is foreign_key to obs_id in obs table.
- For an obs control which is nested in two sections, the data stored in the table will be like this instead of Disease.1/1-0/2-0/3-0
where obs_id is foreign_key in obs_table.
After brainstorming around this we found, this change will have a huge impact on bahmni. So we are going with the first approach i.e. storing all parent section control ids in form_namespace_path.
How would you support backward compatibility for older forms designed?
- in terms of data already captured
- in terms of form definitions that already exist (like no ID or addMore property for section in the older form definitions)
Hi Angshu,
Thank you for raising about it. We thought like no one is using form-builder.
To support backward compatibility, we are going to do the slightly modified version of the same approach.
-
form_namespace_and_path won’t be disturbed until it is(or any parent section) add-more. It means the data will be stored in the database in the same way how it has been storing. It automatically gives us the backward compatibility for the existing data.
- Based on addMore property availability and it’s status we can render the observations in both the ways.
