Technical Implementations

RFE Forms is a lightweight form engine written in React and powered by Formik and Carbon UX. It uses FHIR along with OpenMRS' Web Services to communicate with the associated OpenMRS instance.

Technically, RFE Forms is a React component that requires the following properties(props):

Mapping Controls

Fields are mapped to their controls via a registry system. This is highly extensible and easy to override the default controls.

{ "label":"Which of the following prevention services was the client referred to?", "type":"obs", "questionOptions":{ "rendering":"checkbox", "concept":"5f394708-ca7d-4558-8d23-a73de181b02d", "answers": [...] }, "id":"referredToPreventionServices" }

The field above has the rendering of type checkbox, the engine will simply check the registry for this kind of control and instantiates an instance of this control.

Submission Handlers

These handle submission at the field level. The engine doesn’t know how fields aggregate or compose primitive values into objects that the backend expects ie. an Observation. The form engine by default defines a set of base handlers eg. ObsSubmissionHandler, EncounterLocationSubmissionHandler etc.

These are also mapped using the registry system based on the type property of a form field. On form submission, the engine simply collects all field submissions and aggregates them into some object that OpenMRS understands.

Extending the Registry

The engine exposes an API to work with the registry.

  • addHandler(handler: HandlerRegistryItem) Adds submission handler to the handlers registry

    import { SomeCustomHandler } from "./handlers"; import { addHandler } from "openmrs-ohri-form-engine-lib"; // Add to registry addHandler({ id: "customHandler", component: SomeCustomHandler, type: "someCustomType", });
  • addvalidator(validator: ValidatorRegistryItem)

    Adds validator to the validators registry

    import { SomeCustomValidator } from "./validators"; import { addvalidator } from "openmrs-ohri-form-engine-lib"; // Add to registry addvalidator({ id: "customValidator", component: SomeCustomValidator, type: "customValidatorType", });
  • addFieldComponent(control: ControlRegistryItem)

    Adds custom control to the field controls registry

Post Submission Actions

The form-engine supports post-submission actions. A post action is a JS class or function that implements this interface. This functional interface requires implementing the applyAction(formSession, config) function which has the form session context plus an adhoc config. The config makes the actions more generic and configurable hence the ability of reusing the same action for different use-cases.

How do we register an action?

The engine utilises the registerPostSubmissionActionfunction to register a post submission action.

Example:

HERE is an example of an action that links mother to infant post delivery and here is how it's registered.

Take note that the registration happens in the app's index within the seeder func startupApp.

After the action is defined and registered, we simply have to reference the action within the target forms. This is the recommended and new way of doing things.

NOTE: We can also use the old way of linking post actions we didn't support configuring the actions then, see below. (The form engine still supports the old old way for linking actions)

Program Enrolment

The ProgramEnrollmentSubmissionAction is a generic post submission action that automatically enrols a patient to a specified program upon successful submission of an enncounter. This is passed through the form JSON and the action can either be enabled or disabled based on the expression passed as the enabled flag. Below is an example of TB Program enrolment in the TB Case enrolment Form.

We can add as many post submission actions as we want to one form and only those whose enabled flag evaluates to true will be processed.

Confirmation Modal

The repeating rendering type lets you replicate instances of a question. Such replicas that were created can also be deleted. When deleting a replica, a confirmation modal should pop up asking the user to confirm the action.

The implementation of the confirmation modal must be registered and implemented within the frontend module/package that has the form-engine-lib linked.

In your frontend module, you must have the implementation for the confirmation modal like such:

The modal must be registered in the routes.json of your frontend module in the property modals. For example,

Update the index.ts of your module to include the export of the confirmation modal, as such:

Finally, update the FormEngine component to pass along a prop called handleConfirmQuestionDeletion. This prop should contain a function that has been defined and implemented in the frontend module and triggers the modal using showModal:

If a confirmation modal is not implemented, the form-engine-lib fallbacks to deleting without showing the user any modal, but it is recommended to follow the instructions above and implement a modal if used in a package where the end user fills in the forms.
An example implemented in esm-patient-chart can be used as a reference.

Related pages