Catalogue of public administration services

What is a service catalogue

The VS Service Catalogue is part of the Register of Rights and Obligations (RPP) and as such contains a set of data on VS services, actions and their service channels.

The VS Service Catalogue can be viewed in two ways - as a client application publishing data for clients and as a clerical application used to collect and edit data.

The VS Service Catalogue will be continuously developed to fulfil the following functions:

information - to provide an overview of existing VS services and how they are processed,

publication - to provide the data necessary for the correct display of VS services on portals (sorting, categories, you might also be interested in, etc.),

managing - enabled the management of the delivery of VS services (setting a plan for digitisation, information on the responsibility for the service will facilitate the coordination of the transition to a digital service, etc.),

automation - enabled the collection of data necessary for automation.

CataloguedService

Represents a function (activity) of an authority that is knowingly provided by a particular OVM to a particular recipient of a service under the relevant legislation in such a way that it delivers a perceived value to the recipient, whether in the form of a benefit or the fulfilment of a legal obligation. Only VS services during which there is an interaction between the OVM and the client or vice versa are recorded, not an interaction between the OVM and the OVM. A VS service can also be seen as the achievement of a right or fulfilment of an obligation of the client that cannot be fulfilled except through an interaction or series of interactions between the client and the OVM. A service is distinguished according to whether it is initiated by the client or performed ex officio. Each service consists of at least one act.

When recording VS services, sequentially review the legislation and identify VS services using the definitional features listed below. For each VS service, describe its attributes according to the methodology

Process of publication in the service catalogue

The publication process consists of two main steps:

Registration of services in ZR RPP

The agenda notifier (manually!) completes the registration of services and actions in AIS Scope RPP

Methodology - https://pma3.gov.cz/uploads/doc/Metodika-pro-evidenci-sluzeb.pdf

P2 XLSX template - https://pma3.gov.cz/uploads/doc/P2-Sablona-pro-pripravu-podkladu-pro-katalog-sluzeb-VS.XLSM

Agenda notifier sends for approval, MV reviews and approves/returns for refinement

Service and action records are entered into the RPP ZR and a blank detailed service description is automatically pre-created in AIS Catalogue Management

Filling in the detailed service description

The agenda notifier creates a detailed description for each service

Methodology - https://pma3.gov.cz/uploads/doc/metodika-detailniho-popisu.pdf

P1 template - https://pma3.gov.cz/uploads/doc/P1-sablona-detailniho-popisu.docx

The creation of the detailed description can be delegated to another OVM

Notifier sends for approval, MV reviews and approves/returns for refinement

Detailed description is published from RPP via RPP API and OpenData RPP

Publication of data from service catalogue

The public part of the catalogue is available on the public administration portal here https://portal.gov.cz/sluzby-verejne-spravy/

Approved detailed descriptions are automatically published from RPP via the RPP API (GraphQL, Azure). The GraphQL endpoint of RPP runs here: https://portal.gov.cz/katalogy/api

Options for working with service catalog data

Working with XLS of individual agendas

https://rpp-ais.egon.gov.cz/gen/agendy-detail/

daily updates

advantages

1:1 to data in AIS RPP Scope

complete data

and will be versions of agendas

disadvantages

must be limited to current agendas only (includes past and closed agendas)

parsing data (example of working with XLS parsing - https://code.gov.cz/gov-cz/katalog-slu-eb-anal-za)

API to service catalogue

https://portal.gov.cz/katalogy/api

no access restrictions for now, in the future an API key will be required and the address will change

primary purpose is for detailed service descriptions = texts to sites according to the detailed descriptions methodology - https://pma3.gov.cz/katalog-sluzeb/metodika

daily updates

advantages

Standardized API

GraphQL (output definition already at query)

disadvantages

only service data (no actions and service channels)

no documentation yet

open data

https://data.gov.cz/datové-sady?klíčová-slova=služba%20veřejné%20správy

daily updates

advantages

JSON

documentation

you can use the API - SPARQL endpoint - https://data.gov.cz/sparql (sample queries: https://ofn.gov.cz/registr-pr%C3%A1v-a-povinnost%C3%AD/slu%C5%BEby/2021-01-12/#uk%C3%A1zky-lod)

disadvantages

if a valid agenda has a future version, it is not in the data (also applies to the service catalog)

reasons for the inappropriateness of digitisation are missing

Data searching of service catalog