10 Other Resources

This section links to any external documents that may be relevant, such as standards documents or other descriptions of this Building Block that may be useful.

10.1 Key Decision Log

A historical log of key decisions regarding this Building Block.

10.2 Future Considerations

A list of topics that may be relevant to future versions of this Building Block.

ANNEX I - Use Case Tables and Component diagrams

Use case table - Birth Certificate to Children

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.

Use case table - Appointment booking confirmation for 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.

Use case table - Alert Message

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 (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 alert messages to concerned institutions and persons. The types of message(s) include: Voice Alert Message · With the help of Telecom Service Providers using Outbound Dialler (OBD) infrastructure in local languages. · With the help of Radio. Text Alert Message · With the help of Telecom Service Providers using SMS. · With the help of an email database. · With the help of social media/website. Image and video alert message · TV. · Electronic and Print Media – Newspaper, Bulletins.
Post-Conditions (the success criteria)	The conformance check including metadata, data standard validation of message, and adherence to common alert protocol 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 turn, may make use of Registration, Identity, and Security. Security Building Block to take care of PI data in a personalized alert message. 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 payments.
Messaging Examples	Sample Message – SMS for cyclone alert Warning! Cyclone XXXXX will make landfall on Xth Day, 20XX. The wind speed may go up to 180kmph. Please stay at home, be safe. Or please go to the nearest cyclone shelter.
Best Practices	· Mass Messaging System. · Universal Communication Interface. · Reliable SMS Code. · Common Alert Protocol. · Warning through SMS (Pull SMS Push SMS). · Mobile App Solution: - Notification through a unified mobile app – UMANG (Unified Mobile App for New-Age Governance). · Voice/text bot. · Warning Through social media: WhatsApp, Facebook, Twitter, and Mobile Apps. · Electronic and Print Media for Publicity and Broadcast of Warning: National/Regional Bulletin, Poster and Films, Radio and TV Talks, and Newspapers. · Mode of Dissemination: FAX, GTS, Email, SMS, FTP, Internet, Website, Telephone, Tale-fax, VHF/HFRT, Radio/TV network, IVRS (Interactive Voice Response System) Toll-Free Number, NAVTEX.

Annex II User Journeys

User journey

User Journey	Use Case	Capability	Functional Requirements	Technical Requirements
Post-partum mother and child care	Mother Registration	Inform the mother about registration through different modalities (SMS[1] , email, WhatsApp, Voice message etc.). See the functional requirements and technical requirements.	Workflow, preconditions such as phone number/contact. The user needs to register/connect its contact data to the Messaging Building Block (mailID, phone no etc)[2] [3] [4] or another Building Block. For example, a) direct MSG Type (Emergency) has concrete API endpoints, blasting all channels/endpoints. Business logic and policy in separate Building Blocks can add MSG type, address: who-to-send-to, MSG channel etc. In reverse communication, a unique identifier is created per user upon registering at the Messaging Building Block.[5] [6] Allowing push and pull models. To be able to understand and apply a routing policy in the particular Application,enabling the Messaging Building Block for routing the Message [7] [8] through specific channels [9] [10] and graceful degradation.	OpenAPI specifications for calling this function; resource models and data structures; [11] internal and external interfaces. Stateless architecture.[12] Microservices require Rabbit MQ; Apache/Kafka or GRPC[13] [14] for data transfer speed purposes. Databases with unstructured data should be treated with Elasticsearch/Logstash. [15] [16] Similarly to the client-to-client pubsub model also the end users can be registered as Message queue clients/subscribers in the Messaging Building Block. Subscription is required to receive a message.[17] [18] The message is put in the queue and communicated to the other Building Blocks[19] [20].
	Mother confirmation of a child registration	Mother receives a confirmation registration message with a token that identifies that event for future interactions.
	Appointment booking	Asking the mother for the booking confirmation of a doctor or vaccination appointment through different communicable channels (SMS, email, WhatsApp, Voice message, etc.).
	Appointment reminder	Reminding the mother about the booking.

Use case table

ID	UC-C-PIC-001
Name	Messaging - Postpartum and infant care (Configuration).
Description	The use case implements configuration of a Messaging Gateway in infant care use case scenarios. This results in a saved configuration to be issued to all mothers requiring infant care.
Trigger (the event that triggers the use case)	The (healthcare) application admin/user wishes to configure the policies and assign user contact details associated with the Messaging service. Any change in the pre-condition that requires a re-configuration.
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. Assumption: The mother is in possession of a digital communication device and an application, capable of receiving and sending messages. Assumption: Government/GovStack implementation has an agreement and API GW with the service providers for transmitting text and voice messages, setting up conference calls.
Data inputs	Existing data policies relevant to the messaging scenario. Contact information of end users accessed in another system or[21] [22] transmitted along the Messaging Request by another GovStack Building Block./Application. Any legal information, standards.
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) The health-care provider application (a computer system). Data Protection Officer, Auditors (A person, or an independent authority). GovStack application (HealthCareProvider Application, Workflow, Information Mediator) triggers a Message to be sent with an appropriate policy metadata. Information Mediator publishes the services of the Messaging Building Block for the other Building Block to use (with available policies). When another Building Block discovers Messaging, it receives X number of policies. Metadata says which policy to pick and where to route it to. Note from the Information Mediator: in order to make your Building Block service available on GovStack, you have to register those services (Open API specs and have a specific business agreement signed between the parties/applications/services).
Normal Course (what happens if the event is triggered and the preconditions have been met)	The Messaging Building Block application user is able to invoke the configuration workflow. The healthcare application user uses the existing Messaging Building Block policy and relevant metadata about the user for registering for postpartum and infant care. This policy could be signed off by the organisation's Data Protection Officer, for example: The data required are: Usage purpose. Data policies and rules. Define what data is being collected. The configuration is saved. Once the DPO approves, the configuration is published toward the end-use case, i.e. Healthcare Professional registration system.
Alternative Course (links to other use cases in case there are different ways how to solve the same use case)	Data configuration error scenarios. Data Protection Officer disapproves and the configuration is re-submitted for review and approval.
Data output	The Messaging Building Block policy configuration data.
Post-Conditions (the success criteria)	The Messaging policy is saved in the system and is published in the Information Mediator, making it available for use in the registration process. The system is now configured and ready for routing messages during a workflow.
Exceptions (error situations)	In case the policy has not been configured, an error message is displayed and communicated back to the system that made the request.
Related Building Blocks (related to that particular use case)	Identity Building Block (Required for acquiring authentication token). Workflow Building Block - workflow management. Registries Building Block - stores the data agreement data. Information Mediator Building Block - providing interfaces and publishing the Building Block services, routing policy, etc. Security Building Block - supervision. Consent Building Block - for using personal data.

Interaction with Scheduling Building Block

Reminder messages, time-based triggers.

Appointment booking confirmation, where there are two levels of confirmation: Immediate confirmation: I have received the message. I have deposited a message, and have given the message a token number. And on the basis of this, I can pick up the message or a reply later. Reminder message is already there and an event will trigger it. Event notification, trigger: for example: please join the call.