Skip to end of metadata
Go to start of metadata

RFC: A methodology for managing embedded and collected multimedia in mUzima android clients


mUzima is a mobile application written for android devices written initially for mobile-based data collection. As such it is able to render forms created using client side web scripting technologies (HTML5, js and css) and submit the collected data to the HTML5 forms processing module in an AMRS instance. Forms created for rendering on mUzima clients have hereto excluded embedding multimedia content as part of a form's workflow. Multimedia content (namely images, audio, PDFs and videos) collected using the HTML5 forms once captured also require to be embedded back to the forms for verification by the user (and possible deletion and re-capture). 

This document proposes a workflow with which embedded and collected images will be managed by mUzima clients and displayed as part of a form's workflow. 

Major considerations 

Some of the major considerations in developing this workflow include:

  • Multimedia content (Images and videos) uploaded using a CMS/OpenMRS module 
  • Multimedia content requires formatting for the latency and slow data speeds 
  • Multimedia content will be rendered on devices with various form-factors and resolutions 
  • Multimedia content will require to be rendered on devices with various processing power
  • Multimedia content will require to be loaded on devices with limited storage space
  • Multimedia content may have similar names for various folders. Name-spacing will be required 
  • Multimedia content will be captured using devices with different media capture capabilities 
  • Different devices will have different multimedia manipulation tools (such as zoom, play videos e.t.c.)
  • Different devices have different mobile operating systems and APIs (read: different Android builds and versions with different multimedia support capabilities)

Current Multimedia manipulation methodologies 



Proposed Approach (Functional requirements):

Collecting images on Mobile Devices:

HTML5 Media capture support (taking pictures, recording video and audio) from an input file type has only been supported in Android 3.0+. This is the proposed methodology to be used for collecting images using the HTML5 forms. Support for Media Streaming and capture on Android devices using the <video> tag is still not supported.

Users of the mUzima HTML5 forms that collect images will be presented with an input field on the form that will have an accept attribute that contains a 'capture=camera' property. This input field will be well denoted with a descriptive label that alerts the user that this input field (when selected) launches the camera app. 

Once this camera input field is selected and the camera app launched and used to capture an image, this image is stored on disk using the webview.setWebChromeClient API handler.  

Criteria for storing collected images on disk

  • Media Downloads onto devices
    •  Within mUzima currently, users are able to see all form templates available. They select the forms they want downloaded onto the device. If the form has any references to media, we would want a few things to happen:
      • mUzima should look to see if the media already exists on the device. If it does not exist, the media information is acquired from the server. The size of the file to be downloaded is compared against the available space on the mobile device. If there isn't enough space, the user is told to either  to (a) delete some mUzima media (b) make more space on the device (e.g. synchronize forms (which removes them), deleting non-mUzima media, or removing non-work apps).  Once it is confirmed that enough space is available, the media is downloaded onto the device.
      • Ideally, automatic media downloads and synchronization should happen when the person is in wifi.
      • We should compress the media files where possible to reduce data transmission costs.
      • To be safe, all media should be transmitted securely (https or VPN where available), though we could give an option for non-HTTPs transmission. (We prefer secure, as we will not have a guarantee of the nature of the media content. Some users for whatever reason might have identifiable media - e.g. voice signature, or patient media). We however should give a disclaimer whenever there are images, that it is the responsibility of the person creating the forms to ensure that no identifiable patient information is included.

  • Media storage and Referencing
    • The dev team folks need to come up with a mUzima standard for referencing media within forms. This should include documentation for future individuals who are creating forms on how to do it. Can model what ODK/Commcare have done.
    • We might need a mechanism to identify available space more generically.
    • mUzima based media should ideally not be accessible to other apps that can delete them accidentally.
    • The ideal situation would be to store media in an SD card where possible, but users can be given the option of storing the media in the phone's internal storage. Obviously, if the SD card gets accidentally removed, then all media would need to be redownloaded in the new SD card.

  • Media Deletion and updates:
    • Whenever a form is being deleted, if there is media associated with it, we should ask the user if they want to also delete the media. This obviously should only happen if the media is not associated with any other existing form - could affect how you label media on devices (might need to have a quick reference to which forms the media is associated with).
    • Whenever a user tries to delete a mUzima based media (e.g. when they are notified that there isn't enough space), the application should check to see if the media is associated with any form. If it is, then the option of also deleting the form should be given. The other alternative is obviously not to delete the media. 
      • Essentially, you cannot have a form with media references but the media is not there. 

  • Media display:
    • Ideally, should have a standard way of having particular types of media displayed.
    • As a first pass, we will deal with media display as part of forms.
    • A quick overview screen of available media (similar to youtube dashboard) could also help users quickly peruse through the media. It could also be ideal if the media can be then be rendered easily.

Server Side:

Have a place within OpenMRS where media associated with forms or those that require download to mUzima will be stored.

  • There is need to identify what the key metadata for each media type is. This should also include Short Name, Description, Date Created, Created By, Version Number, Media Type.
  • Have the ability to perform CRUD activity on the media.
  • Have a mechanism of identifying the media size easily even on the server side.

Add administrative privileges in the mUzima admin page to allow particular individuals to be able to manipulate media.



Ideally, this should have push and pull functionality.

Push - This is more around DELTA for media. I.e. if the media changes to a new version, ensuring that the new version is sent. (Functionality can come later)

Pull - a user of a mobile mUzima application can request particular media to be sent to them.



  • No labels