2025-04-29 Developers Deep Dive Call: Solutions & Sandbox
Overview
Date: 2025-04-29 - 14:00 am (UTC)
Room:
Objective: Project
Participants: (kindly only add your own names, not those of other participants)
@Uwe Wahser
OPM
Worldbank
@shahzaib ahmad
m4h , Y-Note , Tinker Technologies
@Sunil Parajuli @Maxime Ngoe
@Seweryn Niedzielski (Deactivated)
Agenda:
When (UTC) | Duration | Who | Topic |
|---|---|---|---|
14:00 (UTC) | 5 min | Updates & administrative things | |
14:05 (UTC) |
| ||
14:45 (UTC) | 40 min | ||
14:25 | 5 min |
| AOB |
Minutes
Admin Stuff
Swiss TPH - Project: 2024.T3b Solution Building
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 - Project: 2024.T4 Sandbox Setup
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
Basic idea proposed:
Questions / AOB
Presentations / Attachments
Additional Resources
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/