I may be able to make it, but, no worries if I can’t… I will try to follow up on the notes, etc
Mark
@akhilmalhotra @jdick @willa @mogoodrich @ningosi @valvijo @burke @raff, this meeting is starting now.
Thanks for the reminder.
Sorry to miss the discussion. Are there notes or summary?
Ellen
Needed a few clarifications from you guys on the form builder AMPATH is working on.
- Where are you storing the form definition? In a database table or in the hard-drive?
- Where are you storing the metadata (form type, version, created by etc.) of the form?
If you some documentation related to this, can you please share?
@akhilmalhotra just for the sake of sharing what the old school xforms module does, the form definition is stored in a database table which references a form_id pointing to the core openmrs form which has the metadata (form type, version, created by, etc)
Thanks @dkayiwa, yes we have looked at the form table and related tables (form_field, form_resource, etc…) in OpenMRS We were wondering how the AMPATH team are doing it for their form builder, before deciding the way forward for storing our form related data.
Sorry for a late reply.
We are currently storing the forms in the file system but we are working to change this where we will be utilizing the form, form_resource & clob_data_type_storage tables of openmrs.
Once we switch to using the openmrs tables these details will be taken care of, currently all these details are in the form schema itself see this schema
Update on Form Builder:
We are working on the form definition. Please find the WIP definition here. Also, attached are the draft mockups for the form builder. We are working on the MVP that will support only concepts of type Numeric and Text and we will be able to create a simple obs form. Please find the mingle epic here.
2 Likes
For what’s it’s worth I’ve decided to store the json as in here (look for valueReference): http://devtest04.openmrs.org:8080/openmrs/ws/rest/v1/form/a000cb34-9ec1-4344-a1c8-f692232f6edd?v=full (user: admin pass: Admin123)
@akhilmalhotra, thanks for sharing the mockups! I like them.
Will you be implementing the builder in a separate OpenMRS module so one can install it without having to use Bahmni?
It’s going to be used by Android Client, https://github.com/openmrs/openmrs-contrib-android-client/pull/178
@akhilmalhotra, the mockups look nice!
Is the idea that after clicking “Proceed with sets” you’ll end up with the nearly-built form with all those questions? That would be cool, but I’m not sure how adding a “Pulse Data” or “Temperature” concept sets, will magically give just that layout of multiple widgets.
In the screen where you’ve selected the Respiratory Rate numeric field, I think it would be nice to somehow be showing the actual underlying hierarchy of data that will be stored (i.e. this is a numeric obs for Respiratory Rate, in an obs group for Respiratory Rate Data).
How similar or different is this from the original “AMPATH kind of schema”?
@darius, the idea is that based on set definition we identify the members, and based on the data type of each of its member, we would come up with a default UI representation (widget/control) for each of the member and present it in the UI. However we shall also provide an option to change the UI representation, say from Yes/No buttons for a boolean data type, it can be changed to say Radio Buttons.
Please expect an update on the Bahmni wiki which would explain the same in couple of days.
We shall discuss this idea internally and get back to you.
Bahmni wiki page has been updated with the latest version of the form definition and differences in comparison to AMPATH definition. Please visit here.
Hi all,
Sorry for popping in late on this thread, and for having missed design calls that (may) have happened about it.
We see a great value in having such a form designer for implementers but also physicians. We are even more interested in the latter: to get the physicians in charge of medical informatics coming up with forms that they deem appropriate from a clinical standpoint. They would typically do this on a test instance until they achieve the final result, unless the form designer allows this kind of manipulation to happen safely on a production instance.
Eventually we would like the service provider to obtain a deployable version of the form so that it can be released (to further sites as well) through a deployable package. For instance this could happen through a forked Ref App module if we were in the context of the Ref App distro, but I understand that Bahmni works differently.
The scenario would be:
- Physician: works on a new form.
- Physician: generates a configuration upon completion.
- Service provider: packages & versions the configuration.
- Service provider: deploys the packaged configuration to several production instances.
Actually, 2 would be super powerful if all the necessary metadata was generated next to the form configuration as well. This would allow missing concepts and other assets to be generated before setting up the form on another OpenMRS instance. However obviously I understand that this complicates it all 
Could anyone shed some light and clarifies what may or may not be on the roadmap?
1 Like
Hi Dimitri,
This is a very nice idea. Thanks for sharing. We started out with the goal of making implementer’s work easy but we can have a discussion around this idea and may be incorporate it in our roadmap.
Hello everybody it has been a while since this started. I thought I should let you know about our (AMPATH) progress in implementing an application that uses OpenMRS backend to manage json forms. We have developed an app that utilizes the REST API. The app is found here and it is still very young (missing a lot of features). Nevertheless here is how the schema that uses other components looks like.
Feel free to shoot any questions.
@raff you might also be interested in this.
Thanks @willa for sharing this.
Can we see a demo of the app installed somewhere to fiddle with it from the UI?