Page tree
Skip to end of metadata
Go to start of metadata
  1. Mobile App Usage Logs.

Currently, the administrators don’t have a way of knowing several key things without asking individual users. These include: 

    • If the users are using the app or not
    • If the user has updated to the latest version of mUzima, or even what version the user has currently.
    • Whether the users are actually using mUzima installation.
    • When the user last uploaded data to the server.
    • What ‘Program’ is installed for each user (e.g., index case testing vs. patient tracing)

The features will help administrators track implementation status and app use. 

    1.  mUzima application needs to log several pieces of information from the mobile device and send these to the server. Information includes:
      1. The Date & time mUzima was set up
      2. The date & time mUzima was updated
      3. Current ‘Program’ installed on the phone
      4. The earliest login time
      5. The last login time
      6. The latest login time
      7. Form data upload times from mUzima.
    2. mUzima to send the logged data to the server when the device is synced.
    3. The mUzima module should receive the logs from the mobile and store them.
    4. The mUzima module on the server should be able to update logs information from the mobile if new data comes in (in the first version and to save space, the data will be overwritten).
    5. The administrators should be able to view summarized data on implementation and app use status for various users. Which users have what version of the application.

2. Improving Security: Remote Device Wiping

There is a need to have the ability to remotely wipe the application data in cases where the device gets lost.

Feature:

    1. Capture relevant device metadata and store it on the server side The metadata includes:
      1. A unique device identifier
      2. Firebase Cloud Messaging (FCM) token (Unique identifier generated through google firebase and used to send/receive notifications)
      3. Device serial number
      4. device model
      5. user name of the provider using the app.
    2. The mUzima module on the server should provide an interface that enables administrators to view users of each device, and details of the device.
    3. The server-side module should allow the administrator to send a wipe notification to a selected device (e.g., one that has been reported as lost)
    4. The mUzima mobile application on the target device should be able to receive the notification from the server and wipe all mUzima-related data from the device. This will happen at the earliest time the device is online.

3. Historical Data View Enhancements (for both Offline & Online Versions of mUzima)

Goal: To improve on the observation view on the mobile: 

    1. The module should:
      1. Provide the ability to create a concept group
      2. Provide the ability to put concepts into a group
      3. Provide the ability to order the groups or concepts by drag-drop
    1. The application should display the observation by: 
      1. Chronological view - The observation should be displayed in a vertical format,  grouped by observation date and time with the latest observations coming first. 
      2. Tabular view - The observation should be displayed in a tabular format, with observation date time being the headers, and concept and observations being the rows. The display should group the observation and order them as per the groups and order in the program concept order.

4. Geomapping (GPS)

The geomapping functionality will be a vital feature, especially for the patient tracing program. The functionality maintains GPS addresses and stores them as part of patient demographics in OpenMRS, and uses the information to plot the address of the patient on a map.

    1. The server-side module should:
      1. Provide a setting to set the google map API key
      2. Provide a setting to enable/disable the geomapping feature
      3. Have the ability to process payload generated on mobile and update the patient’s address(longitude and latitude fields)
    1. The application should:
      1. Provide the ability to add GPS location(longitude and latitude) for patients who do not have GPS location data.
      2. Provide the ability to edit GPS location for patients who have relocated to a different place from the one currently registered
      3. Provide the ability to get direction from the user's current location to the patient’s location
      4. Have the ability to generate a payload that will be synced to the server to update the patient’s address(longitude and latitude fields)

5. Automatic mobile app setup

This will remove the need for the user to select the program to be used to set up the module, the application should detect which program to use immediately after the user logs in for the first time and proceed with downloading the items in that program.

    1. The server-side module should:
      1. Provide a way of assigning a user to only one program
      2. Provide a page to display which program has been assigned to each user 
      3. Return the program assigned to the user once the mobile user successfully authenticates during the first login.
    2. The mobile application should
      1. Get the program from the server and automatically set up the device without the user selecting the program.
  • No labels