The following flowchart outlines the recommended implementation steps and in which order they are usefully taken. Below, all eight steps are discussed in detail.

Open

Step 1: Scheme design

OpenIMIS is an IT system that supports the processing of health insurance schemes. It is hence an important prerequisite that the insurance scheme is clearly defined, specifically in how it will function and what it needs from its information system. If this isn’t clear there is a significant risk that the insurance scheme will turn into what its information system does rather than vice versa. Knowing how the scheme functions (procedures), who the key actors are (structure), what benefits are offered, and how providers will be managed, gives a blue print of what the software needs to do.

The comprehensive design of the scheme is therefore an important prerequisite to the implementation of openIMIS. The following design elements need to be clearly established before implementation:

• Guiding policies and regulations

• Organizational structure

• Operating procedures

• Benefit Package

• Provider payment mechanism

• Provider empanelment criteria and process

In some contexts additional prerequisites are required, such as ensuring the establishment or modification of insurance acts/laws which regulate or establish the insurance entity. The process involved in this stage needs to be consultative in nature and involve relevant actors from the insurance body, relevant ministries (Health, Finance), and other key stakeholders involved and directly related to the insurance implementation. Assessment and planning for the introduction of the software ideally should be done towards the end of this step (once design aspects are clarified) otherwise the assessment remains incomplete and prone to gaps or subsequent changes leading to an inadequate system.

Step 2: Scheme operationalization

Once the prerequisites mentioned above are met, there are processes which would ideally run parallel to the customization process. These processes include:

• Identification and contracting of:

  • Health care providers

  • Telecommunication provider (for data transfer services)

  • SMS gateway (where applicable)

  • Mobile payment service provider/payment gateway (where applicable)

• Procurement of:

  • Data transfer packages from telecommunication provider (sim cards with internet)

  • SMS gateway services (SMS package)

  • Forms (including identification cards) and laminations for card

  • IT hardware (phones and computers)

  • Appropriate hosting environment as per openIMIS community recommendations

• Recruitment of organizational staff (at all levels)

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.

Lastly all staff need to be recruited and in place. A key question to be addressed by the insurer is around the development and maintenance of openIMIS. While the solution is freely available, maintenance of the application requires some support structure and in addition if the insurer desires to undertake further developments to the application locally then there is need of additional capacity. At this point the insurer needs to decide whether this is all done in house or whether it is (fully or partly) outsourced and accordingly have appropriate staff in place.

Step 3: Software customization

Ideally once the design of the scheme is completed the task of customizing the system for implementation should begin. The following aspects are crucial:

• Assessment of system specifications against scheme operating procedures

• Amendment to SOPs or systems specification as needed

• Software modification as per modification made to system specification (if applicable)

• Set up of test server (installation and loading with test dataset)

• Integration with SMS gateway (if applicable)

• Integration with mobile payment service/payment gateway (if applicable)

• Testing of developments

• Finalization of system developments based on test results

• Language customization (resource files and supporting documentation)

The openIMIS software already has some flexibility built into its source code, but this can also be modified to cater to additional needs from users. These needs can at times just be changing the terminology to reflect the terms or name of actors used by the insurer, however, these needs can be more farreaching and require software development. Comparing system specifications with scheme procedures helps identify gaps for software modification and once identified lead to change in system specifications and accordingly modification of software. Irrespective of the extent of customization needed, changes must be properly documented and agreed upon before undertaking any further software modification. When planning modifications it is helpful to consult with the openIMIS Product Group to check the development pipeline in order to avoid duplicate efforts and to find synergies and ways to coordinate development efforts. Integration with external components (eg. SMS and mobile payment gateways) are optional and dependent on the context. The importance of testing the openIMIS software in your context cannot be overemphasized. Plenty of time should be planned for testing the software particularly where significant changes have been made to the software.

Step 4: Software set up

After the customization of the software the next step is to set up the software for use by system users. The following aspects are important:

• Set up of:

  • Dedicated training server (installation with dummy dataset)

  • Live server

  • Server side security measures

  • Backup server and 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 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 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. In addition to the security measures within the application, it is important to have server side security measures in place which protect the server hosting the application and which need to be reviewed regularly to help plug security gaps.

There are various options when establishing an appropriate backup routine, depending on limitations on available resources, acceptable downtime, HR capacities and/or local preferences. 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. 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 documenting decisions being taken (on prices, list of facilities, users, etc.), how they are initially implemented, and how they are subsequently updated/managed. The system administrator can undertake this task but procedures need to be in place to initiate this action and monitor it, because generally the decision makers who initiate the change (eg. decision to add a new facility or change prices) are not the people who will be implementing the change.

Installation steps

First installations of mobile apps, offline installations, and loading extracts on respective devices are tasks that take time if the roll out is of a significant scale and should also be factored into the planning.

Step 5: Training

The next step after setting up the system is training different actors on how they can use the software for undertaking their tasks. The following set of actors 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 each group, as shown in the Generic Training Approach. Ideally the approach would be to combine training of actors on processes and the use of the tool/software. Server administration training should include training on managing the server on which the application runs (including security issues, management of web services, etc.) as well as maintaining the chosen setup. System administration relates to configuration 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 (internal or external, commission based, aso). Health facilities are a key actor that are generally involved in tasks such as identifying clients and the submission of claims in the insurance processing. Depending on the chosen setup the facility staff may also need training, which should be accounted for in the planning.

Step 6: Piloting

Any implementation of the system should start with a pilot phase to test out the system in a real environment with actual actors on a small scale. The lessons learned from pilot programs are always valuable, contribute to the improvement of the system, and subsequently increase the success rate of implementation. 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. 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 and noting bugs or problems that are observed during the pilot implementation that can be quickly responded to and fixed. In case 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. The learnings from the pilot stage should 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 as the setup of the scheme will continue to evolve.

• 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 system implementation, which then might lead to the decision to undertake local developments. 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 other implementers. Managing the upgrade of the software based on openIMIS releases 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 to see how local customizations (if undertaken) fit with the new release. Only once thoroughly tested should the solution be moved to the live environment.

Step 8: Scale up

Once the solution is piloted the scale up should be planned and executed based on the lessons 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:

• Appropriate server configuration (as per expected load)

• Infrastructure (personnel and equipment)

• Backstopping support structure

• Trained staff