Future Considerations (Registration)

It seems, that specification currently focus only onto very simple registration cases and do not consider more complex processes, for example like financial services licensing.

Yes, the GovStack methodology is to focus on functionality needed for Use Cases assigned (Mother and Child registration program, Postpartum infant care). However, it is not hardcoded, therefore any process (including financial services) can be processed.

The functional specification allows to create e-services involving multiple registrations and multiple entities from any domain.

However, Digital registries BB looks to me like DBMS specification. For example, PostgreSQL or ORACLE RDBMS are well fit to the Digital registries BB specification. My point is that if I will try to implement some registration process, for example, in Ukraine, where I recently were engaged, I do not see much added value from the set of two specifications.

Digital Registries is separated BB because not all Registration processes need a new database/registry. Registration BB and Digital Registries BB can operate as one or it can be separated into multiple functional BB-s. We decided to split the functionality in order to simplify the reading. If the Registrations BB is not suitable for your processes in a country in focus, then we could use your requirements for validating our BB specification. Additional requirements can be added in the next iteration when new Use Cases are added.

The document is at a high level and doesn't make clear how a developer can take these specifications and implement.

This is meant to be a guideline and not a technical spec such as a SRS (Software Req Specification). Developers can choose to implement best dev. practices and ensure compliance with defined API-s and functionalities here. With new Use Cases we can add more flesh to the skeleton.

Should be a registration API, without needing to use the identified application

However, somebody needs to define the UI functions for the Registration BB. Without the UI the no-code principles do not work. Technically the UI and API- in the back can be separated.

In countries with existing interoperability platform there is an option that some documents, which are needed for registration can be obtained from other state agencies. For example, 15 y.o. child wants to go on competition with national team from Ukraine to Turkey. To cross a boarder with team coach the child should have authorisation from parent. In Ukraine in such situation parent go to Notary and Notary system can automatically lookup from Civil (Population) Registry the fact that the person is indeed a parent of a child. That means that the development platform should have a Transformer to build an adapter, which provides connectivity from the registration workflow to external state or even private sector organisation to lookup for evidences, which are needed for registration.

Back office system registers all applications submitted. If configured so, the process flow may have bot(s) and human(s) in the flow. Bot roles process applications by validating information against external API information. When processed the BOT role will pass the processing task to the next role. Requirements can be extended during next use cases.

One subcomponent here should be a component to create requests to third parties and prepare adapters for receiving responses. That would support the Once-Only principle: a person should not submit to registrar information, which already exists in some other state agencies.

The function that you seek is part of UI and flow builder (Mapping). See BOT function described in requirement SF-7. We will add more requirements on this function in the next phase. It may be a separate module or even BB.

There are situations, when workflow registration is one organisation and the result of registration goes to a Registry, which is different organisation. For such cases there are should be capabilities to define external messaging.

​

Yes, there are two options for this:

1. 1.Use Roles to process the application inside the same BB web user interface for external operators (SF-3).

2. 2.Use Data bots to send data/validate to external endpoints (BB-s). Bot roles process applications by validating information against external API information. When processed the BOT role will pass the processing task to the next role.Although, some additional requirements may be needed to communicate with the Messaging and Workflow BB. This functionality can be described in the next iteration. Decision- will be added to the Future consideration chapter.

I do not see any requirements regarding layout of forms. This is simple license UI prototype, which has 29 pages in 4 sections: 2 sections for the self-service part and 2 parts for back-office processing. I doubt that I will be able to implement those screens using tool, which is only has compliance to those 8 requirements.

Please see requirement SF-1, SF-2 and SF-3. All the requirements explain the functionality how the User Interface will be built by the Analyst. In general the system must facilitate similar business requirements as envisioned in the Axure prototype.

In this document we have envisioned at least four pages/forms (MVP): Guide, Applicant Form, Document upload, payment, Send. In the next iteration we can add functionality to add any number of pages/screens. Decision:

​

will be added to this version- Analyst can add any number of pages to the user screen flow. Done, see requirement SF-1.

SF-7 Does that mean that there is also a tool to define an API request, including to map for fields to request fields and provide URL and authorisation details? Where this tool requirements are?

Yes, Bot action is about API request and mapping of fields. The Open API endpoint mapping must be solved by this BB in order to fulfill the requirement to pull data to the form and to send the data to external endpoints. SF-7 is the only requirement, The rest of the functionality to achieve this must be done by the BB developers. And as the communication is done via Information Mediator, (Pre-requirement) the authorization details are already configured for the Open API endpoints(See Information Mediator BB). Will be added to the specification: Open API endpoint URL defining and API request/response mapping functionality.

5.2 I would suggest to add also service-level management capabilities in the Operator organisation. Management should be able to establish quality requirements on how quickly processing should be done and should be able to monitor fulfilment of established service quality targets.

Service level management is a good idea, we will add it to the future iteration. We can add the objective and measure the performance.

5.2 In complex cases, like for example licensing of financial services, registration process may be quite long process with a lot of interaction between Registrar and Applicant. For such processes there should be capability for bi-directional communication between parties in context of different fields of application.

Asynchronous bi-directional communication between the applicant and operator may be a good addition to the functionality. This will be added to the next iteration.

DS-6 in financial sector licensing process there are may be applications with many persons involved (like directors, MLRO, controllers etc.), who should provide its own input to one application. Such capability for multi-authoring of one application should be also presented.

In this first MVP iteration, there is no such business requirement in the Use Case. However, the multi-authoring functionality for Part A users may be excellent addition to the Registration BB. We will add it to the next iteration.

These specifications do not handle Inclusion issues - Multiple languages, assisted model, differently abled people, etc.

Language of the user interface should be cross-cutting requirement. Will be discussed where to add.

Specification on encryption for data storage - How will the business user specify which fields need to be encrypted?

Will be added in the V2. The business user/analyst can configure the captured data properties and decide the need for encryption in rest state.