• 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

• 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

• Basic phone, 2G

• Literacy. Aggregator.

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

yes

Public

• Inquiry

• Claims inquiry

• Payment

• 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

• 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

• 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

• 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

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

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

• 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

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