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)

1. Beneficiary Management

   1. Enrolment

   2. Renewals

   3. Update

2. Claims Management

   1. Claims Entry

   2. Claims review

3. Data Analytics

4. System Administration

5. Insure portal

Technologies to be used

1. Android

2. Java/Kotlin

3. PWA

4. SMS / USSD …

Roadmap Strategy

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

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

  • Advantages one app

    • one codebase

    • can make “variant“ to simulate multiple apps

    • easier for users to find

    • mirror UX from web application (if PWA ?)

    • detailed customisation possible for the implementers

    • reuse of common functionalities (e.g. enquiring, barcode reader)

    • modular architecture: might allow additional implementation features

    • Show/display menu based on roles (possible issue if there is multiple user using on app)

  • Advantages multiple 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)

• Native/Web/hybrid solution: Android vs PWA (progressive web application) vs Ionic/Xamarin/ReactNative

  • Advantages native mobile app

    • not dependent on version of browser

    • Code already exists

  • Advantages PWA

    • “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)

  • Disadvantage PWA

    • 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

  • Advantages Hybrid

    • code more likely to be independent of the phone vendor libraries

    • access to native platform capabilities (through Cordova)

  • Drawback for Hybrid

    • New language to be used

    • Possible license fees (tbc per solution)

    • Redevelopment required

• Client mobile app (insuree app)

Next step:

Nils: clean up formatting → Table

Uwe/Dragos/Patrick/Nils - meeting April 6th