Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A form is a collection of form fields classified through pages, sections and questions. Forms are defined following a schema written in JSON. OpenMRS Forms (specifically, those that use the React Form Engine, aka RFE) are leveraging the JSON Schema with a few custom extensions. Below is a snippet of a basic form structureThese fields are rendered differently based on their associated question type and rendering. For example, a text field dropdown will behave differently than a dropdown.

Forms are described using JSON schemas that conform to the O3 standard JSON schema spec. This standard JSON schema ensures that schemas built using either the Angular or React form engines have parity. Below is an example of a form rendered using the Form Engine:

Code Block
languagejson
{
  "name": "Hello world form",
  "pages": [],
  "uuid": "ff0933fb-20bd-4e44-a3e8-4073e9801ceb",
  "encounterType": "d105cbc3-728d-4d11-9ed3-637bf1a4e8a6",
  "availableIntents": []
}

Form schemas get constructed using the Form builder.

Form properties

...

-728d-4d11-9ed3-637bf1a4e8a6",
  "availableIntents": []
}

O3 ships a form builder frontend module that users can leverage to build forms of arbitrary complexity. These schemas can then be published for use in the Patient Chart to collect data.

Forms can be in any one of the following states:

  • published - can be accessed in both the form builder and the Patient Chart.

  • unpublished - can only be accessed in the form builder. The Patient Chart forms workspace only loads published forms.

  • retired - cannot be accessed in either the form builder or the Patient Chart.

Properties of a form

A form schema comprises the following properties:

Element

Type

Description

name

string

The name of the form

uuid

string

The unique form identifier

encounterType

string

The encounter type uuid associated with the form’s encounter

inlineRendering

single-line / multi-line / automatic

The inline rendering mode

pages

Array<Section>

A collection of pages that makeup make the form

availableIntents

Array<Intent>

A list of intents supported by this form

...

Here's how this page definition gets rendered:image-20240418-155220.pngImage Removed

In practice, your form will likely have more than one page. You can cycle through the pages by infinitely scrolling or selecting the desired page from the left sidebar. Here's how a form with multiple pages would look like:

...

A section is an element of a form schema that groups together related questions. Sections will be rendered in "expanded mode" by default. Set isExpanded to false in the section definition if you want the section rendered in "collapsed mode".

...

  • isHidden: A boolean value that determines field visibility. In most cases, this value is driven by hide expressions.

  • hide: You can use this to define logic for hiding a question based on certain conditions. To do so, you provide a JavaScript expression that evaluates to a boolean value:

    Code Block
    languagejson
    {
      "hide": {
        "hideWhenExpression": "onArt!== 'a899b35c-1350-11df-a1f1-0026b9348838'"
      }
      // This logic hides the question with the `onArt` id if the value of its
      // concept does not match the supplied value
    }
  • required: If set true, that form field is considered to be mandatory. Defaults to false.

  • unspecified: If set true, the form engine will render a widget(as part of this field) that can be used to mark this field as unspecified. By default, a mandatory field can't pass validation without a valid value. However, think of a scenario were where it’s almost impossible to provide a value eg. when filling out a form in retrospective were where a value wasn’t collected on the paper form. For such scenarios, a required field can be marked as unspecified.

...