Overview

Date: 2025-04-29 - 14:00 am (UTC)

Room:

Objective: Project

Participants: (kindly only add your own names, not those of other participants)

• https://openimis.atlassian.net/wiki/spaces/OP/pages/940048440

  • @Uwe Wahser

• OPM

• Worldbank

  • @shahzaib ahmad

• https://openimis.atlassian.net/wiki/spaces/OP/pages/3472785409 , https://openimis.atlassian.net/wiki/spaces/OP/pages/3472949249 , https://openimis.atlassian.net/wiki/spaces/OP/pages/3723985388

  • @Sunil Parajuli @Maxime Ngoe

• https://openimis.atlassian.net/wiki/spaces/OP/pages/835682333 , https://openimis.atlassian.net/wiki/spaces/OP/pages/835387396

  • @Seweryn Niedzielski (Deactivated)

Agenda:

Minutes

Admin Stuff

https://openimis.atlassian.net/wiki/spaces/OP/pages/835682333 - https://openimis.atlassian.net/wiki/spaces/OP/pages/4055597058

• not huge update due to release management

• solution coreMIS server has the custom dedicated menu structure (with icons) - applied manually through django admin panel. Later it will be loaded as django fixture

• SolutionBuilding repository where the output is generated into another repository (Solution repo).

• coreMIS solution built using github job https://github.com/openimis/openimis-be_py/actions/workflows/docker-manual.yml.

• colors and logo should also be considered as a part of configuration (Currently logo must be changed in assembly source code - it should be done through config)

• SocialProtection menu will be changed - there is mechanism to change it - now it’s the matter of decision how we should structure this menu.

• Make sure coreMIS branch changes are included on develop (coreMIS branch will no longer be maintained) - both for fe and be

m4h - https://openimis.atlassian.net/wiki/spaces/OP/pages/4059955305

• openSPP setup on local environment

  • Multiple registers present by default

  • No default PUSH mechanism (unlike openCRVS, where webhooks are used to push events such as birth/death registration)

  • APIs conform to DCI standards, ensuring baseline interoperability readiness.

  • Options for integration and standardizations are :

    • 1: Use openHIM mediator to map DCI API payloads into FHIR resources.

      • This allows openSPP to communicate in FHIR without modifying its native API.

    • 2: Introduce a native DCI module inside openIMIS, directly consuming DCI-compliant messages.

      • Avoids the need for mapping between different formats.

      • Makes openIMIS DCI-compliant natively, easing future extensions to other DCI-aligned systems.

    • Recommendation:

      • It would be great to demonstrate both approaches (mapping at mediator vs. adapting openIMIS) during the sandbox setup, to illustrate technical trade-offs

    • One way or another we should map to CoreMIS object (individuals instead of insurees).

      • Individuals is more flexible and will be easier to map on interoperability context

      • Almost all data on individuals on openIMIS side is stored on json_ext field

  • openSPP provides an interactive Swagger API documentation, facilitating API understanding and integration

  • Some Authentification API are not available, @Sunil Parajuli moved forward on FAST Api first

• Next step will be to focus on Bahmni setup

  • Currently integrated in FHIR R3. The workload for FHIR R4 upgrade must be assessed, especially for future compatibility with new health systems and insurance workflows

• Discussion ongoing with Medic Mobile and GIZ teams to explore synergies around health information exchange

• Need to improve Wiki Pages : It's important to keep interoperability architecture and workflow diagrams up-to-date to ensure technical alignment between stakeholders

Open

Questions / AOB

Presentations / Attachments

Additional Resources