Developed by Frank Grozel (UNCTAD), Ingmar Vali(ITU), Tambet Artma (ITU), Saurav Bhattarai (GIZ), Dr. P. S. Ramkumar (ITU), Rauno Kulla (UNCTAD)

7.1 Resource Model

The resource model shows the relationship between data objects that are used by this Building Block.

7.2 Data Structures

The Data Structures provide detail for the Resource Model defined above. This section will list the core/required fields for each resource.

7.2.1 Minimum Required Data

Description: The Data Structures can be extended for a particular use case, but they must always contain, at the minimum, the fields defined here.

Fields:

10.1 Key Decision Log

.

9.1 Administrative/Analyst Functions

The Digital Registries building block facilitates the foloowing main internal workflows:

9.1.1 Create a registry database in User Interface

9.1.2 Process registry data in User Interface

9.1.3 Create registry database in API interface

9.1.1 User Story 1 - Create registry database in user interface

As an Administrator/Analyst I want to use a web user interface to create a register database (example registry use case - social security program) so that I can configure and launch the registry database instantly to be used by internet users and client systems (e.g. Registration Building Block, Information Mediator Building Block) via web interface and API.

Actors: Analyst - An administrator user who is creating/changing the registry database schema. The main actor/user in these requirements is the Analyst.

Preconditions:

1. User is authenticated;

2. User is authorized as an admin;

3. User interface is a web interface;

Process:

1. Create a new registry database project.

2. Define the database fields.

3. Publish the database.

Post conditions:

1. System contains a database that is ready to process new data.

2. System has API services to CRUD (Create, Read, Update, Delete) data (and API to validate if data exist).

3. User can enter data to the registry via web user interface (UI).

9.1.2 User Story 2 - Process registry data in User Interface

As an Administrator/Analyst, I want to process (Create, Read, Update, Delete) registry data so that I do not have to know the query language.

Actors

• Analyst: the main actor in these requirements is the Analyst/Administrator.

• Data owner: a physical person whose personal data is stored in the registry.

Preconditions:

1. Analyst is authenticated and authorized to use the Building Block and process data in the database;

2. The user interface is a web interface;

3. User has internet;

Process:

1. Analyst searches a record via search or filter function;

2. Analyst selects a record;

3. Analyst processes a record;

Postconditions:

Processing changes by Analyst are done and log for change is created.

9.1.3 User Story 3- Create registry database in API interface

As an IT developer, I want to Create/update/delete registry database schema via API services.

Actors

• IT developer (Developer): Main actor in these requirements is planning to open a new business program and web form to capture applicants' data. Captured data must be registered in the registry. In this use case, a Developer is any user who is using API services to create and manage registries database.

Preconditions:

1. Developer is using API with a client system or a script that is connected to Information Mediator Building Block. Client system is any Building Block that is using API services via Information Mediator;

2. IT Developer (Information Mediator organization) has been given authorization to Create/update/delete database schema via API services.

3. Developer has internet;

Process:

1. Developer uses a client system to edit the registry database in the Building Block. Developer can:

   1. Create database schema;

   2. Read database schema;

Postconditions:

1. When Developer is authorized to use Building Block API then the Digital Registries Building Block allows processing CRUD (Create, Read, Update, Delete) schema of a registry, and all authorized users can;

2. When Developer is not authorized to process/CRUD the database schema, the system allows to process schema of all databases where an anonymous user has been allowed to edit the database schema (simplification for GovStack Sandbox instance);

3. When a user has no authorization, one can not create nor change (CRUD) any schema in the Building Block.

9.2 Applicant Functions

9.2.1 Process data in API interface

9.2.1 User Story 4 - Process data in API interface

As an Applicant, I want to process CRUD (Create, Read, Update, Delete) data in the registry database.

Actors:

• Applicant - The main actor in these requirements is an applicant via the client system. In this use case applicant is any user who is using a client system (Registration Building Block). For example, a Health Care worker is an applicant in this user story; a mother, using the Registration Building Block. An example client system in this document is Registration Building Block.

Preconditions:

1. Applicant is using client system (e.g. Registration Building Block) that is connected to Information Mediator Building Block;

2. Client system has been given authorization to access Registry to process (CRUD) information;

3. Applicant has been given authorization to access Registry to process (CRUD) information;

Process:

1. Applicant uses a client system to process data in the registry

   • Applicant can create data;

   • Applicant can read data;

Postconditions:

1. When Applicant is authenticated by a client system (e.g. Registration Building Block) the registry allows processing (CRUD) information from the registry. All users who are authenticated can read data.

2. When a user is not authenticated in the system, the system allows processing (CRUD) data from all databases where an anonymous user has been allowed to process data.

3. When a user has no authorization, one can not process (CRUD) any information in the registry.

5.1 Requirements

The Cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the and . This section highlights cross-functional requirements for the Digital Registries Building Block and in addition, describes any deviation to the Architecture Building Block cross-cutting requirements.

The Digital Registries Building Block provides services to other Building Blocks and to external systems, to store and manage data/claims on any entity (persons, places, and things) in forms of uniquely identifiable records in a database.

For example, these records could contain health and medical information, ownership of property, vehicles, money, qualifications, birth/expiry of people and entities, land surveys, manufacturing information of vehicles and equipment, banking and commercial transactions, etc. Given the diversity of such information, this Building Block provides services useful to abstract the structure, linkages, and grouping of information into various records and collections such as financial, legal, medical, social, educational, commercial, etc., as needed.

The Building Block provides the capability to capture, store, search, distribute, and present data with zero or minimal need for software development. It also maintains and reports logs of all operations taking place on database schemas and data. It contains various functional components, and data resources to abstract away all the details and complexity, and to expose capabilities as service-APIs to external Building Blocks/applications.

The Digital Registries Building Block is an optional Building Block for other GovStack Building Blocks that have the need to store information. Any traditional database platform could be used alone or in combination with Digital Registries Building Block. The Digital Registries Building Block can operate as a standalone service and could be implemented as one centralized instance per domain, containing multiple registries in one instance, or many instances per domain, each database in its own server.

The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.

The provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.

The tests for the Digital Registries Building Block can be found in .

The Digital Registries Building Block may contain multiple registries/databases. The dynamic nature of the database structure requires a standard set of automatically generated APIs for all databases hosted on the platform. The system generates default API method endpoints automatically after each publication of the database schema. A new API service version is generated after each schema publish. Database schema version and API versions are in sync.

6.1 Administrative/Analyst Functions

• DRS-1: Analysts have the option to create a new registry database by filling in the following information (REQUIRED):

  1. Name of the database;

  2. A short name;

  3. Schema of the database (see DRS-3).

• DRS-2: Analysts can create multiple databases in one system instance. Databases must be linkable with foreign keys. See the foreign key API description example in . Analysts can configure which databases and which fields are linked. In this document and foreign key function, we consider databases as database tables that can be linked with one another. See the . User story: As a user, I can browse database content (Data) in the user interface and when databases are linked, then I can click and move from one database/table to another where the corresponding linked data will open in the user interface. In the Digital Registries Data user interface, it should be possible to open another database by clicking on the record ID in one database and all corresponding records from the other Database will open. It is required to have at least two levels of IDs (database ID and field ID) to link the databases. See the example API in. Example: In one registry database we store information about Mother and Child records. In the second registry database, we store information about payments made for the mother. The system must enable a foreign key link between the payment database to the Mother and child record database. Users can click in the payment database record user interface to the Mother ID field and the system user interface should open the corresponding record in the Mother and Child database. (REQUIRED)

• DRS-3: Analysts have the option to add fields to the database schema. Fields of the database must contain at least the following elements (REQUIRED):

  1. Field name;

  2. Field type, at least with the following types:
• DRS-4: Analysts have the option to publish the database. Publishing will reveal the database to users. (REQUIRED)

  • Publish uses versioning. Each publish creates a new version of the database schema and API services;

  • Old database schemas must be available to the users;
• DRS-5: Analysts must be able to configure the API services per registry database. (REQUIRED)

  • The system automatically creates API services to:

    • create data;
• DRS-6: Authorization to (REQUIRED)

  1. create and manage databases;

  2. API usage per service, per record, per data field;

• DRS-7: The system must log all data processing in the database. (REQUIRED)

  • Schema changes must be logged;

  • Data processing (Create, Read, Update, Delete) must be logged;

• DRS-8: Personal Data usage. (REQUIRED)

  System must automatically store all data read requests and store these in the log table.

  • Covers data read events via User Interface and via APIs.

  • Personal Data logs are stored with PersonalData data tag, storing at least the following information.

• DRS-9: Analysts must be able to create views of a database. (OPTIONAL)

  • View is a selection of data from a database;

  • View can be opened as OPEN DATA (anonymous user);

• DRS-10: The option export database schema to JSON file, (optional: XLS file format). (REQUIRED)

• DRS-11: The option to import database schema from JSON file. (REQUIRED); The option to import database schema from XLS file. (OPTIONAL)

• DRS-12: Service usage statistics (OPTIONAL)

  • System must record all API service usage information.

  • System must record all searches made in the Registry User Interface and via APIs.

• DRS-13: An analyst must be able to mark a field as PersonalData log object (This field contains personal data). (OPTIONAL)

• DRS-14: An analyst must be able to mark a field as PersonalDataID. This is the data owner’s ID. (OPTIONAL)

• DRS-15: An analyst must be able to mark a field as secret- This field contains secret data (credit card number). E.g. secret data (card data) must be encrypted while at REST.

  Information in transit between the Building Blocks is secured with encryption. Information in Transit is described and governed by Information Mediator Building Block. (REQUIRED)

• DRS-16: Analyst has the option to read database schema in the web User Interface. (REQUIRED)

• DRS-33: Analyst has capabilities to configure database field properties (REQUIRED)

  1. API-related field properties:

  • Validation options: required, unique, max, min.

  • blinded/encrypted (DRS-15, DRS-18);

• DRS-34: Analyst has the capability to add an encryption key per database. (REQUIRED)

  • Encryption key is used to encrypt and decrypt data (DRS-17).

  • Encryption key can be used by applications to read encrypted data. Each database has a unique encryption key defined by the analyst.
• DRS-35: Analyst has the capabilities to automate data exchange between databases internally and externally via API. (REQUIRED)

  • Automation is triggered automatically after a pre-configured time interval as a loop (finishes when all corresponding records have been processed).

  • Automation processes one record at a time.
• DRS-36: Analyst may have capabilities to use database schema templates so that the registry creation is faster. (OPTIONAL)

  • Schema templates can be shared in the same instance (internal marketplace).

  • Schema templates can be shared in a marketplace.
• DRS-17: Analyst has a view to see all data in the registry. (REQUIRED)

  Two main views:

  • Main registry records grid view.

  • Record detail view.
• DRS-18: Analyst has a view to edit data in the registry. (REQUIRED) Two main views:

  • Main grid (inline editing).

  • Detail record edit view:
• DRS-19: Analyst can use additional functions to simplify data searching (REQUIRED)

  • Filtering by search criteria by field content.

  • Full-text data search.

• DRS-20: Import data to the registry. Analyst has the option to import information into the database. Import formats are: JSON, CSV, XLS. (REQUIRED)

• DRS-21: Export data from the registry. Analyst has the option to export selected/filtered data from a registry to CSV/XLS, JSON. (REQUIRED)

• DRS-22: Statistical queries. The system should have the ability to (REQUIRED):

  1. Produce standard statistical reports

     • System must show statistics of all registered items in the registry, with various criteria for filtering. For example:
• DRS-33: Users can share data with other users. Share data with other users via e-mail, or via a unique and secure URL. Sharing must be at a record level and field level. Data sharing can be turned off in the authorization module. Data can be shared with anonymous users. The data shared with anonymous users is Open Data. (REQUIRED)

• DRS-28: Developer has the option to create a new registry database by sending data via API (REQUIRED). Developer is a user who is using API interface.

  1. Name of the database;

  2. A short name;

• DRS-29: Developer can create multiple registry databases into one system instance. (REQUIRED)

• DRS-30: Developer has the option to publish the database. Publishing will reveal the database to users. (REQUIRED)

• DRS-31: Developer must be able to modify API services per registry database. (REQUIRED)

  • The system generates the API data structure from the dynamic database structure automatically each time a publish is done.

  • The system automatically creates API services to:
• DRS-32: Developer has the option to read database schema via API. Developer has the option to read the list API services available per Database. (REQUIRED)

6.2 Applicant Functions

• DRS-23: Building Block must enable client systems to process (CRUD) the database records via Open API services. (REQUIRED)

  • Applicant can search data;

  • Applicant can create data;

Building Block Components

The Building Block has a user interface to query and consult the registry data but in most cases, the Applicants are using the end client applications like Registration Building Block to access the registry. Any Building Block can query data from Digital Registries Building Block via APIs if authorization is given.

The Digital Registries Building Block is an application meant to offer fast and intuitive database management functionalities to entities without the need for database experts. The Digital Registries Building Block is simple to use like online Excel with advanced data management and connectivity options for advanced users. Digital Registries Building Block is a multi-tenant platform where users can create and manage new registry databases. Each registry database created in the system will have automatically REST services generated.

The Digital Registries Building Block no-code development platform uses graphical wizards to create and build software, unlike the traditional approach which uses computer programming languages. It is simple to use, similar to online Excel with advanced data management, log, and connectivity options for advanced users. Each register created in the system has a simple User Interface to see and edit data and an API connector with automatically created Open API services for machine-to-machine communication. The Digital Registry System does not contain data capturing and workflow functionality, however, if a user interface and data processing is needed then Digital Registries can be combined with other GovStack building blocks (e.g. the Registration Building Block) as a plug-and-play.

4.1 Administrative/Analyst Functions

The first user of the Building Block is an Administrator/Analyst who is building a new registry. The Analyst is the person who is building the new registry database, changing the existing database configuration, or simply administering the API user authorization. The Administrator/analyst is using a web user interface.

The key functions of the Building Block for Analysts are:

1. Create a new register/database (via API or Web user interface);

2. Create and configure the schema of the register (API or Web user interface);

3. Change schema configuration and publish the new version of the database and API services (API or Web user interface);

4.2 Applicant Functions

The second main user is an Applicant who is consuming registry data via other Building Block (e.g. Registration Building Block) screen flow or via Information Mediator Building Block API services.

The key functions of the Building Block for Applicants are:

1. Search data from the register;

2. Read data from the register;

3. Create data in the register;