Overview

This goal is to review Use Case Journeys to break them down into use case steps along a high-level non-technical logical process flow. This helps identify gaps and overlaps across blocks, standardize terminology across teams, and helps clarify scope.

First, each sprint is broken down into level 3 logical processes

Next, each level 3 process is broken down into level 4 logical processes.

Level 3 and 4 processes include checklists mapping how each step applies across building blocks.

Next, a checklist is created to map components to blocks and define which components are exposed to other blocks, e.g. Logical process checklist - registration - post partum and infant care.xlsx.

See eGovernment - Logical Building Blocks v0.3.pptx for more on logical modeling.

Glossary

Asynchronous APIs

Consent

TODO: Please define this!

Promotion - Postpartum and Infant Care

From the Promotion section in Use Case Journeys:

The DIAL use case can be found here: DIAL Catalog of Digital Solutions

See UC-M-PPIC-001 Providing educational materials to a specific demographic group for a concrete use case.

Registration - Postpartum and Infant Care

From the Registration section in Use Case Journeys:

The DIAL use case can be found here: DIAL Catalog of Digital Solutions

Preconditions for Use case - Step ID

TODO

Demo service

https://er3.ext.egovstack.net/en/services-new/2c9280907f23fa95017f27efd0b20074

Process checklist (level 3)

Logical process checklist - registration - post partum and infant care.xlsx

Identify Parent

1. Capture Basic Details

a. The health worker logs onto the system. Assume the health care worker is already registered.

##This also means that the healthworker has completed any necessary ‘right to work’ checks and has presented any necessary qualifications for the role. This strongly suggests that they have an associated record in any national ID system

##Unclear whether ‘already registered’ means has an associated record in any national ID system or simply that they have an employee record in the healthcare service HR system.

First the health worker is authenticated with their health care ID. We can assume they are authorized to use the system for creating new records.

## i.e. when the healthcare worker authenticates themselves (to a required level of assurance - which might be username and password, one time code, biometric etc.) then the healthcare system has sufficient confidence that they are a person who is authorised to create new records

(Authentication is a question of are you who you claim to be, authorization is a question of entitlement/eligibility once authenticated.)

b. Selects the birth registration process

c. Enters the Surname, DoB and ID number of the Mother.

## Assumes a) that matching is based on these three data points; b) that the mother knows her (accurate) DoB); c) that the mother has already been registered in the national ID system; d) the mother knows / remembers her ID number; e) that there is a single, public facing and easily presentable ID number (i.e. a human readable 13 digit number like the Aadhaar number)

d. Optional: A photograph of the Proof Of Identity and mother’s face is stored with the application.

## Assumes that the mother has brought along her proof of identity for the registration process.

## Formally, at this stage, there isn’t an application to attach these two data points to(?)

2. Optional: registration payment

## I do hope this is optional - I am not aware of any significant postpartum / health care scenarios where the mother has to pay to be included in the service.

User Journeys:

QR code + OTP

This workflow shows how a payment can be made using generated QR code to initiate payment for a service. e.g paying to the government fees for the registration of a new person. The flow for other payment modalities like USSD is similar to the QR code flow.

QR code payment flow

Open

QR code payments

USSD + OTP

Patients (registrants) may be required to make a payment to enroll. In this case, the payment process is initiated. For general understanding, the payment is either P2G (person to gov’t) or P2B (person to “merchant”) thus enabling both gov’t owned or private clinics. For payment modality, you might have a payment initiation signal (such as NFC or a QR code), or other payment initiation. Consider USSD, Cash, Bank and Mobile Money Payments

E.g. The mother takes a smartphone, takes a picture of a QR code and ispaid. The mother receives a receipt for a successful payment.

This implies the registries communicate with payments to get a payment token for the QR code. Also, the payment block will send a receipt to the mother.

3. Optional: Validate with foundational ID system

The mother’s details are submitted and validated with an online service from appropriate Govt. Department, e.g. a government ID number, firstname, lastname and DOB. This is a call to a ministry API to validate details.

## Note, above, the document only had surname (=lastname) not firstname.

## If they match, what happens? Are these details used to create a new record in the healthcare system? How many fields are added? (From a data minimisation perspective you might just create a new record indexed on the matched government ID number (but noting that this still allows a large amount of state surveillance of the individual across systems)

If they don’t match this is flagged but not remediated at this point, but is managed later.

## It is best if match is not a binary concept here - what happens if IDnumber, lastname and DoB match but not the first name (Edgar / Ed)?

## I would like more detail about how it is managed later - is this a manual exception path to recombine / relink to the (correctly identified) foundational ID? (How will this reconciliation be done if there are multiple possible people who almost match?)

4. Capture Registration Details

Additional information can be captured such as phone number, current address, number of dependants.

## Is this to check / update existing records or to populate new fields? How does this data in the healthcare system link to data in the foundational ID system? (e.g. does that system include family members - i.e. number of dependents?)

4+. Optional: Request Registration Details from a Population Registry upon consent by the Mother

The Healthcare Organization might use existing (Public) registry (e.g. a Population Registry) to fetch necessary data about the Mother - registered address, marital status, number of dependants etc. This would require consent by the Mother. (The Mother would have an alternative to prove this data by presenting some paper documentation. In this case she would opt out from the digital sharing of her data in the Population Registry).

##This scenario of “choice” might be hypothetical in many places in the world. However, for the GovStack MVP it seems at least a plausible scenario##

During the process the individual is presented with the consent agreement together with the data policy for registration, requesting the data to be fetched from an external source, e.g. population register, the Mother consents to fetch the data, consent record is created, and the data is fetched from the external source successfully and recorded within the Health Organization’s system..

5. Optional where legally required: Get Citizen Confirmation

The mother confirms the information captured is correct. (what about the users without fingerprints, hands - MFA or MFI (identification) may be required)

## Don’t understand. Is this just confirming that the information given 1c above has been correctly entered by the healthcare worker? Assumes level of literacy in the mother to read the screen.

6. Update Register

The local register is updated for later use.

Issue program membership ID card, e.g. barcode

7. Capture Card Details

A pre-printed card is issued to the mother for future reference. The card details are captured in the system after the details have been verified.

8. Assign Card to Parent

The mother either signs or captures her finger print in order to confirm the receipt of the card.

## Signs what? Presumably on the system not the card.

9. Update Registry

The card number and mothers details are sent to the Govn. Registry for update, e.g. Department of Health or Home Affairs.

## It might be helpful to look at https://documentation.opencrvs.org/opencrvs-core/docs/system_overview/user_types/fieldAgents

Capture Birth Details

10. Capture Basic Details

Capture the information required for the birth registration process in the context, e.g. the name of the child, birthplace and time of birth. Register parent information, including all parents if known or available.

11. Update Register

The local register is updated for later use and submit the information for the remote Govn. Department Registry.

12. Request Birth Certificate

The mother is asked whether a birth certificate is required and where she would like to collect it from (by post \ Govn. Office).

## Birth certificate is almost certainly required and should be issued.

##Assumes postal service works and that there is suitably nearby government office.

13. Give Reference Number

Once the request is successfully committed the mother is given a reference number.

## For what? The registration?

Patient Case

14. Search Patient Case

Generate a new folder for case records and link it to the child ID. If no case exists, create one and link the Card, otherwise identify the correct record and store the case UID.

## Am unclear as to why this is now being labelled as a case

15. Update Registry

The card number, mothers details, childs details and birth details, are sent to the Govt, e.g. the Department of Home Affairs.

Cross-block flow diagram (level 5)

Open

See https://www.websequencediagrams.com/ for an editable diagram

Payments - Postpartum and Infant Care

Assumptions:

The mother and HC worker both own mobile phones.

## Smart phones. HC worker doesn’t need to own, only to have access to a smartphone

See DIAL Catalog of Digital Solutions for the DIAL use cases

A complete process checklist can be found here: https://docs.google.com/spreadsheets/d/1_mU6HNGuiMciZhxKMHUaucyAjqy9Acrf/edit#gid=832614800

Preconditions

HC worker must have an account on the postpartum registry system

HC worker has a mobile phone to access the system

Identify Main Beneficiary

1. HC worker logs into the postpartum payment registry system

via single sign on via their mobile phone

2. Mother presents program membership ID card to the HC worker, e.g. barcode

HC workers have access to minimal required data for the purposes of filling out this application. The list of mothers is appropriately scoped to the access of the HC worker, according to local laws and policy. All access will be audited and logged.

3. Capture details for the Mother

Capture data to verify the mother and prevent fraud per legal requirements, for processing later.

Eligibility verification

4. Confirm application eligibility

4.1 Validate the mother has completed all steps (visited a pediatrician, procured medicine and nutrition supplies, and visited the therapy center.) This is done by connecting to the MCTS registry.

In case electronic record verifications are not accessible Health worker may fall back to validate printed records (such as prescription,etc)

4.2 Verify mother has no pending incentive voucher for this milestone? (from the MCTS registry)

(electronic check lists could be ticked by different building blocks on completion of respective milestones in a pub-sub model)- Push or Pull (as a fall back mechanism) -(to check the milestone logs from different systems at this point)?

4.3 Ask HC worker to certify that all steps have been completed

Using a signature and a tick box

Determine Benefits

5. Determine payment amounts for HC worker and mother

All requirements put forward by the program are collected by the registration process and used to compute payments.

These are computed by an external system. They can’t be changed by either the HC worker or mother.

Execute payments

6. For the mother, a cash payment is given via a paper payment voucher

A voucher is printed by the HC worker. It includes a QR code and human-readable data to allow verification of the payment. The voucher expires after one year, so mother must request another voucher if the previous one wasn’t redeemed.

The mother’s details is assumed to be managed at the registration BB to ensure that only one registration is done.

7. Redeeming the voucher

• The merchants will need to be registered with the payment disbursement agency.

• An OpenAPI is needed for large merchants who will need to integrate their systems with the Voucher management system.

• Decisions need to be made about partial fulfillment scenarios.

• Case mgt scenarios need to be developed for scenarios of merchants not supplying the goods, faulty goods or pricing errors.

Voucher payments may follow the flow below:

The voucher issuing flow is shown in the diagram above.

1. An external Building Block may invoke the Payment BB API gateway to pre-activate API on the Voucher Management Server with the amount of the voucher, the voucher currency and the voucher group. The calling block may optionally send a comment. The comment will be stored by the voucher server. The voucher group will indicate that it is looking for a voucher from a specific voucher group. This API call will be made through the payment orchestrator.

2. The voucher group is typically used for the conditional social transfer (e.g. for school fee payment). If any voucher can be used for any purpose, then all vouchers should be created with a generic voucher group (e.g. “GENERAL-PURPOSE”).

3. The API returns to get a voucher number, the voucher serial number and its expiry date. At this point the voucher will be flagged Pre-Activated.

4. The calling Building Block may render the voucher as a QR code, as a barcode or even an SMS text. It is recommended that the voucher should include supplementary data of the recipient. It is also recommended that this data should also be printed in human readable form so that the recipient can verify the data on the voucher. This data can also be verified at the point of redemption.

5. Once the calling API successfully prints / issues the QR code, the voucher can then be activated using the activation API. It is assumed that there will not be a substantial delay between pre-activation and activation to necessitate the need for multiple expiry periods.

Mobile Money individual Disbursement Flow

1. This flow assumes that the disbursement agency has pre-funded the mobile money provider for the amount of the transaction or there is a bank-to-wallet integration in place to facilitate the transfer of funds from the Disbursement agency account to the Mobile Money Provider (MMP)

2. The Disbursement organisation submits the request for processing to the MMP. The MMP will return the request state object indicating that the request is pending

3. The MMP processes the disbursement to the account holder and informs the organisation that the disbursement has been successfully completed by returning the final representation of the transaction

4. In case of failure the MMP informs the disbursement organisation that the disbursement has failed and returns the error object detailing the reason for failure

8. For the HC worker, a batch payment is scheduled after the mother has been given her voucher

Bulk payments are done monthly

A .csv file is generated with mobile number and amount

The .csv is uploaded securely to a payment provider

9. Record payment status and amounts in registry

Below are three scenarios described in diagram format.

High Level FLOW

This process is kicked off by the Ministry of Health.

Bulk Payment flow process.

Bulk Payment Flow Process - Mobile Money

1.This flow assumes that the disbursement agency has pre-funded the mobile money provider via a direct bank-to-wallet transfer or via an aggregator / gateway.

2.The Disbursement organisation submits the batch of transactions for processing to be processed by the Mobile Money Provider (MMP)

3.The MMP processes the disbursement to the account holder and informs the organisation that the request has been completed by returning the representation batch

4.The Disbursement organisation can retrieve a representation of the batch transaction that will confirm the overall success of the approval request

5.The disbursement organisation can request details of all transactions in the batch that have been completed

6.The disbursement organisation can request details of all transactions in the batch that have been rejected

Case Management - Postpartum and Infant Care

See https://solutions.dial.community/use_cases/postpartum_and_infant_care/use_case_steps/pediatrician_visits for the original DIAL use case

A complete process checklist can be found here

Logical process checklist - case management - postpartum and infant care.xlsx

Preconditions

• Caretaker and Child have been registered in the MCTS

• Caretaker has a program membership ID card for their Child

• Child has been scheduled for an appointment with a pediatrician

• Caretaker may provide existing paper healthcare records to the HC worker

• HC worker has authentication tokens and authorization to access MCTS and healthcare record systems

Access and study the baby’s EHRs

1. HC worker logs into the MCTS registration system

via single sign on via their mobile phone

2. Caretaker presents program membership ID card to the HC worker

3. HC workers have access to minimal required data for the purposes of completing this process.

The list of caretakers is appropriately scoped to the access of the HC worker, according to local laws and policy.

All access will be audited and logged.

The audit log must be accessible to the caretaker.

Update the information and findings in the child’s MCTS record

4. The HC worker may read information from the child’s health records registry.

5. The HC worker updates prescriptions for medication

The fact that medication was ordered is updated in the MCTS record

6. The HC worker updates prescriptions for tests

Upload and scan paper records needed for appointment if necessary

7. The HC worker updates prescriptions for nutrition

Upload and scan paper records needed for appointment if necessary

8. The HC worker updates prescriptions for immunization

Upload and scan paper records needed for appointment if necessary

9. The HC worker updates prescriptions for therapy

Upload and scan paper records needed for appointment if necessary

The HC worker helps the mother access the information

10. Book appointments for future immunization, therapy, tests and follow-up visits

The HC worker may schedule appointments on the mother’s behalf with consent.

For each appointment, there may be prerequisites, e.g. a first immunization must come before the second.

For each appointment there may be prerequisite instructions for the appointment itself, e.g. come with an empty stomach. These instructions may come from the service provider.

For each appointment, a reminder should be sent to the mother with prerequisite instructions (e.g. come with an empty stomach) for the appointment.

Postconditions

Mother has one or more followup appointments for future immunization, therapy, tests and follow-up visits scheduled

Mother will receive automatic reminders for any scheduled followup appointments

System has registered followup appointments

System has registered and updated the mother and child’s MCTS records

All operations done by the HC worker are recorded in an audit trail

Registration - Unconditional Social Cash Transfer

Here is the DIAL use case: https://solutions.dial.community/use_cases/unconditional_social_cash_transf/use_case_steps/registration

See https://openknowledge.worldbank.org/bitstream/handle/10986/34044/9781464815775.pdf?sequence=9&isAllowed=y page 41 for an overview of the overall process.

TODO: add a revision history table?

A complete process checklist can be found here:

Logical process checklist - Registration - Unconditional Social Cash Transfer.xlsx

Preconditions

1. The outreach communication to an individual or family has happened

2. The admin has authentication to the registration screen flow application

3. The admin has authorization to access potential candidate records

4. The request from a potential beneficiary is inbound, either by calling into or visiting the office in person

1. The admin logs into a Registration - Unconditional Social Cash Transfer screen flow application

Via single sign-on on their desktop PC at work

2. The admin searches the Registration - Unconditional Social Cash Transfer registry for the potential beneficiari(es) based on information provided as part of the inbound request by a potential beneficiary

Either an individual or a family

3. The admin may create a new registration record if none exists for for the potential beneficiary

4. The admin verifies the potential beneficiary is correct based on details provided by the potential beneficiary

E.g. beneficiary provides identity documents or phone number and the admin makes a judgement call that the beneficiary is who they say they are.

(What are the minimal data captured? What is required by law as the minimal eligibility criteria?)

5. During enrolment, further data can be collected by the admin (depending on programme design) e.g. bank account details, biometrics, etc.

Also, address, employment data, other family members, etc.

(The system must be flexible enough to capture any data needed per legal and programme requirements)

6. Optional: Admin issues a family program membership ID card, e.g. barcode

Further information is exchanged and, in certain program design or context, beneficiaries are issued with a programme card (depending on system setup by country).

6.1 Capture Card Details

A pre-printed card is issued to the potential recipient for future reference. The card details are captured in the system.

6.2 Assign Card to Family

The potential recipient confirms the receipt of the card.

7. Optional: Programme specific data is often entered into a separate Beneficiary Registry associated with a Beneficiary Operations Management System (BOMS)*.

8. Non-eligible households are also contacted and informed, depending on program and context.

9; Enroll beneficiary in program based on list from OpenIMIS.

10. OpenIMIS calls back with a beneficiary ID, payment amount and date for scheduled payment.

Postconditions

1. The potential beneficiary is registered in the SRIS (Social Registry)

2. The potential beneficiary’s needs have been assessed and required details captured by the Admin

Payment - Unconditional Social Cash Transfer

UC-P-USCT-001: Payment - Unconditional Social Cash Transfer (bank payments)

UC-P-USCT-002: Payment - Unconditional Social Cash Transfer (non-electronic/cash payments)

UC-P-USCT-003: Payment - Unconditional Social Cash Transfer (direct payment based on family relationship)

Eligibility Determination and Benefit Package(s) Design - Unconditional Social Cash Transfer

UC-E-USCT-001: Eligibility Determination and Benefit Package(s) Design - Unconditional Social Cash Transfer

Data Verification and Validation - Unconditional Social Cash Transfer

UC-ADV-USCT-001: Automatic Data Verification and Validation - Unconditional Social Cash TransferUC-MDV-USCT-001: Manual Data Verification and Validation - Unconditional Social Cash Transfer

RURAL ADVISORY SERVICE FOR FARMERS

REGISTERING TO THE RURAL ADVISORY SERVICE

Here is the DIAL use case: https://solutions.dial.community/use_cases/rural_advisory_service_for_farme/use_case_steps/registering_to_the_rural_advisor

Preconditions

1. Information about rural advisory services is promoted using digital media such as radio

2. Subscribers can download a mobile app from an online repository (e.g. App Store). There is another service, which is a SMS & Voice based advisory service, available to the subscribers of a particular Mobile Network Operator. Since Pendo did not have a smartphone, she wanted to try the service offered by the mobile operator.

User Stories

1. Farmer buys a SIM card and then activates the Rural Advisory Service

Pendo activates the service by dialling USSD (Unstructured Supplementary Service Data) code (*123*#). She immediately receives a message that she has been successfully registered to the Rural Advisory Service.

UC-REG-RAS-001: Dial USSD code- RURAL ADVISORY SERVICE FOR FARMERS

UC-REG-RAS-002: Activate the Rural Advisory Service- RURAL ADVISORY SERVICE FOR FARMERS

2. USSD System requests farmer to provide personal information.

After registration, Pendo receives a welcome call from the mobile network operator. The call was an Automated Voice Call, in which a pre-recorded voice message in local language Swahili explained about the key functionalities of the service and requests Pendo to provide simple information about her gender, age, size of farm etc. by key press. Pendo completes her profile.

UC-REG-RAS-003: System calls the farmer via USSD service- RURAL ADVISORY SERVICE FOR FARMERS

UC-REG-RAS-004: Add additional personal information via USSD service- RURAL ADVISORY SERVICE FOR FARMERS

3. User enters registration information in the USSD service.

After this she gets a USSD Notification with a menu to select crops. She selects Maize, Sorghum, Sweet Potato and Poultry.

UC-REG-RAS-005: Register for push notifications in USSD service- RURAL ADVISORY SERVICE FOR FARMERS

4. Farmer receives a SMS Message confirming that registration is complete

and she will soon start getting advisory messages five times in week. Along with information about the crops of her choice, she will also get local weather forecast and market price updates.

UC-REG-RAS-006: Receive registration confirmation messages in USSD service- RURAL ADVISORY SERVICE FOR FARMERS

Postconditions

Ideas for extending functionality later

Registration - social cash transfer:

Extend Postpartum and Infant care to more explicitly provide care to the mother - or remove the word postpartum

In the future, we need to consider which messages are published by which blocks, e.g. registration has been completed for a new person.

We need to capture alternative ways of disbursement: bank accounts, cash, payment vouchers, USSD, etc.

Where do we park the shared capability of doing data transformation between formats?

In case mother has lost payment voucher fork a separate process to handle reissue of voucher. Not covered here.

We should consider training as another appointment, which is usually done in groups. See https://solutions.dial.community/use_cases/postpartum_and_infant_care/use_case_steps/visit_to_the_therapy_centre for details on this step.

Security BB Processes

Identity and Access Sequences

The following sequence diagrams depict the basic means by which role based access control shall be implemented across building blocks. Note that by definition an account with no access can be created by any user. Access is determined through workflow upon application for service access based on role grant. At this stage there is no assumption regarding the responsibility for granting roles other than that a workflow needs to be initiated and additional verified and validated documents may be required along with approval by one or more parties during the workflow. Such workflows can be articulated during the detailed design phase:

See https://app.diagrams.net/ for an editable diagram

See https://app.diagrams.net/ for an editable diagram

API Management Sequences

The sequence diagrams below shows examples of how a building block might interact with the API Management and Gateway solution. This is only relevant for the API Management and Gateway services in the context of the security building block. A higher level sequence diagram depicting API interactions for building blocks is depicted and documented in Architecture Blueprint and Functional Requirements (see Ref 1).