Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Introduction

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

Types of Form Data

Form data can be classified into two:

1. Observations:

Have concept IDs defined within OpenMRS Concept dictionary. Examples include patient vitals, symptoms, medications dispensed etc.

2. Non-Observations:

Include patient demographics and encounter meta-data such as encounter date and encounter location. There are no concept IDs for this data.

Types of supported Forms

Currently, mUzima supports four types of forms:

1. Registration form:

For registration of new patients. Only capture patient demographics and encounter meta-data. All data collected is Non-Observation.
Example: https://github.com/muzima/muzima-form/blob/master/RegistrationForm.html

2. Demographics Update form:

For updating patient demographics information. It collects Non-Observations only
Example: https://github.com/muzima/muzima-form/blob/master/DemographicsUpdateForm.html

3. Encounter form:

Both Observations and non Observations. It doesn't collect demographic data.
Example: https://github.com/muzima/muzima-form/blob/master/ScreeningEncounterForm.html

4. Teleconsultation form:

Special type of encounter form. Both Observations and Non-Observations
Example: https://github.com/muzima/muzima-form/blob/master/TeleConsultationForm.html

Note that:

  • 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).

See: https://github.com/muzima/muzima-android/blob/master/app/src/main/java/com/muzima/view/forms/HTMLFormWebViewActivity.java
See: https://github.com/muzima/muzima-android/blob/master/app/src/main/java/com/muzima/view/forms/HTMLFormDataStore.java

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: https://github.com/muzima/muzima-android/blob/master/app/src/main/assets/www/forms/js/muzima.js 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: https://github.com/muzima/muzima-android/blob/master/app/src/main/assets/www/forms/js/muzima.js line 750

  • No labels