Key Decision Log (Registration)

This page documents key decisions that were made about the architecture and functionality of the Digital Registries Building Block

Date	Decision

Date	Decision
31.08.2021	Registration BB and Digital Registries BB is separated into two building blocks.
31.08.2021	The UNCTAD’s eRegistrations system will be used as a reference system as it fulfills most of the BB requirements.
05.12.2021	Additional section “Coverage map” will be added.
05.12.2021	“Coverage map” was moved to section 6.3.
05.12.2021	Infrastructure capabilities added (9.5).
24.02.2022	Review comments incorporated to the main document (see below). Future consideration chapter updated based on reviewers comments. Recommendations not to be considered in this building block documented (see below)

Incorporated in V1
Display, on one or various screens, the necessary fields for the applicant to enter the required data and documents (including a receipt of payment, in case the system does not propose an online payment option or if the user for some reason wants to make the payment physically or directly / in the traditional way).	Text changes added.
9.1 Workflow. such user journey implies ability to test defined forms and workflows, which means that there should test environments and capability to export/import configuration data between different environments. I am not sure that I saw requirements for that in the specification.	Yes, there must be an option to preview the service and to import export service descriptions. Two new requirements added: SF-9; SF-10 In addition there is an optional requirement to enable publishing of services into multiple instances (RE-2).
Also, vocabulary is not consistent. e.g. - Is 'Workflow' the same as 'Case Management'?	Consistency is improved. “Case management” is not a terminology used in this document, it is used to reference to the Dial use cases. Workflow term refers to building block internal workflows (user workflows) and not to the functionality. The term used in the document for functionality of workflow is Flow Builder, roles and Flow
Missing pieces - Queries/ Status/ Monitoring mechanism - How can a citizen query his/her status on the registration process hasn't been specified.	Status/monitoring requirements was added.
Citizen experience due to multiple statuses across departments and applications - If there are multiple processes for multiple applications, the citizens can potentially have many different statuses leading to suboptimal citizen experience. How can these issues be handled using the specifications provided?	Some clarifications made to Requirement DS-1. in general the registration and application status visibility is described.
Registration BB is focusing only onto getting data and not onto using Registry.	The Registration BB focuses both in capturing data and using registry data in the processes and sending it to external API endpoints. We will review the requirement to pull data to the form and rephrase so that it would be more understandable.

Not to be considered

If 2 vendors implement a building block, will the 2 different implementation be interoperable.

Yes, all BB-s are interoperable via Information mediator BB. It is mandatory to use the Open Api standard for communication.

My comment more regarding the first sentence: „A registration may involve

more than two parties: one or more third parties can be requested to assert/confirm the information provided by the applicant (a notary, a family member, a witness, another public entity, or a non-human entity such

as a database);“ because the issuer of the electronic signature /certificate guarantees the identity of the owner of the certificate and in that sense also guarantees financially that the owner of the signature /certificate is the person or entity for which he / she represents himself /herself. In that sense, it belongs to the "third parties" if I understood the meaning of this section well.

Modifications not feasible.

Interesting thought to validate the uploaded documents signed with electronic signature. The purpose for this chapter was to validate the information filled in by the user (e.g. first name, last name, ID, DoB, etc. ). I feel this electronic signature validation feature needs a use case, then we can see how we can describe the required functionality.

Ensure that there is tracking of all changes to records ensuring that the Registry is a System of Record
Publish appropriate (i.e. anonymised) Open Data automatically on registration, and regularly (e.g. monthly) pseudonymised aggregate data

Already existing.

First of all logging is described in the following requirements (REQ-2). Changes to records are done with API-s in Digital Registries BB (or existing BB) , thus logging and tracking of changes to records is available in another BB. Same for Open data, it will be published via Digital Registries BB (will be added to the next scope).

Analyst decides which data field will be public and which is not.

Digital archiving capability is an absolute MUST capability for majority of registrations related to property, for example. It should be at least in the Roadmap for the Registration BB.

This is infrastructure implementation time requirement not BB requirement.

Registration BB is like a proxy that stores data only temporarily. Once the processing is done the information will be moved to other endpoints where it will be stored. This is why long term storing is out for now. The Digital Registries BB (or existing registry) is an option to store the information for the long term.

In practice, there are very different types of user interfaces: (1) Back Office UI for couple of officers, for whom performance and convenience are most important requirements, (2) Self-Service Portal for individuals, who only occasionally using governmental services - for them simplicity and clarity are most important requirements, (3) Self-Service apps for professionals (for example, tax consultants, accountants, logistics etc) - they need something in between, perhaps. This section is targeting what kind of users?

System is flexible to build these self-service services and also processing screens in Back Office processing. The Registration BB could operate as Public Portal or Registry management system (for Back Office).

Next paragraphs (6.1.2) describe the UI sections and the target users- Application File, Processing part. The Registrations BB is envisioned to be flexible to configure the user interface based on the user needs. In addition, the current requirements in this document are focused on the first target Use Cases. The personas are- Healthcare worker, parent, etc.

5.2

Registration is always done for some reason, which means that there are some third parties, which may want to have an access to results of registration. For example, if parent have granted permission to her child to cross a boarder and to go for sport competition abroad, then boarder guard officer should be able to see this permission electronically. I do not see such requirement here.

Content sharing agreement is dealt with Consent management BB.

5.2

In big cities, there are may be many places, where registration can be done (if physical attendance is required). In such cases there should be capability to book appointment and preliminary upload some contextual data.

Yes, the No-code development platform has been designed to be flexible enough to let the user to select a Place of Collection on the form, time of collection, and if required upload some preliminary information- e.g. passport copy. It has been decided that time reservation and Calendar function is solved in another BB.

DS-7

I would suggest explicitly distinguish two types of mobile devices: smartphones, which have 3G-4G and GUI and old-fashioned mobiles with USSD. Those USSD devices should be also supported - in Africa it is massively the only option

Modification is unacceptable. This is part of the Payment BB scope.

Standards.
As you refer here to rules and decisions, then I would recommend to utilise Decision Model and Notation spec (at least for so called Rule engine).
As you refer here to workflows, then I would recommend to utilise BPMN spec at least.
Also, CMMN might be interesting

BB is open to any of these standards and this is the decision of build time for developers.

The Rules engine is designed to be user friendly and it follows the well known Decision model- IF this is true then show the form element, requirement, any element in the system. It is not restricted to this decision model, so the developer can introduce other business rule methods.
BPMN may be technically ok, but overkill for this function in UI. Any user friendly logic will do.
CMMN Technically OK. user interface wise something simpler is needed.

Resource model

This model seems to be limited only with the processing part of the registration and excludes usage of Registry part. Also, Digital Registries component doesn't show anywhere Registry-Subject model as per terminology section #2 (see above). Aim of registration process is always to create registry which can be heavily used for queries. For example financial services authority after issuing licenses will be doing regular risks monitoring and for that they need to have Registry of Companies with types of issued licenses with all related individuals. I am not sure that I understand how such usage can be implemented by the the Registration BB and Digital registries BB.

May be related to requirement SF-7.

Registration BB is to collect and submit data to the registration Authority. Once the authority users have made a decision to enter data to the registry, then the system passes the data to Digital Registries BB (or to existing registry). If there are consumers of this registry data, then they have an option to ask this information via UI services in Registration BB or via Open API in Digital Registries BB.

such generic approach to a data model of the registration process seems to be not very practical. In reality, as terminology section put forward, there are Subject and Applicant, which may have its own complex structure. Omitting Subject and Applicant in the data model put the whole heavy load of modelling of the processing flow and Registry onto users and as such added value of such component seems to be too small. In reality, Subject always has some legal entities and/or persons and/or property/assets. And data attributes are normally attached to some combination of this triad: legal entity, individual and asset. I think, Registration BB and Digital Registries BB should address this complexity. Otherwise it will not be useful for public sector. It will be easier just to ask developer to create using Python or JS/Node just regular code to do processing.

We have chosen the principles of NO-CODE. Thus analyst must be able achieve the same goal without writing code. Data is defined based on domain in focus. Each e-service domain model is different. In this version our focus was postpartum infant care use cases.

As the BB is highly flexible there is no need to write the entity data into the data model. Each process has its own data model and the system must be able to facilitate this (all domains). In Mother and Child postpartum use case there is no mention of a company. If such entity will appear, then this can be added to the custom data structure and process by the analyst. System can facilitate any process and user screen. .

The requirements mentioned here are quite specific. To cater to these requirements, a new type of no-code development platform may be needed and the existing no-code platforms may not suffice.

As mentioned in the specification there are multiple products selected as reference. According to GovStack methodology the requirements may be fulfilled with multiple products/BB-s.

Can you specify where you found the limitation in question.

There are broadly two types of no-code platforms. No-code platforms that facilitate quick front-end development and no-code platforms that enable end-to-end application development.

For the first category of no-code development platforms, the starting point is often APIs. They facilitate seamless integration with APIs by citizen developers (analysts) and they also allow rapid development of the front-end based on those APIs.

For the second category of no-code development platforms, the entities along with their APIs (digital registries in our context) are created first, the APIs from those entities are used to build process flows and finally the front-end is also developed based on either the process flows or the APIs.

It may be a better idea to check whether the requirements can be aligned with the way the existing no-code development platforms work.

Requirements are envisioned to fulfill the needs of a no-code platform (the second one). As mentioned in the document, the specification is considering an example found in UNCTAD system.