Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Current »

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 (question)

  3. Data Analytics (question)

  4. System Administration (question)

  5. Insure portal (question)

Overview technologies

  1. Android

  2. Java/Kotlin (question)

  3. PWA (question)

  4. SMS / USSD …

Technology

Requirement

Supported interaction

Applicable?YES MAYBE NO

Use case

Notes

SMS

  • Basic phone, 2G,

  • literacy.'

  • Shortcode to ensure free SMS

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

YES

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.

MAYBE

Health officer

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

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

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

Mid-term action (needs new funding)

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)

  • PWA (progressive web application)
    (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

Preference / Vote

Polish existing Android apps

Address gaps documented in inquiry and claims apps

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.

all openIMIS users

Dragos Dobre

Redesigned offline-capable mobile app (android or hybrid)

Mobile app which mirrors functionality of the web app, albeit optimized for mobile and offline-capable.

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

  • No labels

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/