Pré-database migration transformations

Owned by Xavier Gillmann (Unlicensed)
Last updated: Dec 21, 2022 by Marco Kalin
2 min read



The aim of this phase is to achieve a running version of openIMIS where:

  • all UIs (currently asp pages) are re-implemented in the target Web FE Technology

  • all business logic (currently .NET code and MSSQL Stored Procedures) is re-implemented in target Online and Batch BE Technology

The database in use at the en of this phase is still the current MSSQL instance, with no (or only minor) changes in the data structure.

Finally, this phase is accomplished in iterations, module per module.

Each iteration identifies the modules to be re-engineered and delivers a production-ready assembly of legacy and re-engineered modules, covering the current openIMIS functional scope.



The very first iteration of openIMIS will be a "all proxy" implementation where every (functional) feature is a proxy in the (web) frontend layer to existing openIMIS implementation:



Next iterations will be planned to replace chosen proxy(ies) to their target implementation.

The core components (FE, BE,...) of openIMIS will be built (enhanced) along the proxy replacements.

The choice (order of) proxy replacement will thus be based on:

  • what is needed from the core components, and its availability

  • what has the most value (business wise)

Proxy replacement by own implementation

Proxy may be replaced by the target implementation, moving horizontally (in a layer) or vertically (cross layers).

Example, should we identify the Payers-related features as interesting to migrate first.

An iteration may target the Payers FE proxy replacement by implementing a BE proxy, targeting current openIMIS API (WebServices):

Depending on the identified workload, the iteration may even skip the BE proxy and connect the actual Payers BE plugins (Online and Batch) implementation:



Proxy replacement by delegation

Proxy replacement does not necessary mean full features re-implementation of existing features.

openIMIS will indeed rely on other Software components out of OpenHIE, a proxy may be replaced by a delegated implementation.

Example, should HFR target an interface to DHIS2 (Organisation Units).

Not all HFR features (like manage facilities hierarchy,...) must be re-implemented in the openIMIS while openIMIS will need search capability for facilities, reference them in the services (price lists,...),

the actual hierarchy management, facility description, grouping,... can be delegated to DHIS2:

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/