October experience zone and demo

[pramodkvarma]

Welcome to the dedicated discussion board category for October demo. All participants and other contributors can use this category to discuss and respond to Oct demo related items.

See demo deck for details of the demo. Everyone can comment and provide feedback.

There is a call every Thursday for the folks who are participating in the demo sandbox. If you are interested, please request via this forum.

THIS IS A PUBLIC DISCUSSION SPACE. PLEAE AVOID POSTING ANY SENSITIVE TOPICS RELATED TO YOU YOUR PROJECT OR COMPANY. PLEASE READ THE COMMUNITY CODE OF CONDUCT AND HELP MAINTAIN A SAFE SPACE. ALSO SEE GITHUB COMMUNITY GUIDELINES.

Welcome!

[PaulMakinMojaloop]

Thank you Pramod for creating this forum. I've asked an introductory/framing question already.

[eduffus]

On the call today I asked about the creation of a fictitious country context that can be use for demonstration purposes. At OpenCRVS we use Farajaland for this purpose (see https://documentation.opencrvs.org/default-configuration/intro-to-farajaland). If OpenCRVS features in the demo scenarios (or otherwise), the administrative structures for Farajaland are all available (https://github.com/opencrvs/opencrvs-farajaland), all based on the FHIR open data standard.

[pramodkvarma]

Thank you @eduffus, very useful.

[eduffus]

@pramodkvarma We obviously need to better understand the current scenarios so we can lock down the overall flow and then work on the technical integration of each DPG to support the E2E process. On last Thursday's call the scenarios seemed propositional, but there were a number of questions / clarifications required about the flow and even a 3rd scenario involved death registration mentioned.
Is there someone taking the lead on each scenario with whom we can join a call to discuss, agree and confirm scenario requirements? The potential role of the civil registry (i.e. OpenCRVS) was to this point not clear and we would like to provide our inputs on how it should be integrated.

[eduffus]

Great job Paul and thank! Lot's to discuss and iron out :-) @vvujjini can you bring together the DPG focal points around each of the scenarios to agree on the overall flow and the specific scope for Oct demo (which may well be less than the full E2E flow IMO).

[vvujjini]

@PaulMakinMojaloop @jeremi - Thanks for sharing the high level process flows. This is real helpful for our conversations to get final alignment on the flows.

@eduffus @ALL

Based on my conversation with the teams:

1. I learnt both OpenG2P and CoreMIS do not have self registration feature (at this point in time) for executing beneficiary initiated flow (i.e scenario 2). To trigger scenario 2 flow, I'm proposing we REMOVE this part of "Self Registration" feature from the scope. Self Registration data can come from any functional or department registry (e.g OpenCRVS, etc.,). We can assume, this functional/department registry has a UX interface to collect user request and pass on to OpenG2P or CoreMIS systems. If required, we shall animate self registration in the final polished demo video.
2. Since there have been requests to participate in both the scenarios, I propose each team attempt both the scenarios. The payment leg of the transactions should be common (i.e on agreed CSV file format interface) and ideation is on the eligibility determination, scheme admin and reporting interfaces.

I'm proposing the following to measure our progress in SANDBOX environment for the two scenraios. This covers integration to various DPGs in a phased manner.

Milestone 1: Sandbox setup
Scope: Each DPG install and configures the product in the sandbox.

Milestone 2: Payment Integration
Scope: Define scheme, Using enrolled users determine eligibility, generate payment api calls, receive payment status file, present the report. Beneficiary information should be seeded into Mifos / Mojaloop Oracle. Prove one time emergency payment and recurring payments for respective scenario 1 & 2.

Milestone 3: ID Integration
Scope: Integrating with identity system to get de-duplicated id, kyc, authenticate, etc., Requires beneficiary required information is seeded in the identity system.

Milestone 4 (Optional): Integration with functional registries
Scope: User Data can flow into OpenG2P / CoreMIS system from functional registries (like OpenCRVS, Household registry etc.,) to receive signals like pregnancy, birth status, etc., The decision to integrate with functional registries is left to the OpenG2P and CoreMIS based on integration complexity and time factors. Any integration shall be on common specification so that one functional registry shall be used between OpenG2P and CoreMIS systems in the final demonstration.

Milestone 5 (Optional): Issue Verifiable Credentials
Scope: issuing verifiable credentials to beneficiary. Enables new possibilities to share across other systems/functional registries.

Milestone 6: Reporting and UX
Scope: Showcase reporting, admin interface module to meet larger G2P program objectives from policy maker and beneficiary perspective.

Milestone 7: End to End Demo data seeding
Scope: Using fictitious country geographic, department and user data all repsective systems integrate using this data sets to showcase a unified view of beneficiary. If we all agree, Farajaland reference pointed by Euan is an option.

Milestone 8: Demo Video
Scope: Creating a short demo video for marketing team as first level input. This will help marketing team to create polished 2 min video with annimation (where required) as a final product .

Looking forward to hear your comments.

[vvujjini]

@vvujjini I believe you mentioned on the call today that you would finalise the details of the demo scenario flows in the next couple of days. Looking forward to seeing this! Just had a chat with Jeremi Joslin about some ideas he had about scenario 2, which he documented here: https://miro.com/app/board/uXjVPdQzhHc=/
It would be great to see a flow of this type for the scenarios showing the step by step process and the DPGs implicated. I think the only way of doing this is on a joint call with the integrating DPGs, however. Happy to join you 1:1 or on a group call to thrash this out.

@eduffus - Sure. I will invite to the DPG calls.

[pramodkvarma]

Excellent suggestions @vvujjini . I am fully aligned. Thanks.

[eduffus]

@vvujjini (for sharing with OpenG2P and Core-MIS in particular):
Milestone 4: Integration with Functional Registries
On the basis that neither Core-MIS nor OpenG2P have a self-registration feature, so scenario 2 needs to be triggered by a functional registry system. We are proposing that OpenCRVS signals a birth event and provides details of the mother and child as a trusted source of eligibility for e.g. a newborn grant scheme. The upfront flow will look like this:

1. Mother declares the birth of her child including her ID
2. Registrar registers the birth in OpenCRVS
3. OpenCRVS publishes the birth event via a webhook (see below for technical details)
4. OpenG2P/Core-MIS consumes the birth event details, including details of the mother
5. OpenG2P/Core-MIS authenticates / de-duplicates the mother's ID with MOSIP
6. OpenG2P initiates the payment process with Mifos / Mojaloop Oracle

Documentation of the birth event webhook is available here and will be further tested with MOSIP over the coming days. Please note: Currently we only have a "NATIONAL_ID" scope but we are adding one now for "socialprotection" with the same access. Any system that we register as a "socialprotection" client will also have access to our locations API too.
Hopefully that should be enough to get the OpenG2P/Core-MIS teams looking at this integration. We will provide final APIs and docs once we have setup the OpenCRVS server on AWS.
We can arrange a call a bit later with OpenG2P/Core-MIS teams to support OpenCRVS integration but appreciate milestone 4 is optional and comes after milestones 1-3!

[pmhunter]

Hi Pramod,

I have been talking with my team and we had a couple of questions on the marketing side of things. Who is leading content (video/marcom) from your team, and what will they need from DPG participants? Branded collateral? Printed materials? We may customize some of our standard items for this purpose, but want to know what you intend to distribute at the WB event. Thanks!

[vvujjini]

@pmhunter Teams from WB and Co-Develop will be part of this leading team with support from all participating DPGs. Contact info from WB/Co-Develop teams shall be shared in next few days.

1. Immediate expectation from DPG participants is to get an end to end demo on the sandbox. These screen shall be used for the 2 min demo videos (along with animation and voice overs). The creation of this video shall be a collaboration between WB/CoDevelop/DPG teams.

2. Printed hand outs shall be in the form of a poster card with brief about DPG, in depth demo (as link in QR code format) and contact info. Above team shall publish a template for the same in collaboration with DPGs.

WB event's session format is also being finalised. Once there is full clarity on this we can meet up plan these steps. Separate meeting will be scheduled in next 1 or 2 weeks to discuss these logistical matters. Hope this answers your questions.

@pramodkvarma please do add your thoughts...

[pmhunter]

Thanks much, we will monitor and plan accordingly.

[pramodkvarma]

Yes @vvujjini you are right. We will share the 1-pager print template for DPGs in couple of weeks. For now, sandbox integration is the most crucial.

[jeremi]

Should Demo 1 and Demo 2 use the same beneficiary database? and just be 2 different programs on the same population?

[vvujjini]

Yes. That would be ideal. In fact, between OpenG2P and CoreMIS sharing common DB through MOSIP, Mifos, OpenCRVS, etc., showcases integrations and readiness for govts to get confidence!

[andreamartin]

Sharing here the link to the draft flows we presented in today's meeting.
https://miro.com/app/board/uXjVPcLdYAQ=/?share_link_id=202935431974

[eduffus]

@andreamartin flow 2 looks good from the OpenCRVS side. As OpenCRVS is the trigger for the whole process, see a number of assumptions below:

• OpenCRVS will expose a webhook where the payload will contain details of the child and mother, including a tokenized (virtual) ID of the mother. See notes on the webhook here.
• The mother needs to already exist in the MOSIP database so biographic info can be validated (authentication)
• Assume the mother does not already exist in OpenG2P/Core-MIS for the demo, and will therefore be created as a potential beneficiary as part of the process
• Eligibility for the programme will be based on the data shared from OpenCRVS on the birth event (e.g. DoB of child, Usual place of residence of mother etc.)
  Please shout if you think any of these assumptions are wrong.

[PaulMakinMojaloop]

Updating the process flows for scenario 1. I've split it into two flows; one assumes CoreMIS as the Beneficiary Management System:
https://miro.com/app/board/uXjVPZOuLgI=/?share_link_id=454880492886
The second assumes Open G2P as BMS:
https://miro.com/app/board/uXjVPZOuLG4=/?share_link_id=854466797379
Can someone from the OpenG2P and CoreMIS teams please review?

[jeremi]

Yes, all good for OpenG2P

[andreamartin]

Thank you Paul, all good for CoreMIS

[PaulMakinMojaloop]

HI, I've created a first draft of the process flow for scenario 2:
https://miro.com/app/board/uXjVPZYGUgs=/?share_link_id=562714421684
It's based on the input from Jerimi, with the payment details fleshed out.

There are some incompatibilities with the flow shared by Andrea. I'll work to iron these out in the next draft.

[eduffus]

Thanks for sharing @PaulMakinMojaloop . From OpenCRVS side this looks fine, although please note the 2 comments entered by Euan.

[PaulMakinMojaloop]

Thanks Ed. I've revised the flow https://miro.com/app/board/uXjVPZYGUgs=/?share_link_id=32238089238 in line with comments received, also reduced it just to the post-natal sue case. Please review again!

[eduffus]

This looks good to me @PaulMakinMojaloop. Small revision required as MOSIP is able to determine if mother is alive - see comment.