======Methodology for recording VS services, their actions and digitization plan======

<WRAP center round box 100%>
{{{:znalostni-baze:logo_eu.png?400|EU logo}} Funded by the project Use of process management elements and introduction of standards for the performance of public administration agendas ("PMA 3"), reg. no.: CZ.03.4.74/0.0/0.0/15_019/0004225. The project is implemented within the OPZ.
</WRAP>


This methodology is intended for **announcers of agendas** who implement the adjustment of agendas according to Act No. 12/2020 Coll., on the right to digital services and on amendments to certain acts (hereinafter referred to as the "Act on the right to digital services"). The methodology is also published on the [[https://pma3.gov.cz/katalog-sluzeb/info|Procedural Modeling of Agendas]] website.

====== What we need from you ======

To fill in the catalogue of public administration services (VS). To do this, you must first do the following:

  * Identify the VS services and describe their attributes in the agendas you are reporting.
  * Decompose VS services into individual actions and describe their attributes.
  * Define how the interaction between OVM and the client occurs - identify the service channel.
  * Determine when and through which service channels it will be possible to perform the digital action and use the digital service.

As the data in the VS service catalogue is a reference, it is necessary to keep it up-to-date.

====== What is the VS Service Catalogue ======

The VS Service Catalogue is part of the Register of Rights and Obligations (RRO) 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 also as an **office application** used to collect and edit data.
The VS Service Catalogue will be continuously developed to fulfil the following **functions**:

  * **informational** - 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.

====== Why we need it ======

For the needs of the implementation of the Law on the Right to Digital Services, a catalogue of VS services is being created, which is linked to the registration of services initiated by the client (acts on request). The catalogue of VS services consists of all VS services, so it does not matter if the service is initiated by the client (subject of the right) or if the service is performed ex officio.

In the VS service catalogue, VS services will be divided into acts. For each action, the service channels - the ways in which the action can be performed - will then be recorded.

The aim of the register of VS services is to **clearly inform the client** about all available services provided by OVM.

The aim of the records of VS services is to **support the development of eGovernment** - to establish a digitisation plan to be implemented between 2021 and 2025. It will be gradually followed by other processes enabling the provision of digital tasks and services not covered by this methodology. Further information can be obtained at https://archi.gov.cz/.

====== In what timeframe ======

According to the Digital Services Right Act **the Government has until 1 February 2021 to set out a plan for the digitisation** of VS services, therefore in the first phase (by the end of 2020) the VS service catalogue must include the following:

  * a register of all services provided by public authorities - in the first phase, the focus will be on client-initiated VS services and primarily those implemented by the reporting OVM,
  * a breakdown of the VS services into individual actions and related information on which service channels can be used to perform them,
  * the digitisation plan - information on which service channels and when the service can be digitally processed.

All this must be part of the reported agendas in the RPP **by the end of 2020 at the latest**. Subsequently, ex officio services and services for which the OVM other than the reporting OVM is actually responsible will have to be added.

====== Brief instructions for completing the VS service catalogue ======

  * The first step is to check the scope of the office's responsibilities and identify the legislation governing your activities vis-à-vis external bodies, whether or not they are already declared as your agencies.
  * After that, compile a complete list of the agendas you are or should be reporting as an OVM. Do not consider agendas in which you are active but are reported by another OVM.
  * Identify all VS services and ideally break them down into individual acts at the same time.
    * Then assign and describe the appropriate service channels to the actions.
  * Finally, provide a plan for digitising the tasks based on the decisions of the responsible managers.
    * If a digitisation plan cannot be established (e.g. exercise of an autonomous or delegated competence without the existence of a centralised AIS), steps must at least be taken to remove the obstacles to digitisation (e.g. amendment of the relevant legislation)

====== What you need to do ======

In order to keep a complete record of the VS services, their operations and to establish a digitisation plan, it is first necessary to identify the individual entities of the whole record, namely: the **SV service**, the **operation** and its **service channel**. The following subsections deal with the definition of these terms:

===== VS Service =====

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.

//Defining characteristics of a VS service//

  * A VS service is governed by predefined conditions that are clearly defined by at least one piece of legislation:
    * e.g. parental allowance service follows from Act No. 117/1995 Coll., on State Social Support.
  * By means of the VS service, the client has the possibility to realise some of his/her **rights** or **responsibilities** which are derived from the law and which cannot be realised/fulfilled otherwise than through (a series of) interactions between him/her and the OVM:
    * e.g. the client has the right under Act No. 329/1999 Coll., on travel documents, to apply for a passport,
    * e.g. the client (landfill operator) has a legal obligation to send annually data on the state of the financial reserve created, data on the state of the free capacity of the landfill and data on the fees for the deposited waste to the regional authority competent for the landfill site on the basis of Act No. 185/2001 Coll., on waste.
  * Each VS service has an output that is perceived by the client as a certain value, either in the form of achieving a **benefit** or **fulfilling a legal obligation**:
    * e.g. the output of the service in the form of a benefit is the issuance of a passport for the client,
    * e.g. the client (landfill operator) has a legal obligation to send annually data on the state of the financial reserve created, data on the state of the free capacity of the landfill and data on the fees for the deposited waste to the regional authority competent for the landfill site on the basis of Act No. 185/2001 Coll., on waste. In this case, the outcome for the client is to comply with the legal obligation and thus avoid penalties for non-compliance with the legal obligation.
  * The VS service is provided by a specific OVM to a specific recipient:
    * e.g. the client Simon Trusina applies for parental allowance at the relevant office of the Labour Office.
  * The VS service is either initiated by the client or performed ex officio:
    * e.g. service initiated by the client - the obligation of written notification of changes in the facts decisive for the duration of the entitlement to the state social support benefit resulting from Act No. 117/1995 Coll., on state social support
    * e.g. service performed ex officio - according to Act No. 300/2008 Coll. on electronic acts and authorised document conversion, the Ministry shall invalidate the access data to the data box of the authorised person in case of cancellation of his/her authorisation and inform him/her about this fact.
  * In the vast majority of cases, the VS service is a set of several operations:
    * e.g. the service for choosing the amount of the parental allowance includes a set of the following actions: submitting a new choice, requesting to document/complete the application, documenting/completing the application, requesting to see the supporting documents, seeing the supporting documents, sending the decision/notification.

//Multiple services if://

  * the client of the service changes:
    * e.g. one service is the issuance of a permit for the closed handling of genetically modified organisms according to Act No. 78/2004 Coll., on the handling of genetically modified organisms and genetic products, when a company that needs a permit for its activities applies; another service is that **anyone** can send their written statement on the application,
  * there is interaction with multiple OVMs:
    * e.g. according to the Act No. 19/1997 Coll., on certain measures related to the prohibition of chemical weapons, it is necessary for the client to report the loss or theft of highly dangerous substances to the Police of the Czech Republic and the State Office for Nuclear Safety, so it is two services,
  * the use of one service results in new rights or obligations for the client, which cannot be fulfilled otherwise than by another new interaction with OVM, i.e. another service:
    * e.g. the output of one service is the issuance of a permit for the closed handling of genetically modified organisms (GMOs) according to Act No. 78/2004 Coll., the acquisition of this permit creates a **new obligation for the client,** namely to provide new information in writing concerning the risks of GMOs and to notify the Ministry of the Environment of the measures taken, while the provision of this information cannot be done otherwise than by a new interaction of the client with the OVM - it is therefore another service of the State Security Service,
  * the output of the service will change:
    * e.g. the service is obtaining the parental allowance drawn monthly in a certain amount (the service output is the award of the parental allowance), another service is a request for a change in the amount of the parental allowance, as its output is only a change in the amount paid,
  * the type of service is changed:
    *e.g. the service of request for data box unavailability based on Act No. 300/2008 Coll., on electronic acts and authorised conversion, is initiated by the client, but at the same time there is a service of data box unavailability performed ex officio.



**The acts reported so far on request in the RPP are in the vast majority of cases client-initiated VS services.**

Services are not defined by individual output characteristics, but only by output. For example, it does not matter whether the ID card is issued for 5, 10 or 35 years - the output of the service is still the "plastic eCitizen card" and therefore it is the same service. Also, it does not matter what the client or the OVM has to prove, the output of the service is what counts. If the output is the same, it is also the same service.

**When identifying and describing a VS service, it is necessary to keep user-friendliness in mind and to look at the solution to the problem from the client's point of view.**

===== Task =====

An act is a single and coherent interaction between a client and an OVM (official), which is implemented through a designated service channel on a single OVM and which has legal consequences. By means of an act or a series of acts, the client seeks to achieve an output of a given VS service.

It is recommended to define the actions together with the respective VS service. Thus, once you have defined and described a VS service, break it down directly into individual acts according to the definitional features listed below. Next, describe the attributes of the action that are defined by this methodology, while defining the corresponding service channel. At this stage, we are dealing with **first decision instance only**, i.e. it is not necessary to record e.g. the acts related to the appeal. By describing services, actions and service channels in a sequential and comprehensive manner, you avoid descriptions that are incomplete or duplicative.

//Defining features of an action//

  * An action represents an interaction between an OVM (official) and a client:
    * e.g. applying for a passport represents one complete interaction.
  * The act is performed by one OVM:
    * e.g. an application for a passport is submitted by the client either to the selected municipal office of the municipality with extended competence, to the office of the municipal district of Prague, to the Ministry of the Interior or to the embassy.
  * One action includes such a number of steps that can be performed together in one interaction, separately from other steps and in one service channel:
    * e.g. the submission of an application for parental allowance, including the supporting documents, regardless of the method of submission (in person at the office, via data box, by e-mail with a recognised electronic signature) can be done in one go and there is no need to spread the submission over multiple visits, reports, etc.
  * The task is performed either by the client or by the OVM:
    * e.g. submission of an application for housing benefit is carried out by the client,
    * e.g. a request for documentation/completion of a housing benefit application is carried out by the OVM.
  * Each action is linked to one or more service channels through which the action can or will be performed:
    * e.g. submitting an application to choose the amount of the parental allowance can be done in person at the office, or via data box and other means.
  * The service is also supported by legislation:
    * e.g. the application for child benefit is based on § 67-68 of Act No. 117/1995 Coll., on State Social Support.

//Multiple acts are involved if://
  * the executor differs:
    * e.g. the submission of the application is performed by the client, but the request for supplementation/documentation is performed by the OVM, so it is a different act,
  * they have different legal consequences:
    * e.g. the acts resulting from the Administrative Procedure Code "request to get acquainted with the documents" and "sending the decision" cannot be combined into one act, because they have different legal consequences - they are the fulfillment (realization) of different rights of the client,
  * only part of the steps can or will be performed through another service channel:
    * e.g. filing and payment of the administrative fee can be done in person at the office (recorded as one act in the VS service catalogue), but as soon as the payment of the administrative fee can or will be done electronically, it is necessary to divide the act into two: filing the application and paying the administrative fee.

Look at the acts as a logical sequence of consecutive steps, at the end of which is the service output, i.e. the fulfilment of the service required by the client.

Not all actions have to occur all the time (e.g. a request to complete a submission), some actions occur only in specific cases (e.g. inspection of the file). **All acts (client/OVM interactions) that can theoretically occur** should be recorded for the service.

//When it is a VS service and when it is an act//
  * A service runs from its initiation to the delivery of its output - it is therefore a collection of all possible OVM/client interactions that can happen sequentially (and repeatedly).
  * An action is only one of the OVM/client interactions that leads to the next service action, unless it is the final action. There is a clearly defined single performer (OVM or client), so it is one step (part of the service).

===== Service Channel =====

The last step of the VS service registration is to define the service channel and also to describe the different attributes of the service channel. The service channels are also used to plan for the eventual digitisation of tasks to be carried out between 2022 and 2025.

It is the way or means by which the interaction between the client and the OVM takes place. The types of digital service channels are defined in Section 4(1) of the RTI Act. These include, for example, a data mailbox or a submission through a public administration information system that allows the client's identity to be proven by electronic identification, authorisation and reverse proof of intent. The description of the service channel shall include a digitisation plan: through which service channel and by what year (2022 to 2025) the central administration plans to process the transaction.

====== Procedural law-based VS services ======

  * Many VS services are governed by general rules such as the Administrative Code and other regulations. Implicit in them, therefore, must be the acts introduced by these general legal rules.
  * In order not to have to redefine these actions for each notifier, the catalogue manager creates them in consultation with the manager of the relevant procedural legislation and notifiers of other agendas subscribe to them (add them to their services).
  * In terms of services initiated by the client, the administrative code is the key, where it concerns actions related to the submission of the application and any subsequent proceedings - e.g.:
    * invitation to complete the submission,
    * completion of the submission,
    * inspection of the file.
  * It is important to know whether the Administrative Procedure Code applies to a given agenda without exception, whether only part of it applies, and whether it applies to all or only certain VS services.
  * Lists of these acts will be continuously updated in the form of annexes to this methodology.


====== Attributes ======


===== VS services =====

==== Service Identifier ====

Automatically (as in the case of an agenda or activity) generated code used for database processing.

==== Service Name ====

The name should concisely and clearly convey to the client what the service is. It is important that it is not confused with another service, but still very simple, understandable and memorable. The benchmark is that the **service name is used** (will be used) in people's everyday conversation.
Always base the naming of the service on the relevant legislation; do not use slang terms (e.g. parenting or maternity).
You can use the phrase "I would like to arrange..." to help you name the service, followed by the name of the service according to the legislation, always in the first line. (e.g. I want to arrange parental allowance - so the name of the service is parental allowance).

==== Service description ====

Use this attribute to explain the purpose of the VS service in more detail.The purpose is not to copy parts of the legal regulation, but to give a short yet precise description that is understandable to the general public and does not contain obscure or difficult to follow terms.The content is only a **true description of the existence of the service**.

==== Type of service ====

The type of service determines whether the service is **client-initiated** or **executed** **officially**. For example, if the service is client-initiated, the initial action of such a service should be performed by the client.Use the dial pad to select only one option. If a service exists in both variants (client initiated and ex officio), it should be listed twice.

==== Entity using the service ====


  * This attribute specifies who is an **entitled client** under the legislation who is entitled to use the VS service.
  * Select one or more options from the code list:
    * natural person,
    * legal entity,
    * natural person doing business.

==== Legislation ====

Enter the relevant piece or pieces of legislation providing for the VS service and its specific parts (paragraph, section, letter).
If desirable, also indicate more than one part of the legislation.

==== Activity ====

Indicate all activities under the Basic Registers Act that are relevant to the VS service in its entire process (from initiation to completion). By assigning an activity, the VS service is **bound to specific internal processes** (e.g. authorisation to access basic registers and/or data in other agendas) and the OVM providing the service is pre-selected.
The link between an activity and a VS service varies - one VS service may correspond to one activity, but usually it does not and the VS service corresponds to several activities, or several VS services are provided within one activity.
==== Public authority ====




Public authorities or categories of public authorities (hereinafter referred to as PPAs) **implementing a VS service** are retrieved from the activities listed.
If the list of OVMs is not complete, additional OVMs can be added by adding another activity to the OVM service.
Conversely, the range of OVMs can be refined by removing them.

==== Scope ====




This attribute is used to classify the service - whether the OVM performs it in scope:

public administration
public administration with delegated competence
local government

The competence is determined through a codebook with the above values. The value can be selected for the whole VS service or for individual OVMs if they perform the service in different competences (e.g. the issue of eID cards is performed by the Ministry of the Interior as state administration, but by municipalities with extended competences as state administration in delegated competence).

==== Local jurisdiction ====


Information on whether the **location of the provision of the VS service to the client is restricted in any way**.
Explanation of each option (typology is based on the Administrative Code):
  * **not** - the client can choose an OVM from the given category (e.g. to apply for a new ID card at any office of a municipality with extended competence or a municipal district in Prague).
    * This option is valid if the OVM is a central administrative authority which does not have local territorial offices.
    * This also includes the possibility when the legal regulation of the OVM limits the relevant OVM to the nearest OVM (e.g. surrender of the ID card of the deceased at the nearest office of the municipality with extended competence or municipal district in Prague).
  * **at the place of activity of the participant** - the client must arrange the VS service at the relevant OVM according to the place, where the client's permanent residence is not decisive (e.g. arranging a wedding is done at the registry office according to the place of the wedding).
  * **at the place of permanent residence (place of residence of a foreigner) of a natural person** - the client must arrange the VS service at the relevant OVM according to his/her permanent residence (e.g. filing a personal income tax return with the tax office according to the permanent residence).
  * **at the location of the property concerned** - the client must arrange the VS service at the relevant OVM according to the address of the property concerned (e.g. the proposal for entry into the Land Registry is made at the relevant Land Registry Office according to the address of the property).
  * **by the registered office of the legal entity** - the client processes the VS service at the relevant OVM according to the address of the legal entity (e.g. a corporate income tax payer is obliged to submit an application for tax registration at the relevant tax administrator according to the registered office of the legal entity).
  * **at the place of business of a natural person** - the client shall process the VS service at the relevant OVM according to the stated place of business of the given agency (e.g. the state regional archives competent according to the place of business shall comment on the application for a licence to maintain a filing cabinet).

The local jurisdiction may vary from one OVM to another:
  * e.g. taking custody of an identity card:
    * municipal office of the municipality with extended jurisdiction - according to the place of business of the participant,
    * registry office - according to the place of permanent residence (place of residence of a foreigner) of a natural person.

Depending on the chosen entities using the VS service, the local jurisdiction options change. Select one option for each type of entity using the service. The following table clearly shows the permissible combinations.


^ ^natural person^entrepreneurial natural person^legal person^
|None | x | x | x |
|By place of activity of the subscriber | x | x | x |
|By place of permanent residence (place of residence of foreigner) of natural person| x |x | |
|According to the location of the property concerned | x | x | x | x |
|According to the place of business of a natural person | x | | |

==== Relevant for ====


Each VS service must be classified with regard to **which all information obligations** you will **fulfill** by recording and (in the future) detailing it.
You select whether the VS service is relevant to the Single Digital Gateway

Based on Regulation (EU) 2018/1724 of the European Parliament and of the Council of 2 October 2018 establishing a Single Digital Gateway (//Single Digital Gateway - SDG)// for the provision of access to information, procedures and assistance and resolution services and amending Regulation (EU) No 1024/2012, some of the GCPs whose agendas are relevant in terms of the SDG are required to provide information about these services in English.
The identification of these services is done through this attribute.


===== Task =====


==== Action identifier ====



Automatically (as in the case of the VS service) generated code used for database processing.

==== Action Name ====




As with the service, provide a clear and concise name for the action to make it clear to the client what the purpose of the action is.
The title of the action should **describe the specific step** in a concise manner (e.g., submitting a request, requesting documentation/completion, etc.).

==== Description of the action ====




Use this attribute to explain the purpose of the action in more detail.
The content **is only a factual description of the action**.

==== Legislation ====




Provide a reference to the section and paragraph or letter of the legislation that establishes the right or obligation to perform the act in order to implement the service. You may list more than one piece of legislation.
If desired, include more than one part of the legislation.

==== Performer of the act ====


Who performs (and initiates) the act - **OVM** or **client**.
Use the dial to select only one option.

==== Phase of the act ====




For each action you must **classify** what its **place in the series of service actions** is.
From the dialpad, select: start, middle, or end. Multiple values can be selected - e.g. if a VS service has only one action, it will be "start" and "end" at the same time.

==== The task is suitable for digitisation (justification must be given if not) ====




For each task, it is necessary to indicate whether or not **it is suitable for digitisation**.
Select one option (Yes/No) from the code list.
Select 'Yes' if the act can be digitised or you plan to digitise it.
If the act cannot be performed digitally and you do not plan to digitise it in the future, select 'No' and indicate in the text box why digitisation is not possible (e.g. digitisation of the act is too economically demanding; the clientele of the act is negligibly small, etc.).

===== Service Channel =====


==== Channel type ====




  * These are **the ways in which the act can be performed** (regardless of the performer of the act).
  * Select one or more options from the list, depending on the channels through which the action can be performed, or through which channels you plan to perform the action:
    * In person,
    * mail,
    * data box,
    * Czech POINT,
    * a recognised electronic signature (i.e. a qualified electronic signature or a guaranteed electronic signature based on a qualified certificate) sent, for example, by email,
    * self-service portal (AIS),
    * other means, if provided for by law,
    * other forms of remote access (e.g. public data network, telephone, etc.).
  * Then describe the remaining attributes (if allowed) for the channel.


This attribute is also used to record **whether and how schools and educational establishments** are to provide **the service according to the Act on the Right to Digital Services** (No 12/2020 Coll., § 14(6)).

==== Public authority ====




The range of pre-selected OVM is based on the activities assigned to the VS service.
For each type of service channel, only the **OVM to which the act is addressed or which performs the act towards the client** is listed among the pre-selected OVMs.

==== Required level of trust ====




This attribute is only applicable to the self-service portal (AIS) service channel, it is not relevant for other service channels.
Select one of the assurance levels defined by the eIDAS Regulation (Regulation (EU) No 910/2014 of the European Parliament and of the Council):
  * none,
  * low,
  * significant (e.g. identity means "name, password, SMS"),
  * high (e.g. eCitizen).

==== Scheduled to ====





Fill this attribute if you plan to cancel the given service channel. This is an optional attribute.
Provide here the exact **day, month and year** of the planned cancellation of the service channel.

==== Scheduled from ====



  * If you plan to introduce a new service channel in the future (e.g. a new self-service portal), you must specify **day, month and year** of the planned launch.
  * This is a mandatory attribute.

====== Detailed description of services VS ======

Based on the consolidation of information obligations (the Digital Service Right Act, the EU Single Digital Gateway Regulation), we are moving to a model where **descriptions of VS services can be kept up-to-date in only one place** - the RPP ecosystem, from where anyone can subsequently draw up-to-date information, whether it be departmental information websites, OVM portals (typically municipalities and regions), or third parties.

The detailed description of the individual VS services will be supplemented with information such as:

  * who can request them,
  * what needs to be documented,
  * what is the fee,
  * where they are processed,
  * etc.

The previous description of the VS services implemented through selected "life situations" registered on the basis of Act No. 106/1999 Coll., on free access to information, and the implementing Decree No. 442/2006 Coll., which establishes the structure of information published about the obliged entity in a manner allowing remote access, will be abolished as of 1 August 2020. An important change for public authorities is that the catalogue of public administration services is directly linked to the system of agendas in the RPP.

The detailed description of the VS services is not part of this methodology, it will be implemented after the agenda is announced and a separate methodology will be issued for it.

Why is the detailed description not entered into the AIS RPP Competence when registering the agenda?

  * If the creation of the detailed description of the individual VS services were part of the agenda registration process, the time needed to register the agenda would be longer. Separating the creation of the detailed description of the VS service from the agenda registration will allow the registration of the agenda regardless of the status of the detailed descriptions of the VS services, and thus will not block the change of other parameters of the agenda (which are used, for example, to control access to the basic registers).
  * It is expected that the requirement to update individual detailed descriptions of VS services will be triggered for reasons other than a change in the legal regulation defining the agenda. In this case, it will not be necessary to re-register the whole agenda, but it will be sufficient to update the relevant VS service description.

If you have any questions, please write to <ukonynazadost@mvcr.cz>.