This section shows possible sample implementations, such as Issuing Birth Certificate; Appointment Booking With a Health Care Worker
This is a high-level overview of how the Messaging BB acts internally, but also to cover the expectation for a third party to deliver requests (to and from).
This is a Use Case Table to cover providing a birth certificate to a child.
Name
Messaging – Birth Certificate to Children
Description
The use case explains the implementation of the messaging for the birth certificate to minor children.
Main Benefits
1. Provides permanent and official record of a child’s existence.
2. Provides right to an official identity, a recognized name, and a nationality.
3. Provides essential element of national planning for children since it provides a demographic base.
Trigger
(the event that triggers the use case)
The birth registry at hospitals/municipalities-driven.
Citizen-driven and digital application.
Citizen-driven and paper-based application.
Preconditions
(list of conditions that MUST be met in order for the use case to be successful)
The application admin/user is logged into the system and has sufficient privileges to use the system.
A Messaging Policy exists and is based on existing electronic data handling laws and regulations.
Registry of birth exists for digital processing.
Workflow for processing of birth verification and certificate attestation exists.
Assumption: Parent/Guardian is in possession of a digital communication device and an application, capable of receiving and sending messages.
Assumption: The messaging is happening in the language of comprehension for the user.
Assumption: Government/GovStack implementation has Building Blocks namely Identity and Authentication, Registration and Workflow in operation.
Assumption: Government/GovStack implementation has web and mobile-supported technologies such as Push/Pull SMS, IVRS, Mobile-enabled Web Interface, Mobile App, etc.
Data inputs
Registration Details
Application Form Details
Required Documents
3.1 A copy of the birth proof
3.2 A copy of the passport of both the parents
3.3 A copy of the certificate of citizenship if acquired by registration/naturalization
3.4 A copy of the marriage certificate of the parents
3.5 Declaration letter that the child does not hold the passport of any other country
3.6 Scan the documents in PDF format
3.7 Each document can have multiple pages
3.8 The size of each document should not exceed 1 Mb (illustrative)
4. Image
4.1 Passport size photo of the applicant
4.2 Image Dimension of Photograph should be 100(Width) * 120(Hight) Pixel only (illustrative)
4.3 Size of the scanned image is not more than 20kb (illustrative)
4.4 Uploading image should be in jpg format only (illustrative)
4.5 Use the Picture manager for resizing the image
Actors
(a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)
The application admin/user who configures the messaging policy (A person, IT admin).
Applicant (A person, Citizen).
Maker/Checker/Approver (A person, Government/Authorized official).
The birth certificate provider application (A computer system).
Auditors (A person, or an independent authority).
Registration Block –Birth Registry, Marriage Registry, etc. (A computer system).
Identity and Authentication Block for checking the Identity of the applicant, parent (A computer system).
Workflow Block for rule-based processing (A computer system).
Email for communication (A system).
Mobile – Push/Pull/IVRS/USSD/App (A system).
Web Application (A computer system).
Normal Course (what happens if the event is triggered and the preconditions have been met)
Acknowledgment message for receipt of application.
Birth certificate approval message.
The Messaging Building Block application user can invoke the identity and authentication Building Block, registry Building Block and workflow Building Block for e-auth (electronic authentication), birth entry, and rule-based processing respectively.
Alternative Course
(links to other use cases in case there are different ways how to solve the same use case)
-
Data output
The messaging Building Block can send a message to applicants through email or SMS. The types of message(s) include:
Acknowledgement of application receipt;
Application progress status;
Duly signed Birth certificate.
Post-Conditions (the success criteria)
The conformance check including metadata and data standard validation of the message is done.
The exceptions are communicated to the system (through error code and message) and to the user through message.
The accepted message is passed on to the Workflow Building Block, which in return, may make use of Registration, Identity, Security, and Consent Building Blocks.
The system is configured and ready for routing messages during a workflow.
User feedback is taken on messaging and factored in.
Exceptions
(error situations)
In case of any configuration change in messaging or any error in the processing of messaging:
1. An error message is displayed and communicated back to the system that made the request.
2. An error message is communicated in easy-to-understand language to the impacted user.
Related Building Blocks
(related to that particular use case)
Identity Building Block - for acquiring authentication token.
Workflow Building Block – for workflow management.
Registries Building Block – for storing the data.
Information Mediator Building Block - providing interfaces and publishing the Building Block services, routing policy, etc.
Security Building Block – for supervision and safety.
Consent Building Block - for using personal data.
Payment Building Block – for making delayed payment.
Messaging
Examples
Sample Message – Email for user registration
User XXXX has been registered successfully.
User ID: XXXX
Please click here to reset the password or copy the link to your browser
<weblink>
Sample Message – SMS for birth certificate approval
Birth Certificate Approved, please make a note of Acknowledgement Number for Future Reference '1202117XXXXX'—Govt. Organization Name.
Best Practices
Birth certificate in Digital Locker
Digital Locker to provide lifelong access to authentic digital documents to citizen’s digital document wallet. The issued documents in Digital Locker system are deemed to be at par with original physical documents as per rule.
This is a Use Case Table to cover the process of confirming an appointment booking when using health services.
ID
Description
Name
Messaging – Appointment booking confirmation for health services.
Description
The use case explains the implementation of the Messaging Building Block for the confirmation and acknowledgment of appointment booking of health services.
Main Benefits
1. Provides a clear and accessible path for citizens to confirm appointment booking through different digital messaging channels (SMS, email, WhatsApp, Voice message, etc.);
2. Provides transparency for the citizens that need to move to a health facility to consume services;
3. Provides efficient usage of the health services by occupying booking slots accordingly to the demand.
Trigger
(the event that triggers the use case)
Citizen registers an appointment booking through digital messaging channels.
Citizen-driven and digital messaging channels.
Preconditions
(list of conditions that MUST be met in order for the use case to be successful)
The application admin/user is logged into the system and has sufficient privileges to use the system,
A Messaging Policy exists, based on existing electronic data handling laws and regulations.
Citizens are previously registered.
Workflow for registering an appointment booking exists.
Assumption: Parent/Guardian is in possession of a digital communication device and an application, capable of receiving and sending messages.
Assumption: The messaging is happening in the language of comprehension for citizens.
Assumption: Government/GovStack implementation has Building Blocks namely Identity and Authentication, Registration and Workflow in operation.
Assumption: Government/GovStack implementation has web and mobile-supported technologies such as Push/Pull SMS, IVRS, Mobile-enabled Web Interface, Mobile App, etc.
Data inputs
Citizen Registration Details;
Message minimal data such as Unique Material Identifier (UMID), content, policy, and priority.
Actors
(a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)
The application admin/user that configures the messaging policy. (A person, IT admin).
Applicant (A person, Citizen).
Scheduler Block for setting up events that triggers a message (A computer system).
Registration Block – Birth Registry, Marriage Registry, etc. (A computer system).
Identity and Authentication Block for checking Identity of an applicant, parent (A computer system).
Workflow Block for rule-based processing (A computer system).
Email for communication (A system).
Mobile – Push/Pull/IVRS/USSD/App (A system).
Web Application (A computer system).
Normal Course (what happens if the event is triggered and the preconditions have been met)
Acknowledgment message about an appointment booking with the information given by the input;
Citizen answers the message about the appointment booking;
Messaging Building Block application delivers the citizen input to the Workflow Building Block that handles it properly.
Alternative Course
(links to other use cases in case there are different ways how to solve the same use case)
-
Data output
The Messaging Building Block can send and receive messages from citizens through different communication channels, and keep the status of the delivery along with metadata about it.
Post-Conditions (the success criteria)
The conformance check including metadata, data standard validation of message is done.
The exceptions are communicated to the system (through error code and message) and to the user through message.
The accepted message passed on to the Workflow Building Block, which in return, may make use of Registration, Identity, Security, and Consent Building Blocks.
The system is configured and ready for routing messages during a workflow.
User feedback is taken on messaging and factored in.
Exceptions
(error situations)
In case of any configuration change in messaging or any error in the processing of messaging:
1. An error message is displayed and communicated back to the system that made the request.
2. An error message is communicated in easy-to-understand language to impacted users.
Related Building Blocks
(related to that particular use case)
Identity Building Block - for acquiring authentication token.
Scheduler Building Block - for scheduling events.
Workflow Building Block – for workflow management.
Registries Building Block – for storing the data.
Information Mediator Building Block - providing interfaces and publishing the Building Block services, routing policy, etc.
Security Building Block – for supervision and safety.
Consent Building Block - for using personal data.
Messaging
Examples
Sample Message – Appointment Booking Confirmation XXXX, can you confirm an appointment booking for the service ZZZZ scheduled for YYYY? (Answer with YES to confirm or NO otherwise).
Sample Message – Appointment Reminder XXXX, you have an appointment booking confirmed for YYYY, make sure to be prepared for the event as follows: ZZZZ.
Best Practices
The content of the messages may have as much information as possible to the citizen but respecting the restrictions of the communication channel used such as the content length of messages;
The frequency of the confirmation messages should take into consideration the regulations of each country to avoid blacklisting a communication channel considered spam.
This is a Use Case Table to cover the process of sending alert messages.
Name
Messaging – Alert
Description
The use case explains the implementation of the messaging for alerts especially alerts linked to cyclone disaster management.
Main Benefits
1. Prevent the loss of lives (human and animal) and livelihood.
2. Coordinated efforts for previous, during, and post-disaster events.
Trigger
(the event that triggers the use case)
Early warning on cyclone.
Early warning on a flood.
It can be customized for warning on landslides and/or earthquakes.
It can be tailored and customized for alerts on banking and covid/healthcare.
Preconditions
(list of conditions that MUST be met in order for the use case to be successful)
The application admin/user is logged into the system (mobile, computer, TV, and/or Radio) and has sufficient privileges to use the system,
A Messaging Policy exists and is based on existing electronic data handling laws and regulations.
Common Alert Protocol is in place for synergies among Government Institutions.
Early Warning System is in place.
Observation is available from space (satellites), upper air (Balloon, Radar, Aircraft), and surface (Automatic Weather Station, Automatic Raingauge Station, surface synoptic observations, etc.).
Language translation system and moderator are in place.
Workflow for processing disaster-related data exist.
Assumption: Government Agencies and Residents are in possession of a digital communication device and an application, capable of receiving and sending messages.
Assumption: The messaging is happening in the language of comprehension for the user.
Assumption: Government/GovStack implementation has Building Blocks namely Identity and Authentication, Registration and Workflow in operation.
Assumption: Government/GovStack implementation has web and mobile-supported technologies such as Push/Pull SMS, IVRS, Mobile-enabled Web Interface, Mobile App, etc.
Data inputs
Warning Message for disaster.
What-to-do Message regarding pre-, during, and post-disaster.
Language localization of message.
Friendliness of messages towards disabled people.
Mobile and Email Database.
Geographical and location-based targets for alert messages on a disaster.
Directory of Telecom Service Providers, Social Media Influencers, Government Institutions, Language Translators.
Actors
(a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)
The application admin/user who configures the messaging policy (A person, IT admin).
Message consumer (A person, Resident).
Government Agencies (Institutions).
Language Translation Moderator (A Person, Expert).
Early Warning System.
Email for communication (A system).
Mobile – Push/Pull/IVRS/USSD/App (A system).
Web Application (A computer system).
TV, Radio, social media (A system).
Normal Course (what happens if the event is triggered, and the preconditions have been met)
Message to Government Institutions through Email, Telephone, Police Wireless, or Website.
Message to the Public through Email, SMS, Radio, TV, social media, Newspaper (Electronic & Print Media), or Website.
Message to marine through NAVTEX (NAVigational TEleX), Telephone, Telefax, or Broadcast.
Alternative Course