...

• Project: Modular Migration Nepal - ❗ warning about project success due to budget constraints

• (tender in preparation as part of a general openIMIS maintenance contract) : Swiss TPH

• ❗ a lot of custom functionality: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43

  • 🧑‍🏭 establish list of functions that need to be migrated

    • prio 1: 🧑‍🏭 existing modification in legacy / hybrid version: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43

    • prio 2: 🧑‍🏭 new feature requests (must)

    • prio 3: 🧑‍🏭 new feature request (nice to have)

  • develop:

    • prio 1: 🧑‍🏭 existing modification in legacy / hybrid version: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43

      • 🧑‍🏭 claim

      • enrolment

      • configuration

      • reports

    • prio 2: new feature requests (must)

    • prio 3: new feature request (nice to have)

...

• ⚠️ budget discussion might not allow a migration within the current contract - future strategy in TZ unclear

• payment layer through REST API - dedicated API for GePG (Government ePayment Gateway)

  • MUSE API exists (will not be changed) - fully based on modular version

  • ⚠️ GoThomis - will TZ move to FHIR? (budget)

  • ⚠️ AfyaCare - will TZ move to FHIR? (budget)

  • GePG API exits in legacy

    • needs to be migrated to modular architecture (as a custom API)

  • 

• capitation payment,

• commission

• Covered by Project: 2022.T1c Modularisation III :

  • GePG not covered for the implementation in TZ, but support in global components might be possible

  • ❗ 🧑‍🏭 mobile apps on REST API is migrated to FHIR APIshttps://docs.google.com/spreadsheets/d/1XdamXxLejmPRzM5xN8dCSPSIbfNv1PgJ/edit#gid=1496686413

    • The apps are being adapted so that the API calls can be dispatched to one interface or another

    • Meeting to be organized with Christophe/Benjamin and STPH to see what can be done for the payment parts

  • 🧑‍🏭 specific reports → migrate to ReportBro https://docs.google.com/spreadsheets/d/1ORCdW5qajBbDT4BaKmAKf6W7X4wbs2Rcd0EQNEVRRzQ/edit?usp=sharing

  • Download master data (claim mobile app)

    • list of beneficiaries

  • 🧑‍🏭 Scheme Funding (“Matching Funds“)- distribution per region (currently done via fake families)

    • The code is there but was disabled some time ago

    • Could be done

  • …

• capitation payment configuration in Product

• batch run

  • capitation payment SP

  • batch run SP

...

• Impact:

  • Mobile Apps will not work any more

  • GOTHOMIS & Payment Layer in TZ

  • stuck to MS SQL because of stored procedures that are called from REST API (ca. 45)

• Discussion:

  • ⛔ C#-part can be re-used, but depend on stored procedures → will be migrated

  • - needs to be compiled for .net core per Windows and Linux (done in Docker)

  • - Added to Docker packaging

    • - issue with env variables (ex. DB connection string)

    • - sharing of files (ex. Insuree pictures)

  • ⛔ - Test REST API against PostgreSQL - not practical as REST-API will not be migrated on PostgreSQL

  • 🧑‍🏭 list of interactions with DB: https://docs.google.com/spreadsheets/d/1XdamXxLejmPRzM5xN8dCSPSIbfNv1PgJ/edit#gid=1496686413 - will not be needed after

    • mobile app for claims

    • 🧑‍🏭 mobile app for registration

Stored Procedures

• Impact: depends

• Discussion: need to list remaining stored procedures that will not be migrated

• 🧑‍🏭 https://docs.google.com/spreadsheets/d/18XxbBsPXvHrq7Enu7Bj02WpE1GiIaslNP1aMK6ECQcU/edit#gid=0

...

• 🧑‍🏭 will need to be migrated to PostgreSQL?

• testing - PostgesSQL uses low isolation level by default - might solve the problem

  • needs large data DB

  • in combination with report migration

  • develop.openimis.org

• might not be needed, documentation on how to approach potential problems

...