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
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.
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
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.uuid, patient.sex, patient.birth_date) are stored under an object with the key set as 'patient', while those with name starting with 'encounter.' (such as encounter.provider_id, encounter.encounter_datetime) are placed under an object with key 'encounter'.