Skip to end of metadata
Go to start of metadata


All muzima form data (e.g. registration form data and muzima form data) is sent to Form Processor.  When one or more more error is identified by the processor, it will be put in the error data queue.  Error requires some manual review process to correct the error before putting in the queue data for processing again.


Form Processing

Muzima API Form Submission

Phase 1 for Data Error Resolution

  • Reformat JSON to be more readable
  • Update the form processor and identify all errors instead of first detected error. In this phase, the error message will be stored in one column in the database.
  • Add a button to display text area for editing the JSON and have the original JSON displayed on top as reference
  • Once editing is done, another button for validation to ensure no error is found before putting into the queue data for processing. If error is identified, clicking on the button will enable the text area for editing.


Phase 2 for Data Error Resolution

  • On individual JSON error message page
    • Separate boxes (??) for different elements
    • Highlighting the specific error with some description of what type of error it is
    • Only highlighted elements (errors) can be editable while the error-free elements should NOT be editable 
    • After editing and passing the validation to confirm there is no error, it will be put in the queue data for form processing.  It will then prompt to next individual error message page.


Phase 3 for Data Error Resolution

  • On error summary page
    • Capture additional data
      • establish 1:n relationship (1 JSON message to multiple error fields)
      • for each error field, have another column to include reason of the error
      • display mUzima form template name (more readable that UUID)
    • Revise columns displayed on error summary page to include user friendly information (for data reviewer/data manager)
    • Create a new UI with filters (e.g. form, encounter location, error type, encounter provider, error reason) along with sorting features
    • Then, display counts for the specific filters.  Once click on the counts, it will display only those specific filtered errors with hyperlink
    • By clicking the individual error hyperlink, it will bring to the individual resolution editing page.
  • On the individual JSON error message page
    • consider to add a comment field for the purpose of "message status", such as "need more time to investigate"
    • add feature of saving the edited message as "draft" which user can return to continue editing later.



  • No labels


  1. I think ideally for the phase 2, we need to be able to pull the corresponding form template. When the user press edit, it will render the form data inside the form template. The form will then resubmit it to the queue when the form becomes valid form.

  2. If we can't do the above, then we need to be able to display the JSON tree. Clicking an error element on the tree will allow the user to edit only that particular element instead of the entire JSON object.