Catalogue of public administration services

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.

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

The publication process consists of two main steps:

1. 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
2. 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

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

1. 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)
2. 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
3. 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