The following flowchart represents the recommended Implementation implementation steps and in which order they are usefully taken. Below, all eight steps are discussed in detail.
...
To support smooth operationalization of the scheme, arrangements need to be made with external partners relevant to the scheme. While healthcare providers are essential to a health insurance scheme, telecommunication provider (to use mobile phone apps), SMS gateway provider (to send SMS confirmations/communication) and mobile payment service provider/payment gateway (to enable mobile payment connectivity) are optional in nature, depending on the scope of implementation of openIMIS. Not having the relevant external partnerships in place can cause delays in the roll out of openIMIS.
Technical partners and processes
Contracting of health care providers establishes modalities of engagement, scale of deployment, and ensures supporting infrastructure will be in place for openIMIS to operate. Paper based implementations without mobile apps or using mobile phone apps in offline mode can be supported but are not ideal setups. Preferably arrangements should be made with telecommunication providers to get data service to enable full use of the mobile phone apps. Data package options available vary across countries and should be locally explored. An example of a useful data package is a closed loop data connectivity package that can enable separate tracking of mobile data used for openIMIS transactions and non-openIMIS purposes and bill them seperately. All openIMIS mobile phone applications are supported in offline mode for data collection, but will require an internet connection to upload the collected information to the database. Sending SMS communication and management of mobile phone payments are tasks external to openIMIS and are undertaken by solutions of external partners that are locally available in different countries. Schemes that wish to use SMS communication within their insurance scheme can procure local SMS gateway service (SMS bundles, management of SMS sending and tracking) along with SMS packages and integrate it with openIMIS to send confirmations and renewal reminders to clients. Similarly schemes that accept mobile payments in their schemes can use local solutions for management of these payments and integrate it with openIMIS to exchange data on payments and automatically activate polices. Procurement and production of materials like hardware (phones, computers, memory cards, etc.), server set up as well as different forms, insurance cards, card laminations, etc. also many times can cause delays to the system roll out. Once procured, developing inventories and managing these inventories are equally crucial. Different configurations for server set up are possible depending on usage and available resources but it is ideal to have separate environments for development, testing, training, backing up and one dedicated for the live system.
...
Set up of:
Dedicated training server (installation with dummy dataset)
Live server
Server side security measures
Backup server and back up backup routine
Configuration of registers on the live server
Installation of:
Apps and uploading of extracts on mobile phones
Offline installation and uploading of extracts
Server setup steps
Different setups are possible according to the context of the implementation, but generally a setup should establish a live server and a seperate training servers server (loaded with dummy or test data). The configurations for an installation should be adjusted depending on scale and may require reviewing on a regular basis. The review should be based on tracking system load and optimization issues. For example, in the context of a the national scale up in Tanzania the application, database, and aggregated reporting IMIS (AR IMIS) components were placed on separate servers to manage higher transaction load. Additionally In addition to the security measures within the application, it is important to have server side security measures are important and in place which protect the server hosting the application and which need to be reviewed regularly as it helps to help plug security gaps. These are in addition to the security measures within the software but directly impacting the server hosting the application.
There are various options that can come into play while when establishing an appropriate back up routine. Limitations with regard to backup routine, depending on limitations on available resources, acceptable downtime, HR capacities and/or local preferences can influence the backup process established. A clear backup process including responsibilities should be drafted and executed. Costs for supporting backup infrastructure can be significant and hence proper justifications (weighing all pros and cons) should be made if compromises are being made. Ideal The ideal approach would be to make a risk assessment grid for different scenarios and establish what risk the insurer is willing to take.
Configuration
...
steps
Configuring registers (building blocks of the scheme – list of services, price lists, etc.) using the interface accessed by the system administrator provides the initial data before any processes can be supported by the system. A protocol should be established between the decision documenting decisions being taken (on prices, list of facilities, users, etc.), how they are initially implemented, and how they are initially added as well as subsequently updated/managed. The role of the system administrator can undertake this task but procedures need to be in place to initiate this action and monitor it as , because generally the decision makers who initiate the change (eg. decision to add a new facility or change prices) are different actorsnot the people who will be implementing the change.
Installation steps
First installations of Mobile mobile apps and , offline installations, and loading extracts on respective devices are tasks that can also take time if the roll out is of a significant scale and should also be factored in into the planning.
Step 5: Training
The next obvious step after setting up the system is the training different actors on how they can use the software for undertaking their tasks. The following set of actors are need to be trained:
Server administrator(s)
System administrator(s)
Scheme staff
Distribution channel/agents
Health facility staff
Trainings should ideally be split across different sets of actors (according to chosen implementation structure) covering aspects relevant to different actors. The approach should ideally each group, as shown in the Generic Training Approach. Ideally the approach would be to combine training of actors on processes as well as on and the use of the tool/software. A Generic Training Approach is also provided for reference. Server administration training should include training on how to manage managing the server for running on which the application runs (including security issues, management of web services, etc.) and maintain as well as maintaining the chosen set upsetup. System administration relates to configuration side aspects like management of key registers – (services covered, changes in prices, facilities covered, user accounts, etc. ), as well as aspects like offline extract management, etc. Scheme staff training would also depend on the roles to be undertaken by different actors including the distribution channel/agents (whether internal or external, commission based or so, aso). Health facilities are a key actor (eg. that are generally involved in tasks such as identifying clients and the submission of claims ) in the insurance processing. Depending on the chosen set up training to facility might also be needed and setup the facility staff may also need training, which should be accounted for in the planning.
...
Any implementation of the system should start with a pilot phase to test out the system in a real environment with actual actors but on a smaller small scale. The learnings lessons learned from pilot programs are always valuable and , contribute to the improvement of the system that , and subsequently increases increase the success rate of implementation of the solution. The following aspects are important.:
Design the pilot
Capture user feedback (bugs or new requests)
Translate user feedback into software/process requirements
Adapt software/processes to incorporate feedback
Test new developments/adaptations
Deploy new developments/enhancements
Thorough planning should be undertaken to pilot the system including the choice of the locations to be piloted. Ideally locations should be chosen that will provide the possibility of using all modules in different scenarios, giving diversity in terms of infrastructure and implementation conditions. A structured approach and tools should be used for capturing user requests or capturing of and noting bugs or problems that are observed during the pilot implementation that are can be quickly responded to and fixed. In case of new requirements as in the earlier step on the pilot shows the need for software customization, the exact requirements should be properly documented, agreed upon, and then developed in the system. Subsequently thorough testing should precede the deployment of the new developments. Based on The learnings from the pilot stage further planning of the scaling up should be undertakenshould be used to update the plan for roll-out and scaling.
Step 7: Ongoing maintenance & upgrades
Once the system is up and running a number of regular maintenance tasks can be expected within the scheme as the setup of the scheme will continue to evolve. This would relate to:
Day to Day management
Updates to configurations
Ensuring system backup
Backstopping support to users at various levels
Preparing data extracts for offline use
Capacity development of (new) users
Ongoing capture of user requirements, gaps, and bugs
Local developments (if undertaken)
Link to global community
Feedback to openIMIS global community
Implementation experiences
Software developments
Downloading new openIMIS release
Upgrading of test environment to latest openIMIS release as per guidance of release notes
Test new openIMIS release
Incorporating local developments (if applicable) and testing of scheme specific customization in new release
Upgrading live environment
Management of registers or system configuration is an ongoing task since as the schemes progress parameters change (for eg. change in price of drugs, enrolment officers/agents allocated to a village, change in price of benefit package, etc.). Similarly backups, provision of backstopping support to users, managing data extracts for offline users, as well as capacity building needs are ongoing for any insurance scheme. The support structure also needs to have in place appropriate processes in place for capturing new requirements or bugs that might be observed during the system implementation, which then might lead to the decision to undertake local developments or not. Here the link to the global community is useful in order to better synergize development efforts. Sharing implementation experience and software developments (if undertaken locally) would lead to further improvement of the solution for all other implementers of the solution. Managing the upgrade of the software based on openIMIS releases are is also an easy way to benefit from developments undertaken on the solution in different contexts. The openIMIS release upgrade should be managed in a sequential manner and taken through a local testing stage as well to see how local customizations (if undertaken) fit with the new release. Once Only once thoroughly tested , only then should the solution be moved to the live environment.
...
Once the solution is piloted the scale up should be planned and executed based on the learningslessons learned. The sequence of events in the scale up have to be visualized beforehand and a proper scale up needs to be supported by having the following in place with the following:
Appropriate server configuration (as per expected load)
Infrastructure (personnel and equipment)
Backstopping support structure
Trained staff
...