Reference data

Reference data are data held in the base register that are marked as reference. It is a general legal and procedural premise that reference data are considered valid in the exercise of public administration unless proven otherwise or unless they are challenged by the relevant editor.

It is therefore the case that the public administration must act on the basis of these reference data and, conversely, that if the public administration acts on the basis of these reference data, there can be no maladministration due to inconsistency with the facts.

The editing and recording of reference data is always the responsibility of the editor responsible. The distinction of the editor's responsibility is not only per subject, but also per data. There is also a situation where there is more than one editor per subject. In this case, the editors are divided into primary and secondary editors. The primary editor is responsible for the actual existence of the entire record (including creation, update and deletion), whereas the secondary editor is responsible only for the individual entity data (including updates). A typical example of a situation of a primary and a secondary editor are legal entities, where the relevant primary editor is responsible for the creation and registration of the relevant basic data (the court of registration, the regional office, the trade department of the municipality, etc.) and the secondary editor (the Ministry of the Interior as the ISDS administrator) is responsible for the additional data, e.g. on the data box. Therefore, the secondary editor cannot establish or cancel the entity, but only adds additional data to it.

The basic duties of the editor are therefore:

• To write and edit data on the basis of the procedural execution of the agenda, which determines whether there is a document registered in the filing service to be executed
• To deal with the complaints process, including challenges to the accuracy of data from the keeper of the basic register, the editor himself or any public authority
• Address the accuracy and timeliness of the data

The documents on the basis of which the editor has carried out his duties must follow document_management.

Virtual reference data are those data that are created by deriving, merging or otherwise modifying existing reference data. They therefore do not meet some of the requirements of traditional reference data, such as the responsibility of a specific editor. Virtual reference data have a label, a definition and a described process for how they are created in each specific service that can provide them. A typical example would be the virtual reference data "full name", which is composed of the reference data "first name or first names" and "last name". Other such virtual data may be:

• Age
• Name without diacritics
• Address in uppercase only
• Number of days until expiration of identification document
• Telephone number in international format
• etc.

Virtual reference data need not be explicitly mentioned in the law as content of a specific basic registry, as they are created and extinguished with the call of a given ISZR or ISSS service. They are therefore only the content of the service description.

Currently, no ISZR or ISSS service has the capability to provide a virtual reference. This functionality is foreseen in the development of the PPDF.

An indicator is a reference data held in the basic register which serves to indicate that potentially relevant data on an entity are held in other information systems. The purpose of indicator data is to prevent unnecessary queries to information systems where such information is not held.

The administrator of the basic register is responsible for the allowed set of indicators, including their names.

The editor of the indicator data type is the administrator of the information system that maintains the indicated data, which are entered into the basic register in the same way as the reference data, i.e. by automatic processes. An indicator may also be a virtual data of the basic register and multiple indicators may relate to one subject.

The indicator data type has the following basic attributes:

• name - the unique name of the indicator, example: COVID-19,
• AIS identifier + agenda identifier,
• optional context identifier, within which detailed data can be retrieved via ISSS,
• Unnumbered list optional refinement code,
• optional text refinement.

The indicator type data contains other standard attributes:

• validity start date and time,
• expiry date and time,
• date and time of initial entry,
• date and time of last change,
• status (S, N, X, F).

Currently no ISZR or ISSS service has the capability to provide an indicator. This functionality is foreseen in the development of the PPDF, where the following modifications are required to introduce this data:

• Add a text item ListIndicator, a string type, and write and read structures to AuthorizationInfo. The names of the flags to be returned/written are entered into the ListIndicator. It is the equivalent of a ListIndicator, and ISZR checks that the querying AIS has permission to read or write to a particular indicator.
• Access to data of type Indicator is controlled by the Registry of Rights and Responsibilities in the standard way. A user (OVM, agenda, activity role) must be allowed to access an indicator with a given name.
• Adding a new indicator must not require XSD modifications or even a new agenda declaration to be as operational as possible.

The data accuracy complaint process can be initiated by anyone who has doubts about the accuracy of the data. The process itself is then always handled by the primary source of the data - i.e. its editor. The process starts with the receipt of a message that contains a doubt about the correctness of the data (from another OVM, a legal entity, a registry administrator, etc.). The editor is then obliged to mark the data in question as questionable. Subsequently, the editor of the data must perform a validation of its correctness, which may result in the closure of the complaint as unjustified (and thus preserving the value of the data) or justified (and thus changing it to the correct value). At the same time as closing the claim, it removes the doubt from the data. The claim process itself is governed by the Administrative Procedure Code.

Each public authority is obliged to use reference data from the basic registers to the extent determined by its competence in the respective agenda. It does so either by using the services of ISZR and linking its agency information systems or by using one of the other tools of the Reference interface.

The basic obligations of the OVM and the SPUU using the data are therefore:

• Use reference data in the agendas
• Use up-to-date reference data, which can be ensured by one of the following two, but always in accordance with the ISZR operational documentation:
  1. By using the mechanism of notification of changes to reference data and subsequent updates , or
  2. by querying the base registers for each transaction.
• If it detects a mismatch between reference data and reality, implement a data complaint against the data editor
• Do not request the data held in the registers from the right holder