Public administration and private data user portals

The portal is perceived as a whole functional unit containing Front-end (logic displaying behaviour towards the client) and Back-end (logic implementing system behaviour and internal and external integration) implementing all types of services according to Information Concept of the Czech Republic - Informational, Interactive and Transactional. This implies, among other things, that the portal is a public administration information system.

• In the area of information services, it provides users with an overview and publicly available information in the area covered by the portal, including descriptions of life situations.
  • In the information part, there is no need to deal with user identification, authentication and authorisation.
• In the area of interaction services, it provides the user with personalized data using multiple information channels, feedback between his actions, including history.
  • Interaction services require user identification, authentication and authorization.
• In the area of transactional services, it provides users with all types of submissions, including making a payment or booking an appointment for an attendance hearing, obtaining a confirmation and receiving a decision from the authority.
  • Transactional services require user identification, authentication and authorization.

Therefore, portals cannot be stand-alone and unconnected applications, but instead must be a resource that is integrated with the information systems in the Authority. In particular, with the electronic filing service, with agency information systems, but also with economic systems where they are used to collect data on payments or fees by individual client. In the case of providing all 3 types of services, these are so-called integrated online public administration services according to Information Concept of the Czech Republic.

The portal is intended to serve the client to obtain information, as a means of publishing open data, statistics and public outputs, for electronic submissions and communication between the client and the authority. The portal must also serve the holders of a guaranteed electronic identification as a means of obtaining their data, for various notifications, but also for interactive submission of applications or requests for statements. It must also provide the client with a so-called profile or personified part, where the portal holds basic information about the client that is known to the authority or that the client discloses of his/her own free will.

The overall behavior and interaction of the Portal towards citizens and officials is called User Experience (UX). The UX includes not only the graphical design, but also the language (form, expertise, …), the way of interaction, communication channels, similar ways of identifying users, etc. For ease of use by the citizen, it is necessary that each portal uses a uniform, centrally defined UX. In simple terms, this is similar to the behaviour and interaction of the Citizen Portal described above.

The Citizen Portal refers to the transactional part of the Public Administration Portal, where the client/citizen can make submissions to the public administration and use its services through self-service under his/her guaranteed electronic identity. For more information see the separate functional unit

An agenda portal is a portal providing services of a logically centralised system for other public authorities and public administration clients. Typically, it is therefore an agenda portal under delegated competence provided by the agenda manager (notifier). The client can be either a citizen or another public authority. It is valid that the services for the client-citizen must be published according to one of the federation forms to Citizen Portal.

A territory portal is meant to be a portal providing services that fall under a certain territory of the country, typically a region, municipality, city, city district - collectively they can be referred to as local governments. A territory portal may contain, in addition to self-governing services such as local tax administration, also delegated services, but there should not be a situation where a delegated service is created only for the territory portal. It is the responsibility of the administrator to create a central environment for the handling of the delegated services that the territory portal will use but not create. In the case of territory portals, two trends are foreseen:

• First, local government portals will include a reverse navigation direction to the Citizen Portal, where the client will be able to handle everything else from the government that they may not have found in the local portal and
• local portals can be replaced in the long term by locally adapted services of the central Citizen Portal.

In the case of the portal of the private data user (also referred to as the PSUU), this is a situation where the owner of the portal is not a public authority, but by its nature is subject to Law 111/2009 Coll.. This may be the case for portals of health service providers, private insurance companies, banks, state-owned enterprises, etc. Such portals provide services that can be federated to the Citizen's Portal, but only provided that the SPMU is registered in the register and is obliged to electronically verify the identity of the client.

By ordinary portal in this sense we mean all kinds of portals according to their focus, as mentioned above, but this diagram shows the work with data. A plain portal acts as a single interface used to handle a service, but the actual handling of the service takes place in an agency information system. The portal procures all the data and other information it provides to the client through the agency information system, and all the documents that are created during the service handling must go into the writing service.

An agenda information portal (likened to an agenda information system) in this sense means all kinds of portals according to their focus, as mentioned above, but this diagram shows data handling. An agenda information portal behaves as a stand-alone agenda information system, i.e. it contains all the logic and supports the processes for receiving and processing the service in addition to the interface itself. The portal procures all the data and other information it provides to the client through a direct connection to information system of basic registers, eGSB/ISSS or AIS, which are managed by the same administrator as the agenda information portal. It is still the case that all documents generated in the course of processing a service must go into the document management file services.

The authority must implement and change the current processes, which are primarily oriented towards personal contact with the client, when operating the portal. The current portals must already have the functionality of linking with a guaranteed identity according to Act 250/2017 Coll. and must be able to adapt to a situation where the client of the public administration will only communicate electronically. This starts with the user-friendly environment itself, which must comply with the graphic manual of the Ministry of the Interior. Next, a form engine is needed that not only allows pre-populating all data already known to the state from the linked data pool and electronic identity provided by the national identity authority. Last but not least, it is necessary to ensure that all submissions made in the portal are forwarded to the agency information systems in which the submissions are processed according to the agenda and also to the office's filing service.

The portal supports a self-service client that includes both delegated and self-governing competences and contains a description of the life situations in which mandates in electronic communication are dealt with. If the portal implements and supports the agenda of public administration according to register of rights and obligations, it must behave like any other agenda information system and work according to the definition of an agenda.

Thus, when submitting submissions from the portal, functionality needs to be provided to make the submission "human-readable" and "machine-readable" information within a single document, typically PDF/A3 and above. This "container" format is then used both to meet the "readability" requirement and to provide the requirement for automated data processing (embedded XML with data for automated processing). Furthermore, the document must be provided with the requisites according to Act No. 297/2016 Coll., typically an electronic signature or an electronic seal and a time stamp. The human-readable format, typically PDF, goes to the filing service for registration and the machine-readable format goes from the agenda system. Neither technology nor infrastructure matters in the operation of the portal. So neither On Premise solution nor cloud solution is preferred, it all depends on the needs of the office and the possibilities that technology can offer. It is always necessary to think about load distribution, for example:

1. personal income tax returns are filed once a year and although this is not a single decisive moment (the total period is 6 months) and additional tax returns can be filed, it is not necessary to put the same demands on the infrastructure throughout the year, or
2. applications for various subsidies (e.g. "boiler") are submitted by a certain date, some load can be expected from the time of launch until the end when the demands on the infrastructure will be high (with an increasing trend) and after the deadline when they will be minimal.

However, any solution must support access to central eGovernment services and other public administration services through a secure Public Administration Reference Interface infrastructure.

The rules for the Citizen Portal and the Public Administration Portal are described in a separate functional unit.

An agenda portal is a portal providing services of a logically centralised system for other public administration bodies and public administration clients. Typically, it is therefore an agenda portal under delegated competence provided by the agenda manager (notifier).

Such a portal must fulfil several conditions:

• It must be registered as a public administration information system in the register of public administration information systems
• It has a public administration authority that performs one or more agendas according to the list of public administration agendas
• Must be federated to Citizen Portal
• Must be federated to National Identity Authority and announced as a qualified service provider
• Must, according to its agency law, be able to draw and provide data through the eGON Service Bus/Shared Service Information System
• Must, according to its agenda law, be able to draw data from the basic registers information system
• Must use the same service and life situations catalogue structure as in RPP
• Must comply with graphic manual of the Ministry of the Interior

Procedure for client work activities, client identification and service selection

• Clients connect through NIA and are identified by BSI until the client selects a service that is provided by agenda
• After the client selects the service, the OVS provides identity translation (BSI-AIFO of the selected service's agenda) using eGON of the ISZR services
• OVS will query the authorized credentials for the needs of the service
• OVS will give the client a choice of which role he/she wants to fill according to the agenda in which the service is provided (so-called mandate)
• After the service is completed, the OVS does not remember the AIFO or other data used for the service, unless required by the agenda itself
• OVS remembers the BSI for the client profile on the portal

In the case of local government portals, two trends are foreseen: a) firstly, local government portals will contain a reverse direction of navigation to the Citizen Portal, where the client will be able to handle everything else from the government that he/she may not have found in the local portal, and b) local portals may be replaced in the long term by locally adapted services of the central Citizen Portal in the PVS. Such a portal must fulfil several conditions:

• It must be one for each authority - everything that the authority is competent for is available on it.
• It must be registered as a public administration information system in the system on public administration information systems
• It must be federated to the Citizen Portal
• Must be federated to National Identity Authority and announced as a qualified service provider
• Must, according to its agency law, be able to draw and provide data through the eGON Service Bus/Shared Service Information System
• Must, according to its agenda law, be able to draw data from the basic registers information system
• Must use the same service and life situations catalogue structure as in RPP
• Must comply with graphic manual of the Ministry of the Interior

Procedure for client work activities, client identification and service selection

• Clients connect through NIA and are identified by BSI until the client selects a service that is provided by agenda
• After the client selects the service, the OVS provides identity translation (BSI-AIFO of the selected service's agenda) using eGON of the ISZR services
• OVS will query the authorized credentials for the needs of the service
  • OVS distinguishes between autonomous and delegated competence
  • An autonomous competence is a set of multiple agendas, the entire autonomous competence cannot be held as a single agenda
• OVS will give the client a choice of which role he/she wants to fill according to the agenda in which the service is provided (called mandate)
• After the service is completed, the OVS does not remember the AIFO or other data used for the service, unless required by the agenda itself
• OVS remembers the BSI for the client profile on the portal

In the case of the private data user portal (also referred to as the PSU), this is a situation where the owner of the portal is not a public authority, but by its nature is subject to Law 111/2009 Coll. An SPÚÚ is an entrepreneurial natural person or legal entity that is not a public authority and is entitled to use data from the basic register or from an agency information system according to another legal regulation. Such a portal and its owner must meet several conditions:

1. It must have a data box for communication with the public administration.
   • Legal entities have a data box established by law
   • It is possible to set up a data box according to the information on the Czech Post website
   • The data box can be operated via the web interface at www.mojedatovaschranka.cz or have its functionalities integrated into the internal systems of the organisation. Most often it is an electronic filing service.
2. It must be reported in the SPUU's register of rights and obligations. You can check here https://rpp-ais.egon.gov.cz/AISP/verejne/katalog-spuu.
   • Reporting to the SPUU register is done via the competence agenda information system see https://rpp-ais.egon.gov.cz/AISP/. This system can be accessed by any agenda notifier.
   • Therefore, if there is an agenda under which the UAMS is entitled to draw data from the basic registers or the agency information system, the administrator of the agenda should be contacted and the entry in the UAMS register requested.
   • If the private data user is not declared in the AISP and the agenda manager or other OVM does not want to declare him/her, the SPMU may contact the administrator of the Register of Rights and Obligations (posta@mvcr.cz) with a request to declare him/her in the SPMU register with the following data (name of the organisation, address of the organisation, registration number, tax identification number, law and section authorising access to the basic registers or the agenda information system, contact person)
3. Must be declared as a qualified online service provider (hereinafter referred to as Service Provider). More also here https://www.eidentita.cz/Home/Ovm. Notification can be automated via a form if data box type (type 10, 14, 15, 16) allows it. If the applicant does not have this type, it is necessary to contact the Administration of the basic registers via the data box directly with a request containing all the data as in the case of the automated method:
   • entity ID number
   • Name of the qualified provider (SeP)
   • Description of the qualified provider
   • URL linking to the homepage of the website
   • URL address for sending requests
   • URL for receiving the issued token
   • URL to which the user will be redirected when logging out of your website
   • Retrieving the certificate
   • Address to retrieve the public part of the encryption certificate from the metadata (URL). This public part will encrypt the data in the token
   • Qualified Provider Logo
4. Must be able to receive and process data using SAML2 or WS-Federation standards

Workflow for client identification and service selection

• The SPUU portal does not need to be an ISVS
• Clients connecting via NIA are identified by BSI until the client selects a public service
• For the purpose of querying other data, they must use an ISVS (possibly another OVS performing the given agenda) to which they forward the user's BSI. The transfer of data between the SPUU and the OVS must be legally supported
• The SPUU shall give the client a choice of the role he/she wants to fill
• Upon completion of the service, the SPUU does not remember the data used for the service unless a specific authorisation requires it
• SPUU remembers the BSI for the client profile on the portal
• Private services are governed by their own specific rules!