The very first iteration of openIMIS will thus 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:
