React Forms / Form Builder questions

Development
1

Hello all…

I’ve started to dig into the current React Form functionality provided by O3, and doing a gap analysis for the features needed for PIH to be able to adopt React Form, so apologies in advance, but there will likely be a fire-hose of questions coming from me in the near future. :slight_smile: I can start to ticket the missing features, but thought it would be good to confirm here first.

First, a bit of a blocker, there appears to a problem saving forms via Form Builder that I’ve ticketed here: [O3-2124] Form Builder: Unable to Save a form after initial save - OpenMRS Issues

Also, as I start making tickets in the O3 project in Jira for features we will need to add, is there any component/epic/label/etc we are using to track form-related feature requests? (@grace @dkigen )

Here are some of the missing features from my rudimentary testing that I’m going to start to ticket, please let me know if any of these features are already implemented and I’m missing them.

  • Referencing concept by mapping: Am I correct that concepts can only be referenced by uuid in the form schema? For usability, we will want to add the ability to reference a concept by a concept source/mapping pair, as we do in HTML Form Entry (HFE). For instance “CIEL:1234” to refer to the concept with the CIEL mapping 1234.

  • Translations: Is there any provision yet for localizing “label” text provided as part of the form schema? We often have forms in multiple languages.

  • Default labels: when rendering a question or answer of type obs, if you don’t provide a label field for that question or answer, the label should default to the preferred name for that concept in the current locale

  • Default answers: if you don’t provide a list of answers for a question and the question concept is of type “question”, the system should render all the answer concepts associated with that concept in the concept dictionary

Now a couple higher-level questions:

  • It appears that the form schema is stored in the clob_datatype_storage field. In HTML Form Entry, although form schemas are also stored in the database (in the “htmlformentry_html_form” table) we provide a means where forms can be loaded from the file system. This provides several benefits, most importantly 1) the ability to work on a form within an IDE, 2) the ability to commit forms to version control and collaborate on them, and 3) the ability to deploy and update forms easily to multiple servers as part of the server configuration package. Is there any existing or planned support for this? If not, I’d like to start to spearhead thoughts around this.

  • Right now, if I’m understanding, the form schema primarily provides a way to define the schema and questions to display on a form, but there’s not much control over the actual layout of the form. This is a departure from HTML Form Entry, which basically just added special form tabs to HTML while still supporting all the basic HTML layout. so basically if you could do it via HTML and CSS you could lay out a form any way you like. Thoughts on how/if we want to support custom layouts in React Forms? Honestly, in some ways I do like the fact that React Forms is opinionated and it’s layout is fairly simply (and trying to support layout could get myy), but it will be a bit of a paradigm shift from what we currently do, and people’s desire to have a form look a specific way.

Okay, I’ve probably already included too many questions in single Talk post, that’s all for now… I’m excited to get this working!

fyi @dkigen @ibacher @grace @ball @mseaton @fiona @ddesimone

Take care, Mark

2

We supporting loading forms via Iniz and that’s our recommended way to load forms in production (if I had my way, the form builder’s “save” button would just download the JSON—it’s probably good that I lose some arguments).

We made a decision early on in the O3 process that the form engine would be very opinionated on layout. We’ve inherited (from AMPATH) the decision that forms render as a single column, which makes it easier to support both a tablet view and a desktop view in the web app. These are, of course, revisable decisions.

The general idea (though this isn’t really implemented) has been that components in forms can interact with the rest of the patient chart. For example, we might have a link in a form section that will bring up a relevant table or graph (in the center view of the chart) so that, on a desktop, the user can look at, e.g., relevant lab results or w/e while filling out a form. Similarly, if someone needs to place an order, we can queue up the order in the order basket rather than having an order entry section of the form, etc.

On the detailed stuff, most of this is just the result of the React form engine being relatively “new”.

Supported on the Angular engine; should be added to the React-based one.

Supported on the Angular engine; will be added to the React-based one.

Supported on the Angular engine; will be added to the React-based one.

I actually don’t know if this is supported by the Angular engine or not (I tend to assume no). We should probably consider it. With the Angular-based form builder, things were setup so that when you selected a question with answers for a question, the answers were loaded from the concept dictionary at that point, though that does make maintenance harder.

The reason things work this way is that because the form engine is entirely a client-side application, there’s no way to resolve “default answers” without actually fetching the concept and for a form with dozens of questions, the performance would likely be unacceptable; however, to support the label loading and concept maps, I added an endpoint to the REST API called /conceptreferences which takes a parameter of comma-separated concepts (UUIDs or mappings) and returns them all as a JSON map. It would probably be possible to leverage the same end-point to also load answers (ideally, as part of a single call to the backend).

2 Likes
3

Thanks @ibacher for the quick and detailed reply.

So is the intended workflow now to develop the form via the Form Builder, and then download the JSON when you are done and save in the appropriate configuration directory for Iniz? That seems fine for deployment but still seems a little clunky for development, probably worth a little more brainstorming.

@fanderson @ddesimone @mseaton @ball I know I keep harping on this :slight_smile: but this ^^ is a paradigm shift that is key to keep in mind when doing our O3 planning and making sure it’s acceptable to us and our end users (I really hope it can be). ie, no more laying out forms to “look like the paper” but rather use a consistent entry interface, and don’t bundle things like ordering into a form, but link out to them. I think the sooner we can prototype and validate a form/workflow (assumedly using one from MCOE) in this new model, the better.

Yeah, totally, I figured that… I’m happy to work on some or all of these as it will help me get up to speed on how everything works. I’ll poke around tomorrow to see if I can figure out what is ticketed and what isn’t.

Take care, Mark

4

Keep harping @mogoodrich .

The unfortunate reality is that we have so many places and users that still are entering retrospective data. This is required because internet and power continue to be unreliable.

I wish that wasn’t the case. The layout shenanigans that we currently deploy with htmlforms are to match the (often ugly) paper layout.

I’d love to hear from other places which don’t face these real-life issues or use offline.

5

@ball a lot of work was done for O3 to support offline mode, one of the areas that we could explore is to bring back this functionality to the forefront.

Having said that, much work was also done to support special data collection flows that have the potential to support retrospective data entry (thinking here of FDE, fast data entry from the ICRC). I’m not saying this is applicable to PIH, but definitely worth exploring.

Cc @jesplana @frederic.deniger @mksrom

1 Like
6

I’m definitely open to suggestions about improvements we can make here.

I would note, though, that there’s no reason you can’t edit the files in an IDE and use the form builder as basically a preview (or as a mechanism to deploy the form to a dev system and view it in the actual form entry tool—assuming some of the bugs you highlighted get fixed).

7

Yes, absolutely @ibacher . Though to make this smooth we’d need an easy/seamless way for the Form Builder to load a file from the file system, as cutting-and-pasting from the IDE into the Form Builder editor will get tedious quickly . (This may not be particularly difficult… or maybe it’s already done and I’m missing it). We had something similar in the old HFE 1.0 edtior.

Just to continue harping @fanderson @ddesimone these are the kinds of questions we should be striving to answer with our intiail MCOE/O3 designs and prototyping, ie:

  • Is the O3 Form Entry suitable for retrospective entry, or do we need another technology for that? Would fast data entry meet that need?
  • For retrospective entry, is it imperative that that the electronic forms match the paper forms?
  • etc…
8

I ticketed the form engine improvements and labelled them with them form-engine label:

https://issues.openmrs.org/issues/?jql=labels%20%3D%20form-engine

(let me know if there’s a better place to put these/better label/better component to use)

2 Likes