Registration (FGA)

Differences between Registries Platform and specification:

No fully no-code approach during the development of registry regulations. It can also be treated as a benefit in part of the cases because this allows building more complex and specific business flows, which bring more value and usability to an end-user in summary.

Actions for forms components should be defined in javascript language

No self-registration using email/phone and password with further confirmation

No direct integration to external systems from UI forms (except registries running on the platform instances). Integration is modeled on business process level through Trembita / REST API

No granular UI-form action to role mapping. User task / UI form with all its actions is configured to be accessible to one/multiple roles

No support for reports granular access control for different services / roles

No SMS/Voice services

No QR-code generation (planned for the future)

No consent management (planned for the future)

No single Information Mediator BB used, except Trembita event bus for SOAP integrations

Business process (service, registration) design happens in a BPMN modeller. The Registries Platform do not have any additional component on top of BPMN design tools.

A no-code development platform

Could be implemented

Low-code development platform for digital services modelling available covering data model, business process, UI-forms, org structure, access management, reporting and notifications, external integrations, etc.
Further evolution steps towards no-code development are planned for 2023 by the extensive development of a “one-stop-shop” registry regulation modelling portal

The online registration services developed with the platform (there is no limit to the number of services that can be developed)

Implemented

Registries Platform provides end-user cabinet interfaces for consuming and providing digital services by citizen and officer user roles

The no-code development platform is used by authorized personnel, called “analysts”, entrusted by the entities in charge of the registrations to develop the corresponding online services.

Implemented

Low-code development platform is used by authorized personnel registered in administrative realm by entrusted entities and having specialized set of roles

The online registration services developed with the no code platform are used by the applicants who want to be registered and by the operators in charge of processing the requests.

Implemented

Digital services are consumed by citizen users and provided / processed by officer users through end-user cabinet interfaces

No-Code Development Platform

Rules engine: a tool transforming legal rules relating to a registration (i.e subjects, results, requirements and determinants), defined by a human analyst, into machine-readable statements. See definition and illustration of “rules engine”.

Could be implemented

Low-code development platform provides modeling capabilities for business processes in BPMN notation, scripting business rules, UI-forms field dependencies & validation logic, etc.
Introducing declarative business rules support in DMN notation planned for 2023

Screens (user interface) and flow builder: a tool for a human analyst to create and organize the screens and fields that are necessary for the registration (application file) and processing.

Implemented

Controls configurator: a tool for a human analyst to define, for each field in the application file and processing screens, what controls will be applied (input format, formulas, actions/checks between fields and with external databases).

Implemented

The Online Registration Services

The online registration services (e-services) created through the no-code development platform are adapted to any type of registration. They consist in a succession of online screens and actions through which:
an applicant can provide claims (= fill a form), credentials (=upload documents) and fees (= pay online or upload a payment receipt) and send his/her request to one or more entities in charge of the registration (we call this part “application file”)

Could be implemented

Online payments support as a part of digital service is not implemented yet (External payment gateways integration planned for 2023)

an applicant can see/monitor the status of the submitted application file and receive results from the entities in charge of the registration

Implemented

Citizen user can monitor current status and completion result of digital service consumed through his cabinet. There is an option to receive a completion result either through defined communication channel (email, etc.) or in a form of generated signed digital document accessible for download through cabinet. Overall process view / monitoring with current status is not implemented - planned for the future

Validation: one or more human or automated (“robot” or “BOT role”) operators can review the elements provided, approve or reject an application, send claims to a registry and issue a credential (we call this part: “processing”)

Implemented

Addressed through modeling business processes (BPMN) containing “elements” review steps assigned to roles/officers in charge, persisting data into registry storage, generating digital document signed with a key of registry owner as a form of credential

For each service, user rights can be defined and statistical reports can be configured (“administration” part)

Could be implemented

Service statistics reports can be configured based on data from “audit” database. No granular report access control per service supported - reports are accessible to all users with “officer” role through special user interface

Secure ingress and Egress access mechanisms

Implemented

Inclusion issues

Could be implemented

Functionality for differently abled people not implemented yet

No-Code Development Platform

Rules Engine Functional Requirements

RE-1

Creation of Services
An analyst (user) must be able to create, in the rule engine, one or more services, each service encompassing one or more registrations.
A “Service” is a name given to a registration, or to a combination of registrations which can be undertaken simultaneously.
To create a service, an analyst will:
Give a name to the service
Link one or more registrations to the service

Must have

Implemented

Analysts can create business processes within the scope of the single registry instance. 

RE-2

Publish service to external instance
Each service can be published in the same or in a separate instance, together with the rule engine. Instance must be configured and interoperable with Registration BB service definitions.

May have

Implemented

Each definition of the business process can be published to a registry instance using registry regulation publication pipeline

RE-3

Creation of one or more “Registrations”
An analyst can create one or more registrations. For each registration, the analyst defines in clear language, in the rules engine:
The name of the registration
The entity in charge of the registration

Must have

Implemented

RE-4

Definition of the subjects of a registration
For each registration, an analyst must be able to report/input in the rule engine, in clear language, rules defining who/what are the subjects of the registration.
To this end, the analyst can select one or various of the following options:

1. The registration is mandatory to all

2. The registration is mandatory to specific subjects

3. The registration is optional to all

4. The registration is optional to specific subjects

1 and 2 can’t be selected simultaneously; 3 and 4 can’t be selected simultaneously.
Specific subjects (in 2 and 4) can be defined through determinants or a combination of determinants. Determinants can be combined by “AND” and “OR” operators. Combinations can be grouped into “groups of determinants”. Group of determinants can be combined through “AND” and “OR” operators.
Examples:
Registration is mandatory for attribute “resident” (all residents must register)
Registration is mandatory for attribute “resident” AND attribute “foreigner” (all residents who are foreigners must register)
Registration is mandatory for {attribute “resident”} AND {attribute “foreigner” OR attribute “have children”} (all foreign resident must register; national residents who have children must register)

Must have

Could be implemented

We are not supporting DSL language for the moment. DSL language could be designed to support simple conditions. Proper mechanisms could be introduced (custom step template) to process DSL rules. DMN notation could be used for a simple rules definition as well.

RE-5

Definition of the results of a registration
An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the results of a registration.
The result of a registration has a name (example: registration number, registration certificate, permit, license, etc.). To this name, the analyst must be able to associate a template/document (see RE-11).
In some cases, some subjects of the registration will receive a different result. The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific result.
Examples:

1. Future truck drivers that apply to a driving license and pass the exam will receive a driving license for “large vehicles”, while car drivers will receive a driving license for “light vehicles” (attributes: “truck driver” or “car driver”)

2. Enterprises with assets below US$5,000 will receive a “Cottage Industry Certificate”; enterprises with assets above US$5,000 will receive a “Business License”, when applying for an activity license (attributes: “assets below US$5,000” and “assets above US$5,000”)

Must have

Could be implemented

We are not supporting DSL language for the moment. DSL language could be designed to support simple conditions. Proper mechanisms could be introduced (custom step template) to process DSL rules. DMN notation could be used for a simple rules definition as well.

RE-6

Requirements of a registration - Documents/Credentials
An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the documents (= credentials) that must be provided.

• A document/credential can be defined by a name

• One registration can have several required documents/credentials

• A document/credential can be physical or digital

• For each required document, the analyst can select one of the following options: has to be brought to the front desk;

has to be uploaded
has to be signed in front of an Operator.
The required documents can differ according to the categories of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific required documents.
Examples:

1. Married applicants must provide a copy of their wedding certificate (attribute: “married”)

2. Foreigners must provide a copy of their residence permit (attribute: “foreigner”)

3. Applicants that can’t provide a copy of their birth certificate must provide a certified copy of their ID (attribute: “can’t provide a copy of the birth certificate”)

Must have

Could be implemented

The business process can include steps with a form definition to allow users to upload digital documents. Documents can be digital only.
No "signed document in front of the operator" functionality
We are not supporting DSL language for the moment. DSL language could be designed to support simple conditions. Proper mechanisms could be introduced (custom step template) to process DSL rules. DMN notation could be used for a simple rules definition as well.

RE-7

Requirements of a registration - Fees
An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the fees of a registration.
The fees of a registration has a name (example: State fee of MCTS programm, license registration fee etc.). To this name, the analyst must be able to associate an amount and a currency.

• Fee can be calculated or fixed;

• One registration may have 0..n fees;

• All fees must have an assigned currency. The system may allow multiple currencies;

• A fee can have a description.

When the fee is calculated, a formula builder will allow the analyst to build the formula, using values from any field in the service and numeric values, combined with the usual operators (+, -, *, /).
In some cases, some subjects of the registration will receive a different fee. The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific fee.
Examples:

1. Mothers with one child that apply to a registration to MCTS program will receive a identity card for 10 EUR, while mothers with two children or more will receive the identity card for 15 EUR (attributes: “one child” or “more than one child”)

2. Farmers with farming land area > 10 000 sqm that apply to registration of farm land will receive registration certificate for 10 EUR, while farmers with land area <= 10 000 sqm will receive registration result/credential certificate for 5 EUR.

Must have

Could be implemented

We are not supporting DSL language for the moment. DSL language could be designed to support simple conditions. Proper mechanisms could be introduced (custom step template) to process DSL rules. DMN notation could be used for a simple rules definition as well.

RE-8

Requirements of a registration - Data/Claims
An analyst must be able to report/input in the rule engine, in clear language, rules defining what is the data (= claims) that must be provided.
A piece of data is defined by:

• A name (e.g. date of birth, nationality, first name, last name, etc.)

• A type (text, number, date) mandatory/ optional (See Control configurator element for more options)

As for the other requirements, some data can be required only for a specific category of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific required documents.
Examples:

1. Married applicants must provide the first name, last name and date of birth for their spouse (attribute: “married”)

2. Owners of farm land should provide the number and date of registration of their property; applicants who rent farm land must provide the name and ID number of the owner (attribute: “own land”, “rent land”)

Must have

Could be implemented

We are not supporting DSL language for the moment. DSL language could be designed to support simple conditions. Proper mechanisms could be introduced (custom step template) to process DSL rules. DMN notation could be used for a simple rules definition as well.

RE-9

Possibility to combine various registrations in one service
In many cases the process for the user/applicant contains multiple pre-and post registration steps in order to achieve the final goal (e.g. apply for a healthcare program).
For example, in order to register a mother and a newborn child to the Mother and Child support program, both of the subjects must be previously registered in the Civil/Population registry. Civil registry registration service could be a separate service, but it is much user friendlier and less time consuming for the applicant to merge the two registrations into one service that can be filled at the same time. This service type is called Single Window- or integrated registrations service.
To facilitate the combination of various registrations in one service:

• Registration requirements (documents/credentials, results, fees) must be reusable inside the service. One registration may re-use another registration result credentials as input requirements.

• Overlapping requirements and/or results must be automatically eliminated.

• Fees of all registrations must be merged into one sum, so that the applicant could see and pay total fees. Fee information is stored and segregated per registration.

In one registration the document/credential may be issued as a result and in another registration the same document/credential may be required as an uploadable requirement. The system must eliminate the overlapping results and/or requirements if the requirements overlap inside the service.
Examples:

1. One service has two registrations and both of them require a passport to be uploaded. When an applicant chooses to apply for both registrations then the system must ask for the passport upload only once.

2. One service has two registrations. First registration’s result (credential) is the second registration’s requirement. The system must not ask this requirement from the applicant as the result will be generated during the process. However, if the user chooses to register for only the second registration then the requirement must be asked.

Must have

Implemented

We have the possibility to have a complex business process including several business processes definition as one BP definition.
We do not have a mechanism how for avoiding uploading the same documents from several BP. To address this manual steps could be added to a business process definition to try to search existing uploaded documents.

RE-10

Creation and functioning of determinants
The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific element of a service. An element of a service can be a field, block, button, message, processing role, result, requirement etc.
Simplest case being, is this claim data field on the screen relevant for all subjects or only for a specific category of subjects? If all then no determinant is needed as all users will see and use it. If a specific (e.g. “applicant is married”) category and this category must fill in additional information (e.g. “Spouse name”), then a determinant must be added to control the field visibility for this category of subjects. If the user is married, then the determinant is true and the “Spouse name” field is visible; if the determinant evaluates to false, then the spouse name field is not visible for the subject.
Analyst must be able to:

• create and manage determinants (CRUD);

• search the existing determinant;

• reuse determinant inside the same service;

• use formulas - calculate math functions on the form with user input value and use the calculated value in the determinant.

E.g. math functions (SUM, MIN, MAX, AVG, COUNT, MEDIAN, CEILING, FLOOR, ROUND, CONCAT, CONCAT_WS, LEN, REPLACE, UPPER_CASE, LOWER_CASE).
Apply determinants to:

• Any element of a service (registration, claims/data fields, screens, roles, templates etc.)

• Any element of a registration (results/credentials, requirements/documents)

Determinants can be combined by “AND” and “OR” operators. Combinations can be grouped into “groups of determinants”. Group of determinants can be combined through “AND” and “OR” operators.

Must have

Could be implemented

We do not have any explicitly defined determinants
Any mentioned formula behaviour could be a part of business process calculation (or even more complex inside a custom script business process step)

RE-11

Definition of a template associated to the result of a registration
An analyst must be able to create an electronic template (a screen with images, text, fields, QR code) and to link it to the result of a registration.
A template can be:

• Filled with values coming from fields in the service or from external databases;

• Printed as a pdf file.

• Generated and uploaded to the system as a PDF file.

On each template, an analyst can create data fields that must be filled by the system and place them on the screen of the template. Fields will have the following characteristics:

• A name (e.g. date of birth, nationality, first name, last name, select option, submit application, etc.)

• A type (text, number, date, selector, catalogue, button etc.)

• Source of information/capture data from. Function to capture data from application screens upon creation of PDF.

In addition to fields, the analyst can create information texts and add images, QR codes on the template screen.
QR code must be generated with the ISO/IEC 18004:2015 standard.
Determinants and groups of determinants created in the rule engine can be assigned to each field on a template. A field will be displayed/printed only if the determinants assigned to it are true.
Fields can be grouped into containers (blocks, tables etc). A container is defined by a name.
Fields can be moved to and on the screen by “drag-and-drop, inside/outside of and between containers.

Must have

Could be implemented

We are not supporting of QR code generation with a reference to a business process execution result

User Interface and Flow Builder Functional Requirements

SF-1

Application file and layout - Creation of screens and of their sequence
An analyst must be able to create one or more screens that will allow to show information to the applicant and to display fields that the applicant will have to fill to provide the requirements of the registration.
The analyst can define the sequence/order in which the screens will be displayed to the applicant.
The analyst can define one screen e-service or create multi page - wizard e-service supported by breadcrumb. The number of screens in an e-service is not limited.
By default the system provides template structure e-service screen skeleton.To this end, the analyst will be able to activate or inactivate, through a toggle, the following screens:

• Guide screen: this is a screen where the analyst can create text for the information of the applicants (guidelines) or ask questions (through fields) to determine what category of subjects the applicant belongs to (i.e. if the applicant is subject to the registration and what data, documents and fees are required).

• Applicant form screen: this is where the applicant will provide the required data.

• Documents upload screen: where the applicant will upload scanned copies of the required documents/credentials.

• Payment screen: where the applicant will see a list of fees that must be paid and can be redirected to an external online payment service.

• Send screen: where the applicant can be reminded of any information missing in his/her application (if some fields have not been filled or documents not uploaded) and will be requested to confirm his/her will to apply for registration.

The above screens, when activated, will be displayed, in the predefined order (guide, applicant form, document upload, payment, send).
The flow of screens can be visualized by the analyst.

Must have

Could be implemented

No supporting for payment screen
No templates predefined, this functionality could be added
No switchers for a screen, screen flow will be defined within a business process definition

SF-2

Application file - Creation of fields on each screen
On each screen, an analyst can create data fields/claims that must be filled by the applicant and place them on the screen. Fields will have the following characteristics:

• A name (e.g. date of birth, nationality, first name, last name, select option, submit application, etc.)

• A type (text, number, date, selector, catalogue, button, radio, etc.)

• Properties:

• Multiple values(array type)

• Catalog reusable source. Catalogs are reusable across all services in the same instance.

• Field/Button reusable action (e.g. activate data bot AND save form AND generate PDF AND upload PDF to application file data )

• The name of the registration(s) the field is associated with (i.e. the corresponding data is a requirement for this registration)

• Mandatory or optional

Determinants and groups of determinants created in the rule engine can be assigned to each field. A field will be displayed only if the determinants assigned to it are true.
Actions and groups of actions created in the service can be assigned to each field or button. For example, an Action can pull data to the form, submit data to external API endpoints, create PDF documents from templates or help users to move between the forms. A field will activate action automatically upon form load once. Actions can be controlled with determinants.
Every time a field is created it is recorded in the “data” part of the rules engine.
Fields can be grouped into containers (blocks). A container is defined by a name.
Fields can be moved to and on the screen by “drag-and-drop, inside/outside of and between containers.
In addition to fields, the analyst can create information texts, images that, contrary to fields, do not expect any input from the applicant.

Must have

Implemented

Developer can specify the flow for the screens.
We do not have the determinants but the visibility of fields could be defined for components using components attributes depending on specific conditions within business process

SF-3

Processing part - Creation of screens/roles
The processing part relies on the flow builder because roles are part of the process flow.
An analyst can create one or more screens allowing human operators to process the application files, i.e. to review the information sent by the applicant, to add data or documents to the application file (e.g. a number, a date, a credential, etc.), to approve an application, to reject it or to send it back to the applicant when more information is required.
We call “processing role” (or simply “role”) each successive processing an application file will go through until final approval is given and the registration is completed.
Usually, different roles are ensured by different government entities. It happens that successive roles are ensured by different units in the same entity.
Example flow:
Unit 1 reviews the application file, checks that all data and documents provided seem true and correct
Unit 2 approves the application
Unit 3 issues and signs the credential and sends it to the applicant
For each role, two screens are necessary:
A first screen (list screen) where the operator will be able to:
see a list of application files, filtered by status (pending, validated, rejected, sent back to the applicant)
select a file for processing (if pending) or for consultation
A second screen (processing screen) where the operator will be able to:
review the selected application file (data and documents provided by the applicant, fees paid or not)
add data or documents to the file
Make decision- approve the file, reject it or send it back to the applicant
Therefore, an analyst must be able to create one or more roles, each role coming automatically with one list UI and one processing screen UI. Each role will be defined with the following elements:
Name of the role
Name of the registration the role is associated with
Entity in charge of the role
Position in the process flow.
Determinants and groups of determinants created in the rule engine can be assigned to each role. A role will be displayed/activated only if the determinants assigned to it are true. If Role determinants evaluates to false, then the application file passes the processing role without stopping.

Must have

Implemented

We have a different approach in this case but the functionality is the same in general.
The review process is a separate business process for officers, which has a separate set of forms for reviewing and approving or rejecting the application.

SF-4

Processing part - Ordering of screens/roles in Flow Builder
An analyst will be able to define, for each role, a list of possible statuses, by selecting which of the following statuses are possible for the role:
Pending (the file is waiting to be processed by the role)
Approved (the file successfully passed the role)
Rejected (the application is denied, the file is closed)
Send back to the applicant for correction (the operator sends the file back to the applicant and requests that some information be corrected or added)
For each activated status, the analyst will be able to indicate where the application file will be sent in the processing flow:

• To another processing role

• To the applicant role (for consultation or payment)

• To end- the application file is closed/ end of processing

Therefore, the roles/screens in the processing part will come in an order specified by the analyst and this functionality is called Flow Builder.
The analyst must be able to visualize the flow of roles/screens.

Must have

Could be implemented

Mentioned functionality should be explicitly implemented in an official business process for reviewing citizen applications.
We do not have the possibility of assignment application status being processed by a specific role. Instead, each registry regulation could have different statuses of applications and specific processing flow for these statuses by roles.

SF-5

Processing part - creation of fields on processing screens
On each screen, an analyst can create fields that must be filled by the role operator and place them on the screen. Fields will have the following characteristics:
A name (e.g. registration number, date of registration, type of registration, validate application, etc.)
A type (text, number, date, selector, catalogue, button, etc.)
The name of the registration(s) the field is associated with (i.e. the corresponding data is a requirement for this registration)
Mandatory or optional
Every time a field is created it is recorded in the “data” part of the rules engine.
Fields can be grouped into blocks, columns, field sets and other containers (tables). A container is defined by a name.
Fields can be moved on the screen by “drag-and-drop, inside/outside of and between blocks.
In addition to fields, the analyst can create information texts and images that, contrary to fields, do not expect any input from the applicant.
Only human roles have the option to build processing screens.
Determinants and groups of determinants created in the rule engine can be assigned to each field. A field will be displayed only if the determinants assigned to it are true.

Must have

Implemented

Officer business processes together with forms could be designed in a visual editor.

SF-6

An analyst must be able to add QR-code/barcode scanning function to the service screen
An Analyst can add a form field element (e.g. button) to a screen and configure an action to trigger the capture of data from a QR-code.
Expected result- Analyst will build a service that has a button on the screen and a field on the screen to store the captured data. An applicant/user can trigger the “Read QR code” button on the screen of a service that opens the mobile phone’s (or other device) camera, reads the QR-code and captures the data from QR code to a field on the screen. Example data extracted from the QR-code is “MCTS123”.
QR code must be generated with the ISO/IEC 18004:2015 standard.

Must have
UC2

Could be implemented

We are not supporting QR codes for a moment

SF-7

Actions - the analyst must be able to configure triggering of actions when a user or system initiates an event on a screen of a service.
A triggering event can be a button click, a form loading, a form element click, data being entered into a field, or a row being added to a table.
Before actions can be triggered the API request must be defined in action attributes. The action attribute specifies one or more of the following data mappings (BOT):
where to send (request) the form-data when an event is triggered and where to store the received data (response). For example, the user will enter first name and last name to a form and after entering the last information the system will initiate a data BOT action to search data from the pre-defined external data source (via Information Mediator) and store the answer(response) phone number to the correct data field;
where to pull data (from an external registry API) and where to show the answer in the user interface fields;
where to send user (screen flow action). For example, the button click will take a user to the next screen. The next screen can be internal screen or external URL;
validate captured data integrity (required fields must be filled);
save entered information; exit service form.
send message (screen message, sms, e-mail, API message etc.)
Some actions can be activated only for a specific category of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific actions.
Examples:
User enters a person's identifier (tax number) and a button click pulls first name, last name and date of birth from an external API on the screen.
Married applicants must provide the first name, last name and date of birth for their spouse (attribute: “married”) and when data is entered, then the application screen will validate the entered persons name from the Population Registry and return validation answers on the screen (Success, Fail). Actions are only triggered if the user has entered the data AND “person is married”- determinant.
User clicks the “Validate and send” button on the screen, then the system will activate three actions: Save user data action, validate user data action, send user data action.
User clicks the “Print” button and the system triggers “Print to PDF” data action where a template is used as base for creating a new PDF document. System will enable the user to see, print or download the generated PDF.
User submits application and system will trigger BOT Role in the flow and it in turn activates data action bot -e.g. POST/GET message to external API.

Must have
UC2

Implemented

Business processes and forms can communicate via RestAPI with external systems.
These actions could be triggered via pressing buttons (or form component events) on a form or from a custom script step inside a business process.

SF-8

Formulas - Analysts must be able to add formula calculations to and between the fields. The Formulas can be added to numeric fields, int, decimal, date. Calculated values allow calculating values based on the values in other fields of the form. E.g. If the registration subject has more than 2 children, then multiply the social payment times the number of kids.

Must have
UC2

Implemented

We can define any formula within a custom javascript code for a UI component

SF-9

Preview- Analyst must be able to preview service User Interfaces before publishing the service to the applicants.
Following preview functions must be available.:
Preview of user interfaces one by one;
Preview of full service;
Preview of full service in test instance with the functionality to test the full service before publishing to live instance. .

Must have
UC1

Implemented

This could be done in a way of a preview of developed form, and entire business process functionality could be reviewed on a temporary environment

SF-10

Import/Export of service descriptions- Analyst must be able to import/export full service description.
Service descriptions must contain at least:
User interfaces, screens, fields;
2Process flow;
Service settings.
As a result, the service can be imported with minimal effort from another instance and published for users/applicants to use. Instance specific configurations must be done in each instance and are not target to import export.

Nice to have

Implemented

All of the business processes and other registry regulations part could be exported from a registry and imported into another registry.
This action could be done one by one for each single business process or form, or you can do it in a batch manner using git repositories.

SF-11

User can activate text-to-speach feature in the user information capturing forms to read out the screen information. The goal is to help illiterate users with understanding the text on the screen. The feature can read   captured information and other e-service information visible in the e-service screens.

Nice to have

Could be implemented

This functionality potentially could be added in future

SF-12

The feature enables to capture information from voice answers and ask confirmation if captured information is correct. Voice guide enable the user to follow the e-service wizard and submit applications.  

Nice to have

Could be implemented

This functionality potentially could be added in future

Control Configurator’s Functional Requirements

CC-1

Controlling the data capturing- Form field value validation
An Analyst must be able to configure field specific validation options e.g.:

• required;

• number, bigger, smaller, min, max;

• text, regular expression, contains, mask;

• date, earlier, later, today, older than age (The age of the applicant must be >=18);

• File upload size max limit;

• File upload type allowed.

Must have
UC1

Implemented

CC-2

Controlling the data capturing- Form field value validation from external API
An analyst must be able to configure screen field(s) validation from external API data source.
Examples:

• Applicant name and ID must match with data in Civil Registry record;

• Subject (first name, last name, DoB) must not been entered to the MCTS registry.

Must have
UC1

Could be implemented

UI components implementation could be extended to have validation possibility via external RestAPI

CC-3

Controlling the data capturing- data integrity validation
The system must verify that all claims/fields are correctly captured and all required documents uploaded.
The system must generate on screen meaningful error messages if any requirements are not fulfilled.
The system should not let user to submit application file if screen data capturing is incomplete.

Must have
UC1

Implemented

This logic should be implemented within a same business process

Online Registration Services Functional Requirements

DS-1

User Account (A0)
The User Account page, A0, is the first page that all users see when they authenticate (log in) to the system.
A0 must contain the following sections:
"My applications" part with various tabs:
list of applications (can be filtered and queried by status);
list of documents in the account and access to each of them;
application file content - the data sent with the applications;
messages received.
"Services available" part listing the services available for applicant to use. For each service there is a button, an icon, a title, an explanation text.
In order to make the service usable and personalized, Applicants must authenticate to the system - then the Applicant’s information is automatically attached to the application file when sending the application for processing.
The system must enable to:
see the User Account screen(Dashboard);
select an e-service from the list of e-services and fill a new application;
open the Applicant’s own applications to see the content;
save and continue filling the Applicant’s draft applications;
filter applications (search free text from application name, submission date, deadline date, and status);
delete draft applications;
see the content (Data, documents) of the submitted applications and the status of the application;
see “My documents” - certificates and/or approvals issued for the Applicant;
see and give approval for applications waiting for the Applicant's approval;
see, correct and resubmit applications sent back for correction;
see applications rejected by the Back Office;
see messages sent for the Applicant;
see and CRUD all documents uploaded by the Applicant;
see a list of registration application files, filtered by status (pending, validated, rejected, sent back for correction);
send on screen messages and e-mail, sms, etc. messages to applicant(s) and users based on application statuses;
see the status of the application file of registration(s) process.

Must have

Could be implemented

No Separate sections for a documents uploaded among all of BP. This could be implemented as a separate BP within a single form.
All of the mentioned items to see could be implemented via separate BP definition.

DS-2

e-Service screens
An applicant must have an option to see all screens of the e-service. The e-service may have one or more screens. Service screens are preconfigured in Screen and flow builder as service schema. Example screens:
Guide screen: this is a screen where the analyst can create text for the information of the applicants (guidelines) or ask questions (through fields) to determine what category of subjects the applicant belongs to (i.e. if the applicant is subject to the registration and what data, documents and fees are required).
Applicant form screen: this is where the applicant will provide the required data.
Documents upload screen: where the applicant will upload scanned copies of the required documents/credentials.
Payment screen: where the applicant will see a list of fees that must be paid and can be redirected to an external online payment service.
Send screen: where the applicant can be reminded of any information missing in his/her application (if some fields have not been filled or documents not uploaded) and will be requested to confirm his/her will to apply for registration.
The above screens, when activated, will be displayed, in the predefined order (guide, applicant form, document upload, payment, send) as a wizard. If not activated, then applicant will not see the pages.

Must have

Could be implemented

The flow of the screen is configured on a BP.
Form to ask questions: could be implemented via specific BP definition.
Payments are not supported now.

DS-3

e-Service data capturing
When an applicant is entering data the system must capture data entered.
Applicant can save their applicant file as a draft and continue data entering later.

Must have

Implemented

DS-4

e-Service data validation
When an applicant is entering data the system must validate the data based on configuration made by Analyst in the Control Configurator.

Must have

Implemented

DS-5

e-Service registrations
The system must tell applicants which services are applicable.
The system must have the list of applicable registrations where the Applicant can make a selection before continuing to the next form page. A registration may be optional or mandatory.
The system will not allow the Applicant to continue or submit the file if mandatory registrations are not selected.
Applicants can select multiple registrations in the same application.
Example: the UC-Postpartum infant care- Registrations in Civil registry, mother and child tracking program (MCTS) and optionally to pediatrician first meeting registration - three simultaneous registrations within one service.

Must have

Implemented

DS-6

e-Service required documents(requirements)
When an applicant has filled data/ selected registration to apply for, the system must show which additional information/documents must be uploaded with the application. Duplicate requirements are merged. If a requirement is an output of one registration and at the same time the input to the next registration, then this document must not be asked/visible in the requirements list as it will be acquired during the process.
An Applicant must be able to upload documents or take the documents to the counter service as originals.

Must have

Implemented

Asking the user for document uploading is a responsibility of BP definition. If the business process should first check if the document exists already in a system and, in case if not exists, should show the form for document uploading - this should be defined explicitly in a BP definition.

DS-7

e-Service required fees/payments
When an applicant has filled data/ selected registration to apply for, the system must show which fees are relevant.
Applicants must see the list of all fees to be paid, displayed both as sum and separately;
Fees can be paid in bulk;
Fees can be paid in the beginning of the process (pre-payment) ; in the middle of the process after a decision or after the process is finished upon receiving the result/output (cash payment);
Payment options may include: online payment; cash payment; mobile payment, etc;
All payment-related transactions must be logged;
All payments received must be available in the payment registry (or equivalent registry) as successful transactions.

Must have

Not the same approach

Payments not implemented

DS-8

e-Service movement on screens, roles and submission
Applicant can move between the screens and change the data up to the point of submission.
Applicants can submit application for processing(flow). All submitted applications are recorded in processing flow engine and first role defined in the flow builder will receive the the registered application file as a task for processing.
Movement on the screens can be done by clicking a button (Next) or by clicking on a tab/page name.
Movement between the processing roles is done via decisions (approve, reject, send back)
System must validate inconsistencies of the application upon submission.

Must have

Implemented

DS-9

e-Service application history
Applicant must see the application and flow history, process registration time and processing status in a flow. It should be possible to see which Institution is currently processing the application.
Applicants must see the expected processing end time for each application.

Must have

Could be implemented

Citizens can see only the current status of the application. We can implement proper RestAPI methods to get the required detailed information about BP execution. We can get the data from camunda db via camunda rest api. 

DS-10

Read information from QR-code/barcode and insert to the form
Applicant can use a function (e.g. button) and the action to capture data from QR-code.
Expected result- applicant can activate (mobile phone) camera, read the QR-code and capture the data from QR code to a field. Example data to be captured: “MCTS31”; “http://www.registrations.org ”
<Example UI>

Must have
UC2

Could be implemented

No support for QR codes reading now. Planned.

DS-11

System audit log functionality
System logs all user action in the system.
User action log is visible for admin users.
By default user action log is stored for 1 year after which the system will delete the log. The storage length is configurable in the Rules Engine.
Statistics are entered to statistics log table.

Must have
UC3

Implemented

If some actions should be visible in an audit log, these actions should somehow affect data in a DB, and these data should be marked as historical.
Actions like pressing several times "Next" and "Previous" buttons on a screen would not go in an audit log potentially.

DS-12

Back office Operators must have a view to see the list of applications to be processed (task list dashboard).
The system must have the function for an Operator to pick assignments from the common task dashboard.
The system must have the view for an Operator to see assigned roles and assigned tasks for this role.
Operators are linked to Institutions (or sub-units) and roles, thus can only see the tasks relevant for their role and Institution.
Optionally (configurable) - an operator could be able to claim a task from the application task dashboard. When task has been claimed, then the application file will be taken off from the common pool.
<Example UI>

Must have

Could be implemented

Everything should be implemented as a custom BP definitions

DS-13

An Operator of a role must see the received application file screen containing all information submitted by an Applicant and information complemented by other Operators while processing the same file.
Required documents relevant for this role and registration linked to the role;
Required data relevant for this role and registration(s) linked to this role.
An Operator must not see any information that is not relevant/required for the registration that this role is serving.
Must be able to see the history of the application file processing.
Must be able to see the status of the application file.
<Example UI>

Must have

Could be implemented

Everything should be implemented as a custom BP definitions

DS-14

An Operator must be able to make a decision in the system by selecting the right decision type (approve, reject, send back for correction).
At least one decision option must be available in order to process the application file.
The system must enable a form for an Operator to draft a decision text and select/fill additional information on the form.
In case of errors in the application, an operators must be able to mark which document and/or data field is incorrect. Applicants must see the highlighted information.
<Example UI>

Must have

Could be implemented

Everything should be implemented as a custom BP definitions

DS-15

Operators must have the option to print, sign and upload a certificate.
The system must not let an Operator make a decision in case a required document/result certificate is missing.
The system can display, print and upload a filled certificate from a template.

Must have

Implemented

DS-16

Operators must have the option to edit application information if corrections are needed.
The system must highlight if an Operator has made any changes to the information submitted by the Applicant.
The system should enable the Operator to remove and/or upload required documents.

Must have

Implemented

DS-17

Operators must have the option to communicate with applicant users.
Communication is application related and stored with application data.
Communication can be initiated by an operator or by an applicant. Communication initiation options must be configurable.
Communication system must be integrated with other systems via API (Information Mediator) and configurable for multiple channels.
Communication options are asynchronous and/or in real time. 

Must have

Not the same approach

No communication functionality in place (chat or something)

API interface for application file registration

API-1

System has an API service that enables to register new application files in Registration BB.
API endpoints with correct authentication credentials can be used as a service by Plug-in components for submitting captured user application information to Registration BB. 

Must have

Implemented

API-2

System has an API that contains an e-service application file  schema with all data fields. Schema can be used by other Building Blocks and components to create alternative e-service channels. 

Must have

Implemented

Application schema is a registry regulation management definition. Could be accessible via RestAPI using admin-portal lets say

Overarching Requirements

REQ-2

System audit log functionality
System must log all user activity in the system.
User action log is visible for admin users.
By default user action log is stored for 1 year after which the system will delete the log automatically. The storage length is configurable in rules engine.
IDENTIFY: Each building block MUST implement access and authorization audit, logging, tracing and tracking with alerts (minimally proxied or implemented through the API Management and Gateway services).
See detailed Audit logging requirements in the Security Requirements specification.

Must have

Implemented

Database CRUD related actions are auditable

REQ-3

Each building block MUST implement the ability to provision, deprovision and manage Identities and access rights (this may or may not be centralized for the whole architecture as a unified provisioning process).
See the Security Requirements specification.

Must have

Implemented

All dates should follow ISO 8601

Implemented

RFC 7159 - The JavaScript Object Notation (JSON)

Implemented

Open -API Version 3.1.0

Implemented

QR code must be generated with the ISO/IEC 18004:2015 standard

Could be implemented

QR-code generation is planned for implementation in 2023

Data Elements

Registration

Process through which an entity gets claims recorded in a registry and a credential proving the registration, in exchange of providing some requirements.

Required

Implemented

Digital service process modeled in BPMN notation consisting of data submission, validation & processing, persisting stages.

Service

Name given to a registration, or to a combination of registrations which can be undertaken simultaneously, by the entity(ies) in charge of organizing the registration process.

Required

Implemented

Digital service parent process  consisting of multiple sub-processes or multiple data records persisting operations

Screen/form

A service is composed of one or several screens defined in the Screen Builder by the analyst.
One or several screens defined in the Screen builder.
Screen(s) where a human

Required

Implemented

Implemented

Role screen/form

operator will undertake actions to process an applicant file, usually enter data (eg registration number, or registration certificate) and press buttons (approve, send back for
correction, etc.).

Required

Implemented

Implemented

Workflow

A workflow provides a visual representation of a business process. Workflow Engine executes processes that are defined in Business Process Model and Notation (BPMN), the global standard for process modeling. With BPMN, the analyst can automate most complex business processes using an easy-to-adopt visual modeling language.

Not required

Implemented

Implemented. Modeling workflows as business processes in BPMN notation supported through administrative user interface

Role

Human or bot actor in the workflow who must process the application file in the order set in the workflow.
A role is defined by 4 properties:

• Name of the role and;

• Who is in charge of the role- Institution entity

• Type- Action that will take place in the context of the role, either human or BOT

• Status decision options of the application file in relation with the role (0=pending, 1=passed successfully, 2=send back for correction, 3=rejected)

Not required

Implemented

Defining custom officer roles and assigning them to particular user tasks in business process supported.
Defining multiple role-action relationships for particular business process task / form is not supported

Institution /entity

Institution in charge of Registration and/or Role.

Required

Implemented

Digital services are scoped to particular registry / institution owner

Field/claim/data

An attribute asserted by an entity, about itself or another entity

Not required

Implemented

Result/credential

The result of a registration, in addition to the recording of information in a registry, is usually a credential (sometimes called: certificate, license, permit, card, etc.) proving the
registration.

Not required

Implemented

Credential generation can be included in business process model in a form of generated digital document signed by registry owner (excerpts)

Required document

Information (i.e. claims and credentials) which must be provided in a registration process. The requirements may vary according to each subject.

Not required

Implemented

Modeled depending on digital service requirements on UI-form level and validation rules

Payment/fee

Amount of money to be paid in relation to a registration.

Not required

Not the same approach

Online payments is not supported yet - planned for future

Determinant

A determinant is an attribute, defined in the rule, which determines/triggers if (1) an entity is subject to a registration and/or (2) what requirements this entity must provide to register.

Not required

Could be implemented

Modeled either on UI-form level through conditionals or on the business process level through alternative flows and business rules scripting

The statistics API gives BB operational statistics- number of processed applications (per: operator, registration, service, date).

Could be implemented

Digital services do not have separate statistical APIs. We need to develop a separate component to support a GovStack statistic API. This API could get required statistics data from camunda db.

The API is built using representational state transfer (REST) software architectural style (https://restfulapi.net/ ) and described in Open API 3 standard (https://swagger.io/specification/) using YAML (a human-readable data-serialization language - http://yaml.org/ ). Request and response body is in JSON (lightweight data-interchange format - ).

Implemented

Workflow- Creating a Registration Service (Admin Function)

Analyst/administrator as the main actor in this workflow will create a new e-service by filling the required registration requirements, create screens for the user and publish the service on the web ready to be used by internet users.

Implemented

Low-code development platform provides modeling user interfaces and tooling to create and publish digital services to end-users

As a pre-condition the user/analyst has authentication credentials and authorization to the service builder- Rules engine. If the service needs to read or write data from external sources (Information Mediator) that requires authorization then this is already authorized for the Registration BB. Registration BB is connected to Information Mediator.

Implemented

Registry regulation administrator must be authorized to use a low-code modeling platform
External systems authorisation configuration is defined on a registry level and available for all digital services belonging to the registry authorized.

As a post-condition, the e-Service has beglossaryen published on the internet for users to use immediately. The optimal time for an Analyst to build the e-service of a simple registration service is 2h.

Implemented

Depends on digital service business process complexity (number of UI-forms, business rules, integrations, etc.)

User Journey

Implemented

Similar modeling and publishing flow for digital services implemented using DEV and PROD registry instances

Interaction 1: Authentication and Authorization (Security BB)

Implemented

Data Structures: Existing user authentication

Implemented

External identity provider can be configured for use in platform Keycloak IAM for user authentication

Data Structures: Authorization

Implemented

Registries Platform uses Keycloak IAM

Interaction 2: Sequence Diagram via Self-Registration

Not the same approach

Self-registration is supported through UA-gov identity broker usage and on-boarding business process depending on registry requirements for assigning registry-specific user citizen roles, etc.
Self-registration with email/phone + password together with email/sms confirmation is not implemented

Interaction 2: Sequence Diagram for User Self Registration via Foundational ID

Could be implemented

Self-registration via Foundational ID is not implemented, but can be solved by implementing Keycloak authenticator extension and integration with external identity broker

Interaction 3: Information Mediator (IM) BB

Implemented

Business process integration connectors available for:
Integration with external systems / registries through Trembita event bus
Integration with external systems through REST API
Cross-registry integration with registries running on the same/other platform installation

Data Structures: Get list of registered institutions/databases

Not the same approach

Registry platform is not aware of the registries on another platform instances

Data Structures: Request API descriptions

Implemented

Partially covered by Trembita Event Bus administration UI

Data Structures: Get service descriptions

Implemented

Partially covered by Trembita Event Bus administration UI

Interaction 4: Payment BB

Not the same approach

Interaction 5: Setup for Multiple Registration BBs

Implemented

Workflow- Using a Registration Service

Description: flow description

Implemented

Description: payments

Not the same approach

Authentication and authorization (Security BB)- see “Creating a registration service”

Implemented

Information Mediator

Implemented

Interaction 1: Voucher Pre-Activation (Payment BB)

Not the same approach

Payments subsystem is not implemented as a part of Registries Platform. Flow can be modeled as external system integration through REST API protocol