EXECUTIVE SUMMARY

GIZ hired Bluesquare to pursue, as part of Bluesquare’s support of the openIMIS community, the openIMIS migration from the legacy to the new modular architecture and port the “Beneficiary Enrollment”. This software development project has been accomplished in 5 iterations with a global project deadline in February 2021.

As of March 2021, the project enters the Tender 3 phase. 

This document aims at detailing:

• the exact scope for all remaining modules that remain to be migrated;

• our strategy for the setup of an API that will provide an efficient environment for the subsequent development of a FHIR API; and 

• our strategy for the migration to a PostgreSQL database and the exact scope of our support to the migration of legacy databases. 
  
  

In doing so, Bluesquare has been through the below steps:

• Analysis and comparison of the architecture of the legacy system and the new modular architecture as a basis for a strategic decision on how to successively transition the remaining legacy code into the new modular architecture

• Analysis of the current data models and business processes to identify further opportunities for enhancing the customisability of openIMIS in terms of user-defined attributes and business processes

• Analysis of the options for a further optimisation of the open design of the system, allowing user exits for custom code and plugins for user defined modules

In a collaborative process with involved partners, Bluesquare is therefore proposing this Strategy for the full migration of the remaining legacy codebase based on the analysis results from the previous points and will update the technical roadmap accordingly.

Scope of the remaining modules to be migrated

After the Claim and the Beneficiary enrollment, there are still a number of modules to be migrated to the new architecture. The current application is still relying on a number of existing modules and features even to execute the already migrated activities. The main one being the user login and management. The other modules like the product management are usually only required during the setup phase of the project. Other modules like the reporting are crucial and might require a lot of work to be properly migrated. Last but not least, the database system itself is meant to be ported to an Open source environment, PostgreSQL.

User management

The current version of OpenIMIS is deployed with a reverse proxy (gateway) that dispatches the requests to the legacy system or the new modular architecture depending on the parameters. On first arrival, the user is redirected to the legacy system login page. Once the login has been validated, the proxy will intercept the cookie and transmit to the modular architecture the username that was authenticated.

It is therefore not possible to deploy the new architecture without having a legacy app running too. The goal of this first step is to provide a login feature from the modular architecture itself. That login would then have to support the various roles and user profiles that are already in the system. This module will still have to perform the login in the legacy system as long as there will remain parts of the application that are not migrated yet.

This also includes a password change feature for users, including some rules about password complexity. Currently, they are the typical uppercase, lowercase, length but a more robust and flexible rule like recommended by NIST might be more user friendly and secure. See Correct Horse Battery Staple for a more readable explanation.

The second activity in this module will be to provide the administration interface to create users and assign profiles to them. The current interface has dedicated screens for various roles like enrolment officers and claim administrators, however we will use a single interface with some adapting fields depending on the user profile.

The working plan for the migration of this module is:

• expose the User objects to the GraphQL API

• expose a User picker React component so that the formal sector team can close its current development

• provide the full user creation screens in the application, for the enrolment officers as well as for claim administrators. This screen is used by administrators

• provide user login

• provide user password change for the users themselves

• adapt the gateway to use the provided login screen instead of the legacy system

• If possible, adapt the gateway to perform a login into the legacy system so that the screens that have not yet been migrated can still be used

Medical services and items

Unlike the claim and beneficiary enrolment modules, the medical services and items do not include a lot of business logic. It is therefore mainly a conversion of the user interface. The backend already features most of the read operations and will need create/update/delete operations.

While the focus will be on the rewrite of the existing separation between items and services, we will try to keep as many parts of these elements generic, as was already performed with the Claims module.

Medical services/items price lists

The price lists definition depends on the previous modules. They allow the various services and items to be selected for specific regions and districts, potentially overriding the price of the item or service.

This module only allows specifying a region of district. Specific health centers are already able to use one of the price lists of their region in the new modular architecture.

Product

The product management is one of the more complex modules to migrate. It contains a lot of parameters that only apply in some scenarios. Some of these parameters are already handled by the corresponding module using them. For example, the policy value is computed based on the “lump sum”, the adult/child prices, etc. While the goal of the rewrite is to keep the same behaviors, we do intend to separate the product parameters into multiple tabs. The Formal Sector is already extending the product definition and would benefit from this approach to integrate. That integration will be left to the Formal Sector team. The suggested tabs would include one for medical items and services parameters. Another one would be the policy value computation and yet another one for capitation parameters or some other more specific parameter sets.

Payers & Funding

The Payers are already partly visible in the payment module. The add_funding stored procedure has also been ported already. However, the difficulty arises from the workaround that has been used to add funding by creating fictitious families and contributions.

Transforming the funding system into a more complete one is out of the scope of this rewrite. The current system of fake families will continue to be used. Changing it would also potentially have a strong impact on the reports.

Key system admin utilities

This module contains:

• Upload of XML files of reference data with different strategies: insert, insert/update, insert/update/delete and the ability to perform a dry run:

  • Diagnoses
    ⇒ uspUploadDiagnosisXML

  • Locations
    ⇒ uspUploadLocationsXML

  • Health facilities
    ⇒ uspUploadHFXML

• Download of the same data

• Download master data, used by the mobile application to retrieve the data necessary for use on mobile devices. The file is in JSON format named with “.rar” but it is actually a zip file made with 7zip and encrypted with a password from the system settings.

  • ConfirmationTypes

  • Controls

  • Education

  • FamilyTypes

  • HF

  • IdentificationTypes

  • Languages

  • Locations

  • Officers

  • Payers

  • Products

  • Professions

  • Relations

  • PhoneDefaults

  • Genders

• Download of Feedback and Renewals for a specific enrolment officer. The officers download this to their mobile device before leaving for offline use.
  ⇒ uspGetPolicyRenewals & .NET code for feedback

• Create phone extract: creates an SQLite database for Android apps use. It can be pretty big and therefore available to be run as a background task that notifies by email when done. It contains:

  • controls

  • policy inquiry

  • references

• Create offline extract: similar to above with location and health facilities.
  This item has many more options and downloadable items:
  Region, District, Municipality, Village, Items, Services, Price Lists Items, Price Lists Services, Price Lists Items Details , Price Lists Services Details, Main Dg, Health Facilities, Payer, Enrolment Officers, Products, ProductItems, ProductServices, ProductDistribution, Claim Administrator, Families/Groups, Insurees, Photos, Policies, Contributions, Zipped Pictures.

• Uploads of data generated by offline mobile applications. They produce a potentially large XML file that is encrypted and saved on the mobile device in the IMIS/Documents folder. They can then be transmitted by USB key for example and loaded here. There are three categories:

  • Claims: at some point, the new modular architecture could interchangeably use the stored procedure or its own rewrite, so this should be quite easy to support

  • Enrolments: this contains the whole enrollment process including beneficiaries, families, policies and contributions. This also includes renewals (they are downloaded in an extract above but are then included into the regular enrollment process). The process has already been ported to the modular architecture but the XML file processing was not used there so it will have to be adapted.

  • Feedback: the feedback requests are also downloaded above but the collected feedback is uploaded here. The claims module already features this feedback.

As described, these features are mostly intended for the mobile application interactions. There are currently two supported mobile applications: an enrolment one managing the family and insuree encoding, policy creation (with valuation) and renewal and feedback, and a claims application that can be used by health facilities to register claims. The former is available as a demo in the openIMIS Play Store while the latter is only available to customize and self-publish. SwissTPH is currently maintaining these applications and has expressed the desire to rewrite most of the above interactions with FHIR APIs. This would allow an easier integration of third party applications, ease future developments and reduce the specific development work in this module. No decision has been made on this regard yet but should the workload on this module reduce, Bluesquare would adapt the scope of this module or the reports one.

Reports

This was originally included with the above module but it should have its own section given the extent of those reports.

Current list of reports in the default system:

• Primary Operational Indicators-policies

• Primary Operational Indicators-claims

• Derived Operational Indicators

• Contribution Collection

• Product Sales

• Contribution Distribution

• User Activity Report

• Enrolment Performance Indicators

• Status of Registers

• Insurees without Photos

• Payment Category Overview

• Matching Funds

• Claim Overview (2)

• Percentage of Referrals

• Families and Insurees Overview

• Pending Insurees

• Renewals

• Capitation Payment (1)

• Rejected Photos

• Contribution Payment

• Control Number Assignment

• Overview of Commissions (2)

• Claim History Report

The reports have been designed to be adaptable and extensible, so this list might not correspond to many existing deployments and some reports might not be used anymore. Given the budget constraints, Bluesquare cannot guarantee that all reports will be converted. The goal of this module will be to setup the reporting framework so that additional reports can be added when needed. Bluesquare will use the allocated time to convert as many reports as possible. There are also traces of country or deployment specific reports in the current system, these will not be migrated.

1. The capitation payment will be overhauled by SwissTPH and migrated to the claim_batch module where it should belong. The payments are in fact the closure for a time period in a location or for a product.

2. The Claim and Commission overviews (for Enrolment Officers commissions) will also be migrated by SwissTPH.

Reports that are specific to a single module, like a Claim report, will be integrated into their respective modules. So that if a module is not deployed, it also won’t appear in the reports.

Remaining parts outside of the scope of this contract

REST API

Currently, there is a REST C# API that is used by the mobile application, the payment gateways and potentially more actors. Most of the features exposed in this REST API can easily be connected to the services exposed by the modular architecture, with work to ensure that the error handling and corner cases work the same way. A number of those interfaces can also be migrated either to their own modules for easier maintenance or converted to a supported API like FHIR. This is outside the scope of this contract but Bluesquare will try to work with SwissTPH to ease the migration.

Bluesquare Strategy for the setup of an API in preparation for FHIR API

Bluesquare considered that adding an HL7 FHIR API was challenging within the allocated time frame. The standard only partly covers the existing OpenIMIS functionality and developing the entire scope of the API would be extremely time consuming and probably used only in part and still require tuning and maintenance.

However, the current API used by the web frontend is very well suited to the modular architecture and allows developers to quickly get the information that they need. They can in a second phase consider adding the FHIR resources corresponding to their needs. The development of this GraphQL API is included in every module.

SwissTPH has already extended this FHIR API and expressed interest to continue to support and extend it as needed.

Bluesquare Strategy for the migration to a PostgreSQL database and legacy database migration scope

The original understanding was that the GIZ wanted to part ways with Microsoft SQL Server both because of its cost and for an open-source alternative like PostgreSQL. It was originally planned to perform a total migration of the database as part of this contract. However, some implementers have expressed their intention to stay with SQL Server at least for some time. The application should therefore implement and support both databases concurrently.

Django is designed to handle the database portability transparently. However, there are a number of caveats:

• MS SQL Server is an unsupported database backend. It works reasonably well but some custom functions had to be added to achieve some date computations for example. These would need to be adapted to support both styles, even if PostgreSQL has a more appropriate way to achieve the same result.

• There are a few raw queries for really complex requests. These would need to be adapted and supported on both database backends.

• Some performance tweaks are required to obtain the best performance from PostgreSQL.

SwissTPH hired a student to develop a migration tool from MS SQL Server to PostgreSQL.   It is available at https://github.com/openimis/database-data-migration_py It attempted to port all the remaining tables and stored procedures although the latter still has a lot of work required. The migration tool to transfer data between databases will prove useful.

Supporting both databases and having the code work on both is also not enough for this activity. With databases like Nepal that contain millions of claims, insurees and various operations, the performance aspects of the database are a crucial part of the migration. Bluesquare has developed a few scripts that can generate fake data in sensible scenarios in order to evaluate the performance of the application. Due to the inability to obtain an anonymized version of a real database, Bluesquare will use these tools to generate lots of data and try to evaluate that performance meets reasonable standards.

The delivery of the final PostgreSQL version is planned for May 31 2022 but Bluesquare will try to integrate support for the PostgreSQL version as the new modules are converted. The list of tables and stored procedures and their adaptation is available at https://docs.google.com/spreadsheets/d/10A3NELG1750ykhsR4LHIoD6XP5f7fCH2mCvMNk6-fOE/edit?usp=sharing and will be kept up to date as the modularisation continues.

Proposed Work Plan and Technical Roadmap

Conclusion

This preliminary analysis allowed us to reduce uncertainty on the ability to produce a fully modularized version of openIMIS, its limits and what Bluesquare could achieve in the given time frame. The modularity has already allowed other teams to contribute to the software. This proves that the proposed architecture was efficient and that some of the features that were planned to be developed within this contract will already have been built by other contributors or the requirements could change. The provided plan will remain the general guide but is likely to be adapted as the openIMIS system evolves.