Overview

Date: 2025-06-24 - 14:00 am (UTC)

Room:

Objective: Project updates and indepth discussions

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

• GIZPreview

  • @Uwe Wahser

• Worldbank

• m4hPreview , Y-NotePreview , Tinker TechnologiesPreview

  • @Maxime Ngoe

• Swiss TPHPreview , SolDeveloPreview

  •  

Agenda:

Minutes

Admin Stuff

Follow up on 2025-06-05 Developers Deep Dive Call: MOSIP IntegrationPreview

• https://docs.google.com/document/d/18AziKSmz1laSFGGrUhMmD61gJcxNAJ6CmWHlAuSi-ik/edit?tab=t.0

• eSignet doesn’t seem to be relevant as these are oreinted at online beneficiaries as users

• preferred (in that order):

  • a) management of dedicated / individual numbers (use case 1.2.B)

    • ongoing project in Ethiopa with MOSIP which might put MOSIP into the position of verifying the national ID (relevant to Komores, too)

  • b) MOSIP for biometric verification (use case 2)

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

• openHIM implementation - worked with traefik to setup reverse proxy to manage domain integration to openHIM.

• No updates from CHT due to cancellation from their side. Previously we discussed with CHT, feedback (as part of usecase1). Discussion on subscription method to push claim data to CHT side (push strategy).

• For subscription “Claim” data to be sent , it requires a bit development on openIMIS side, this seems to be the best scenerio since, openimis will share data to external systel (like CHT).

• Real time Data notification via FHIR Subscriptions Workflow

  • CHT Subscribe to claim creation event

  • On claim creation openIMIS send the claim information to CHT real time

  • CHT is doing his own process for feedback collection

  • CHT is sending feedback to openIMIS (including InsureeUUID , ClaimUUID and data collected on their side)

• Subscription on claim is not really working out of the box so if we want to move forward with this kind of 2 way interoperability we will need to develop this feature on the sandbox context. (few days are required to make it work - 4 days). This subscription mechanism for claiming can be useful for other interoperability scheme and tools.

• openSPP -DCI-register endpoint : there is no specific standard for this kind of endpoint. Sunil proposed a structured endpoint for individual registration

  • Use case located for now is openSPP as a Registry (ie : Farmer Registry)

  • openSPP doesn’t follow the DCI standards at this stage. But we hope they will adapt in the next release

  • openSPP should then send the individual to openIMIS

  • openIMIS will play the integrated social protection plateforme

  • Possibility to integrate with openG2P but requires more analisys

• Slide:

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

• we are working on integrated experience to develop a solution from solution definition to development env

• we are working on splitting the social protection package, there is open discussion but one should not mix registration and enrollment. Currently registration isn’t available. Creation of individuals are currently on social protection package. Registration is the creation of insuree/individuals. Enrollment - attach individuals to the programme.

• we are planning db migration to full django to have a real modularity

• open question on data init, we develop a nice ux role definition but it might conflict with fixture from role

•  

Questions / AOB

• We need to talk about splitting the social protection package and how it's going to be done. As Shahzaib pointed out there's currently dependency issues between individuals module and the social protection module due to enrollment implementation. That should be fixed before any discussion of further splitting social protection module

Presentations / Attachments

Additional Resources