Fixed Intake Form - can be filled only once (e.g. Diabetes)
Iterative Intake form - edit & refill an intake form (e.g Multiple instances of TB)
Followup/Progress form
Forms are currently displayed in Bahmni under clinical→patient consultation→ history & observations tab
Screenshot
Form should consist of not just simple observations, but also of other clinical aspects like diagnoses, chief complaints, symptoms, orders (lab or radiology) etc
Form builder shall be the tool using which the implementers shall design the forms for each implementation. The current processes will be changed in that there will not be a compulsory need to create a "concept set" and adding the set to a "concept set of sets" Also the current process of creating a JSON configuration to control the behaviour of concepts could be handled through the form builder.
Sample mock up:
To reduce the technical know how dependency required for the implementers currently to configure forms in Bahmni.
Reduce the start up time for forms set up during each implementation.
Remove the current dependency for every form or section within the form to be a concept set. Instead allowing the implementers to design the UI elements separately without the need of having a concept set.
Diffculties faced while creating a form currently:
Grouping concepts under a "concept set"
Adding the concept set to a "concept set of sets"
Creating a JSON configuration to control the behaviour of concepts in the form
Proposed Workflow
Define the workflow of selecting a form type, choosing elements, defining validations at field level, form level, view draft of the form and then publish it.
Provide implementers with a user interface using which:
They shall define the forms and its UI elements.
The UI elements may be bound to concept datatype. For example, for a coded concept the UI elements could be dropdown, multi-select, etc.
They shall be allowed to define validations on the UI elements. (Whereby eliminating the need for users to edit JSON configuration files and to provide custom javascript functions for validations)
Allow implementers to share the form definition across implementations thereby reducing the startup time for defining forms at each implementation site, i.e. create a master form for the implementation and export & import forms across implementation sites. The implementers must also be able to import existing forms and make changes to them. In this case the updated form will be the new form definition and the previous instance of form must be retired.
Each field must either bind to a source which is a concept or it could be a derived/auto calculated field. An example of a derived field is BMI which is auto-calculated based on the patient's height and weight.
Field shall be allowed to be marked as read only. Say you have a order fulfillment form, in which you have added patient related data (say date of birth or sex), which should be read only on the order fulfillment form being created.
Field must be allowed to be marked as mandatory or dependent on some other field. <To-Do>
Fields may have default values. Consider a form that has a date/time field which defaults to the current date time of when the form data is being captured.
Fields must support visualization field that you can choose from. eg: text should have long and short text. <TODO:> Clinical example
Coded fields shall have button-select, dropdown, multi-select and autocomplete options.
Every field (either label or the value of the field) must allow internationalization (different languages) and localization (date format, currency)
Default label shall be taken from concept name, however users shall be able to override it.
Each field may have validations associated with it.
Validations may be derived from the bounded concept associated with the field.
There may be custom validations associated with a runtime function in javascript.<Elaborate><Example>
Special fields like mail ID, phone number, patient ID, etc...must have special UI validations of data being in particular format.
The system shall need to store following information associated with the form while creating or modifying the form.
Fixed Intake Form - can be filled only once (e.g. Diabetes)
Iterative Intake form - edit & refill an intake form (e.g Multiple instances of TB)
Followup/Progress form
Share the forms (make it portable) to different Bahmni systems.
Shall allow users to edit form data within same encounter data/session context. (obs.form_namespace_and_path --> form ID, weight in two forms (gynae and cardiac)
Migration strategy for existing clients: Backward compatibility or allow both methods (old and new) or migrate form definitions. <TBD>
Figure out a more intuitive way to add new values (accept new value) | nice to have
Need (must have) in the current way, should have (a new way) to do the same