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 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.

Beneficiary Management
1. Enrolment
2. Renewals
3. Update
Claims Management
1. Claims Entry
2. Claims review
Data Analytics
System Administration
Insure portal

...

Overview technologies

Android
Java/Kotlin
PWA
SMS / USSD …

Technology

Requirement

Supported interaction

Applicable?

Status

colour	Green
title	yes

Status
colour Yellow
title maybe
Status
colour Red
title no

Use case

User groups

Existing?

Prerequisite?

Priority

Status

colour	Green
title	High

Status

colour	Yellow
title	medium

Status

colour	Red
title	low

Notes

SMS

Basic phone, 2G,

Literacy

literacy.'
Shortcode to ensure free SMS

Basic interactions, Notifications. No limit on number of steps for dialogue, but gets cumbersome above 5-10 steps.

Status

colour	Green
title	Yes

Enrollment information

Renewal reminders

Health officer

Enrolment
Claims valuation

Public

Renewal reminders

SMS costs are quite high. Implementers/Users need to be aware

IVR

Basic phone, 2G,
Phone familiarity.
Shortcode to ensure free calls.

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.

Status

colour	Yellow
title	maybe

Health officer

Information dissemination Enrolment
Claims valuation

Information about services (not related to openIMIS)

Public

Inquiry
Claims inquiry
Renewal reminders

Call costs can be quite high (especially for outgoing costs). Implementers/Users need to be aware

USSD

Basic phone, 2G
Literacy. Aggregator.

Basic interactions. Can support longer interactions Potential timeouts (USSD is like a call).

yes

Public

Inquiry
Claims inquiry
Payment

Mobile Web

Smartphone, 3G/4G,
Smartphone familiarity.
Web server/ domain required

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.

However, progressive 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

Smartphone, 2G or 3G/4G,
Smartphone familiarity
Web server / domain required.

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

...

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

...

Non-functional requirements

offline capable
themeable

Requirements Solutions

table should include

Solution title “USSD-based inquiry” or “mobile app for insurees”
Target users
Usecases / Covered business processes
Prerequisites

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

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 Installation and Country Localisation

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 Mobile Applications Privacy Policy
- Enable flavoured builds by implementing organisations
- Step-by-step guide Installation and Country Localisation

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	one codebase is easier to maintain can make “variant“ to simulate multiple apps easier for users to find mirror UX from web application (similar menu, logical separation of lists) detailed customisation possible for the implementers reuse of common functionalities (e.g. enquiring, barcode reader, offline sync) modular architecture: might allow additional implementation features Show/display menu based on roles (possible issue if there is multiple user using on app)	could bring higher download size	Dragos Dobre
Multiple task-oriented apps	versioning easier to read, a lesser impact for the update because the user-based of each app will be smaller on app per role “ready to use“ specialized apps => know its purpose, easier marketing/visibility fit to segmented usage (claim and enrolment)	how to manage complex processes

Which type of mobile app?

Option	Advantages	Disadvantages	Preference / Vote (leave username)
Android (like DHIS2, SORMAS)	not dependent on version of browser Code already exists (but needs improvements) no restrictions in access device functionality performance	separate code base on a separate language (additions of functionality means edits in both app and mobile code)
PWA (progressive web application) (like Bahmni)	“one” codebase for web and mobile front end even if mobile optimization is required the ReactJS Frontend(used in modular) can integrate PWA capability => code can be reused Regular web app gains offline functionality can migrate one module at the time (no big bang required) access to browser capabilities (e.g. GPS, camera)	Design to be reviewed => responsive design Show only required fields => don’t pollute the view Offline DB / Synchronization logic can be complex (service worker / Cache management) Need SSL signed by a trusted body (let’s encrypt, GlobalSign ….) which complexify the testing by preventing usage local servers (current modular has the same limitation) Don’t have access to full device hardware - limited to browser permissions/access. dependent of the version of the browser / webview	Dragos Dobre
Ionic/Xamarin/ReactNative	code more likely to be independent of the phone vendor libraries access to native platform capabilities (through Cordova)	New language to be used Possible license fees (tbc per solution) Redevelopment required

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

Versions Compared

Old Version 11

New Version Current

Key

Overview technologies

Questions

Priorities for new development

The strategy around mobile money

Requirements Solutions

Decision criteria

Roadmap

Immediate action (within the scope of the current contracts)

Mid-term action (needs new funding)

Long-term Vision

Combination of the functionalities in only one app: modular mobile application

Which type of mobile app?

Scenarios

Decision criteria

Page Comparison

Versions Compared

Old Version 11

New Version Current

Key

Overview technologies

Questions

Priorities for new development

The strategy around mobile money

Requirements Solutions

Decision criteria

Roadmap

Immediate action (within the scope of the current contracts)

Mid-term action (needs new funding)

Long-term Vision

Combination of the functionalities in only one app: modular mobile application

Which type of mobile app?

Scenarios

Decision criteria