Use Case Step | Use Case: PostPartum and Infant Care, Step: Registration (provide link to UC when complete) |
Preconditions (list of conditions that MUST be met in order to be able to successfully execute this process) |
|
Data inputs |
|
Actors (the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Government-accredited health worker, A woman who has delivered her first baby System:
|
Normal Course (what happens if the event is triggered and the preconditions have been met) | The registration form screen for the MCC application provides a list of initial details required to proceed with the registration (eligibility verification, required documents, required fees).
Feature: Get Consent Agreement Scenario: MCC Application retrieves Consent Agreement for Mother Given an Agreement for MCC user registration exists in Consent BB And MCC Application has MCC application has Mother's <ID> and authentication token for the registration session When MCC application fetches a Consent Agreement for MCC user registration Then MCC application gets a valid Draft Consent Agreement associated with Mother's ID
3. The health worker (via MCC Application) introduces to the Mother the Consent Agreement for fetching the relevant details from the Population registry for verification and appropriate use with the MCC and captures signature to the Consent Agreement from the Mother. Feature: Sign Consent Record Background: Given MCC Application has the Draft Consent Agreement associated with Mother's ID And MCC application has Mother's <ID> and authentication token for the registration session And Mother has read the Draft Consent Agreement And Mother approves to sign the Draft Consent Agreement associated with Mother's ID Scenario: Sign Consent Record on Paper Given MCC application has captured the consent in a digital form (for example: scan of a paper form) When MCC sends digital Consent Record payload to Consent BB Then Consent BB digitally signs Consent Record And Consent BB confirms to MCC Application that Consent Record for Mother has been successfully signed Scenario: Sign Consent Record Digitally Given Mother has capability to sign Consent Record digitally When MCC sends the Draft Consent Agreement to Consent BB Then Consent BB creates a paired ConsentRecord and Signature object And Consent BB digitally signes Consent Record And Consent BB confirms to MCC Application that Consent Record for Mother has been successfully signed
This scenario uses a set of features:
Feature: Verify Consent Record MCC Application verifies if Mother has signed Consent Record to fetch the needed personal data from Population registry for MCC user registration Scenario: Retrieve valid Consent Record Given Mother has Signed Consent Record stored in Consent BB When MCC Application makes the request to population registry API to fetch Mother's personal data Then MCC Application makes prior request to Consent BB API to retrieve Mother's Signed Consent Record And Consent BB sends the signed Consent Record to MCC Application
Feature: Imports client personal data from a registry Import Mother's pesonal information from Population Registry to the e-service form Given Mother has entered <ID> in the Registration e-service registration form, national ID number field And MCC Application has received Signed Consent Record from Consent BB When the MCC Application user pushes a button "Import Mothers's information" Then the MCC Application makes a request to Population Registry API And Population Registry returns requested data to MCC Application And MCC Application fills the form on the screen with Mothers data <ID>,<first>, <last>, <birth> Examples: |ID|first|last|birth| |53|Sowmya|Krishnamurti|2022-11-01| curl -X 'POST' \ 'https://gdb.er3.ext.egovstack.net/data/crs/2.9/read' \ -H 'accept: application/json' \ -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJHOFhwMFNhUko3U1RBSkJvZGpFSjhVb3FnUXozZTVoQng1SEJXcXhfV3BZIn0.eyJleHAiOjE2Njg3NTcxNDYsImlhdCI6MTY2ODc1Njg0NiwiYXV0aF90aW1lIjoxNjY4NzU0OTk5LCJqdGkiOiI5MDkwYjM0Ny1hMTAxLTQ3ODQtYTFlNy1kZWM4YTdlZGI1NTkiLCJpc3MiOiJodHRwczovL2xvZ2luLmVyMy5leHQuZWdvdnN0YWNrLm5ldC9hdXRoL3JlYWxtcy9DSCIsImF1ZCI6WyJyZWFsbS1tYW5hZ2VtZW50Iiwic3RhdGlzdGljcy1iYWNrZW5kIiwic3RhdGlzdGljcy1mcm9udGVuZCIsImJwYS1iYWNrZW5kIiwiYnBhLWZyb250ZW5kIiwiYWNjb3VudCJdLCJzdWIiOiI2OTY4NzVmNi1iNjI1LTQxYzQtODgzMi1kMjRkZTE0Mzg3YzgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJnZGItY2xpZW50Iiwic2Vzc2lvbl9zdGF0ZSI6IjkwYjYyYmFkLTExMDctNGQ1Mi05YzRmLWVhMWRlMzE2NzRiNyIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9nZGIuZXIzLmV4dC5lZ292c3RhY2submV0Il0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJEcmFmdCIsImRlZmF1bHQtcm9sZXMtY2giLCJzdXBlcl9tYXJpbyIsInBhcnRiIiwib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiIsInN1cGVyaW5zcGVjdG9yIiwic3lzYWRtaW4iXX0sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJtYW5hZ2UtdXNlcnMiLCJ2aWV3LXVzZXJzIiwibWFuYWdlLWNsaWVudHMiLCJxdWVyeS1ncm91cHMiLCJxdWVyeS11c2VycyJdfSwic3RhdGlzdGljcy1iYWNrZW5kIjp7InJvbGVzIjpbInN0YXRzIl19LCJzdGF0aXN0aWNzLWZyb250ZW5kIjp7InJvbGVzIjpbInN0YXRzIl19LCJicGEtYmFja2VuZCI6eyJyb2xlcyI6WyJCUEEiXX0sImJwYS1mcm9udGVuZCI6eyJyb2xlcyI6WyJCUEEiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoib3BlbmlkIGVtYWlsIHByb2ZpbGUiLCJzaWQiOiI5MGI2MmJhZC0xMTA3LTRkNTItOWM0Zi1lYTFkZTMxNjc0YjciLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwibmFtZSI6IkluZ21hciBWYWxpIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiaW5nbWFyLmdvdnN0YWNrIiwiZ2l2ZW5fbmFtZSI6IkluZ21hciIsImZhbWlseV9uYW1lIjoiVmFsaSIsImVtYWlsIjoiaW5nbWFyLnZhbGlAZ21haWwuY29tIn0.cIRdyN1v7am_8NAm_4Arg825bET3Kv-JqQLjneAVZvfCo5s0v8KRpZEYsHp6-ryRBjELBgieou7pgeEwEtXwKv3HT1pDgRFdE1Uab2y1tFLrpmkhae7p9QITC7YDNLRfWRuyEtlC5pqK_n-noyTGuCjlx4zfPX2ViNKyQbrCgWtcsEUQBH2Xlelq5Miv6yYqeCG0YYsK44NGK76M0OxwFtZjCAIOQH2_6RbdKi81omE42uAvZDaNICcXfpg1S5bM7n6CdsxTajeFjZYjxwHzCQt6kuXlZ-rEOFLTxtt3wRUVWVhmjKW41drX82ojN69_VE3mzU1gCNqQVCwBTLK6qA' \ -H 'Content-Type: application/json' \ -d '{ "query": { "content": { "National ID": "53" } } }' In response, the Govstack IDBB/ Digital Registries BB is expected to return the following: { "receive": { "content": { "ID": "0409CC96-700A-4FB9-A22C-F56DC8A03BC1", "Father": { "Last names": "", "First names": "", "National ID": "" }, "Gender": "Female", "Mother": { "Last names": "Riisikas", "First names": "Usha", "National ID": "47" }, "Birthdate": "2022-11-01", "Full name": "Sowmya Krishnamurti", "Last names": "Krishnamurti", "First names": "Sowmya", "National ID": "53", "Nationality": { "key": "EST", "value": "Estonia" }, "Nationality key": "EST", "Nationality value": "Estonia" }, "created_at": "2022-11-18T07:37:34.678816Z", "modified_at": "2022-11-18T07:38:00.239776Z", "uuid": "6e5ea0ad-c990-40d9-be4b-d152f7ede16f" } }
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) | Description of alternate paths or flows that may be needed for this example implementation. These alternates should include links to test files, APIs, and data structures as well |
Data output |
|
Post-Conditions (the success criteria) |
|
Exceptions (error situations) | List of error conditions that may be encountered during the normal or alternative flows. Each error condition should provide information on what data will be returned and guidance on how error conditions should be handled by various actors. |
Related BBs (working groups related to that particular use case) | Identity BB Consent BB Registration BB Digital Registries BB Payment BB |
Sequence Diagram | Embedded image and link to sequence diagram showing interactions between various actors |
General
Content
Integrations