Mobile Strategy
This is page to define a strategy for the use of mobile technologies in openIMIS. It’s foundations lie in a report on the potential of mobile technologies in openIMIS by @Nils Kaiser but is intended to be a collaborative process among the openIMIS community. This strategy should serve as guidance for some of the software development efforts within openIMIS.
Background
Current developments/situation
Functions/Business processes supported through mobile use (current and future)
Beneficiary Management
Enrolment
Renewals
Update
Claims Management
Claims Entry
Claims review
Data Analytics
System Administration
Insure portal
Overview technologies
Android
Java/Kotlin
PWA
SMS / USSD …
Technology | Requirement | Supported interaction | Applicable?yes maybe no | Use case | Notes |
---|---|---|---|---|---|
SMS |
| Basic interactions, Notifications. No limit on number of steps for dialogue, but gets cumbersome above 5-10 steps. | Yes | Health officer
Public
| SMS costs are quite high. Implementers/Users need to be aware |
IVR |
| Very basic interaction but doesn’t require literacy (except “Press 5”). Can record messages and allows transfer to a real agent in urgent cases or as fallback. | maybe | Health officer
Public
| Call costs can be quite high (especially for outgoing costs). Implementers/Users need to be aware |
USSD |
| Basic interactions. Can support longer interactions Potential timeouts (USSD is like a call). | yes | Public
|
|
Mobile Web |
| Complex interactions. Limited offline capabilities are available. Progressive web apps can be installed on a home screen and receive notifications, thus mirroring a lot of native functionality. | maybe |
| Progressive web apps have longer initial load times - though much faster in subsequent loads - and require the development of an app according to specific technologies |
Mobile App |
| Complex interactions. Offline-mode is available with syncing data upon the availability of network connection. Can either be native Android / IOS (probably not that relevant unless for client app) or hybrid. | yes |
|
|
Questions
Priorities for new development
Mobile-first? (for some functionality? eg. enrolment - most of the use now and in future will be done through the mobile interface - does it make sense in the re-design to have UI/functionality that serves the mobile interface better if a choice has to be made between mobile/browser?)
Improve exiting functionality? Which ones?
Develop new functionality? (eg. client portal)
Strategic orientation
Develop openIMIS specific apps? One app for everyone? OR template app for every implementation to customize?
Build ‘modules’ in existing global goods - eg. ODK?
Integrate other global goods with similar functionality? (eg. Meso-health - now open source at: github.com/meso-health )
The strategy around mobile money
Technologies?
Standards?
Non-functional requirements
offline capable
themeable
Roadmap
Immediate action (within the scope of the current contracts)
Avail the App on Google Play for Demo
Verify that Google Play account is an official openIMIS Account
Privacy Policy for Google Play
Server Strings point to demo server
Upload to Google Play
Avail the App on Google Play as Generic App (e.g. via config file)
config file for
server string (url, password etc)
(additional attributes - low hanging fruits)
quick guide in https://openimis.atlassian.net/wiki/spaces/OP/pages/786104344
Mid-term action (needs new funding)
Avail the App on Google Play per Implementations (will be in the responsibility of the implementer)
Privacy Policy as template https://openimis.atlassian.net/wiki/spaces/OP/pages/1252950021
Enable flavoured builds by implementing organisations
Step-by-step guide https://openimis.atlassian.net/wiki/spaces/OP/pages/786104344
Warning about later upgrades: publishing in Google Play doesn’t mean people have it installed (latest version) on their mobile.
‘Corporate’ world use to rely on ‘User Endpoint Management solutions’ such as mobileiron, Microsoft Intune, etc. Additional costs might be required.
Long-term Vision
To confirm
use of device with multiple users?
transition strategy?
Questions to be answered:
Design of the mobile applications UX/UI
Combination of the functionalities in only one app: modular mobile application
Option | Advantage | Disadvantage | Preference / Vote (leave username) |
---|---|---|---|
One openimis app |
|
| @Dragos Dobre |
Multiple task-oriented apps |
|
|
|
Which type of mobile app?
Option | Advantages | Disadvantages | Preference / Vote (leave username) |
---|---|---|---|
|
|
|
|
|
|
| @Dragos Dobre |
|
|
|
|
Scenarios
Scenario | Description | Target users |
|
---|---|---|---|
Polish existing Android apps | Address gaps documented in inquiry and claims apps. Keep separate apps, and introduce changes iteratively. May require new apps to be built in future. | insurance officers, health practitioners |
|
Offline-capable PWA layer for modular openIMIS | Add a progressive webapp layer on top of modular openIMIS, which includes an offline-capable sync model. This means that the openImis web application would be usable on tablets, smartphones, even offline. It can also be made available in app store. Bundles all functionality of openImis into one mobile app, the main menu would be similar to the openImis UI (insurees, claims, policies, etc). | all openIMIS users | @Dragos Dobre |
Redesigned offline-capable mobile app (android or hybrid) | A complete Mobile app which mirrors functionality of the web app, albeit optimized for mobile and offline-capable. Bundles all functionality of openImis into one mobile app, the main menu would be similar to the openImis UI (insurees, claims, policies, etc). | all openIMIS users |
|
Mobile app for insurees* | A mobile app with dedicated features for insurees | Insurees, Public |
|
*not really in competition with other choices
Decision criteria
Requested by implementers
complexity
maintenance
development
does it allow to reuse existing Infrastructure, API, Mobile code…
New development language yes / no
Access with back-end
Robustness of the connection
Robustness (deal with complex data)
Synchronization
implementation / deployment
training & version management
Running costs
Strategy
Use of standards
Supported by or other eHealth solutions
Did you encounter a problem or do you have a suggestion?
Please contact our Service Desk
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/