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 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 users (e.g., index case testing vs. patient tracing)
The features below will help administrators track implementation status and app use.
1. Mobile App Usage Logs.
1.1. mUzima application needs to log several pieces of information from the mobile device and send these to the server. Information include: (a) date & time mUzima was set up, (b) date & time mUzima was updated, (c) Current ‘Program’ installed on phone, (d) the earliest login time, (e) last login time, (f) the latest login time, (g) form data upload times from mUzima.
1.2. mUzima to send the logged data to the server when the device is synced.
1.3. The mUzimamodule should receive the logs from the mobile and store them.
1.D. The mUzimamodule on the server should be able to update logs information from the mobile if new data comes in (in first version and to save space, the data will be overwritten).
1.E. The administrators should be able to view summarized data of 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 remote wipe the application data in cases where the device gets lost.
2.1. Capture relevant device metadata and store on server side
The metadata include: A unique device identifier, Firebase Cloud Messaging (FCM) token (Unique identifier generated through google firebase and used to send/receive notifications), Device serial number, device model, and user name of the provider using the app.
2.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.
2.3. The server-side module should allow the administrator to send wipe notification to selected device (e.g., one that has been reported as lost)
2.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:
- The module should:
- Provide ability to create a concept group
- Provide ability to put concepts into a group
- Provide ability to order the groups or concepts by drag-drop
- The application should display the observation by:
- Chronological view
- The observation should be displayed in a vertical format, grouped by observation date time with the latest observations coming first.
- 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.
- The server side module should:
- Provide a setting to set the google map API key
- Provide a setting to enable/disable the geomapping feature
- Have ability to process payload generated on mobile and update the patient’s address(longitude and latitude fields)
- The application should:
- Provide ability to add GPS location(longitude and latitude) for patient who do not have GPS location data.
- Provide ability to edit GPS location for patients who have relocated to a different place from the one currently registered
- Provide ability to get direction from the users current location to the patient’s location
- Have 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 of the user selecting the program to be used to set up the module, the application should detect which program to use immediately the user logs in for the first time and proceed with downloading the items in that program.
- The server side module should:
- Provide a way of assigning a user to only one program
- Provide a page to display which program has been assigned to each user
- Return the program assigned to the user once the mobile user successfully authenticates during the first login.
- The mobile application should
- Get the program from the server and automatically setup the device without user selecting the program.