Page tree

Versions Compared


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


This document briefly describes the types of forms, the kind of form data handled by mUzimaeach form, form structure and the mechanisms of how the data is loaded into forms, and how the forms are serialized while saving.


  • Each of these forms has a corresponding handler within the server side forms processor module, to validate and process the data.

  • Ideally a project/organization that uses mUzima will have only one registration form (and probably one demographics update form and one Teleconsultation form) and one or more encounter forms.

The following sections describe encounter form, which is the first use case for automating their creation.

Interaction between mUzima (the app) and forms

The app invokes native WebChromeClient provided by Android, and passes initial form data to be pre-populated into forms. The app also provides a Javascript Interface to the web client, through which the web client can interact to send requests to the app (e.g submit form data for saving).


Populating forms Algorithm

This loads previously saved data (demographics and observations) for saved forms, and demographics data only for new forms.

1. Populate Concept data:

Iterate through JSON payload observation object, load data into elements with corresponding data-concept attribute values as payload keys, clone elements to create repeated sections as necessary, while maintaining nested structure of concepts.

2. Populate Non-Concept data:

Iterate through non observation objects, load data into elements with corresponding name attribute values as payload keys, clone elements to create repeated sections as necessary.

See: line 733 - 747

Saving Forms

Happens when auto-saving forms, or when user decides to save and exit web view client. This is done by:
1. Serializing form data into a JSON payload
2. Invoke and pass the payload to mUzima Javascript Interface. From there, the app has its own mechanisms to store and upload the data to server side.

Serialization Algorithm

This extracts all input data from form elements, and creates a JSON representation of the data while maintaining their structure. i.e.

  • Nested data elements are kept as JSON sub-objects, repeated elements as JSON array.
  • Observations (those elements with data-concept attribute) are stored under one object with the key set as 'observation'.
  • Non-Observations (those elements without data-concept attribute) are stored under objects with the key determined by their name attribute values. e.g all non-observation elements with name starting with 'patient.' (such as patient.uuidpatient.sexpatient.birth_date) are stored under an object with the key set as 'patient', while those with name starting with 'encounter.' (such as encounter.provider_idencounter.encounter_datetime) are placed under an object with key 'encounter'.

See: line 750