Translations of this page:

NAP: Totals by layer and use

Basic Principles (Business Layer)

Legal and regulatory systems and services

systems_services_associated_with_the_legal_council

Agenda model of public administration

Popis Agendového modelu veřejné správy

Agendový model je základem byznys architektury veřejné správy a základem řízení výkonu digitálních služeb veřejné správy. Všechny agendy veřejné správy jsou zapsány spolu s legislativním ukotvením v Registru práv a povinností včetně definice OVM v agendách působících. V souladu s touto registrací pak OVM musejí vykonávat svoje činnosti a poskytovat svoje služby. Registr práv a povinností dále definuje údaje v agendách vedené a pravidla pro jejich využívání jinými agendami resp. agendovými informačními systémy tyto agendy podporujícími.

Agendový model výkonu veřejné správy

Základ agendového modelu výkonu veřejné správy byl vytvořen při implementaci základních registrů ve veřejné správě. Agendový model definuje působnost a činnosti OVS v jednotlivých agendách – souhrn všech činností ve všech agendách, ve kterých OVS působí, definuje působnost OVS. Orgány veřejné správy mají veškeré své veřejnoprávní činnosti definovány popsáním působnosti v jednotlivých agendách.

Agendy veřejné správy

Agendy veřejné správy jsou nejen právní rámce pro fungování orgánů veřejné moci, ale i základní rámce pro realizaci procesů jako činností a pro evidenci a spravování a využívání údajů v rámci principu propojeného datového fondu.

Existuje následující obecný rozpad toho, co je evidováno k agendě v RPP a co to obecně znamená:

Agenda je soubor činností definovaných zákonem, či zákony (příklad je agenda občanských průkazů, státní sociální podpory, evidence řidičů apod.)

  1. Ohlašovatelem je OVM, který je gestorem dané právní úpravy a má tedy povinnost agendu a údaje o ní zapsat do Registru práv a povinností. Součástí ohlášení jsou:
  2. Referenční údaje o agendě
    • název agendy a její číselný kód, které jsou součástí číselníku agend,
    • čísla a názvy právních předpisů a označení jejich ustanovení, na jejichž základě orgán veřejné moci vykonává svoji působnost, nebo na jehož základě je soukromoprávní uživatel údajů oprávněn k využívání údajů ze základních registrů nebo agendových informačních systémů,
    • výčet a popis činností, které mají být vykonávány v agendě,
    • výčty činnostních rolí,
    • výčet a popis úkonů orgánů veřejné moci vykonávaných v rámci agendy na žádost subjektu, který není orgánem veřejné moci, identifikátor úkonu, vymezení subjektu, který může podat žádost, a forma úkonu,
    • výčet orgánů veřejné moci a soukromoprávních uživatelů údajů, kteří agendu vykonávají, nebo jejich kategorie,
    • název ohlašovatele agendy a jeho identifikátor orgánu veřejné moci,
    • výčet orgánů veřejné moci, které byly pro výkon agendy zaregistrovány, a jejich identifikátor orgánu veřejné moci,
    • výčet údajů vedených nebo vytvářených podle jiného právního předpisu v rámci agendy; to neplatí pro zpravodajské služby,
    • výčet údajů vedených v základních registrech zpřístupněných prostřednictvím informačního systému základních registrů pro výkon agendy a rozsah oprávnění k přístupu k těmto údajům,
    • výčet údajů vedených v jiných agendových informačních systémech zpřístupněných prostřednictvím referenčního rozhraní pro výkon dané agendy a rozsah oprávnění k přístupu k těmto údajům,
    • číslo a název právního předpisu a označení jeho ustanovení, na jehož základě je orgán veřejné moci nebo soukromoprávní uživatel údajů oprávněn využívat údaje ze základních registrů nebo z agendových informačních systémů anebo je zapisovat,
    • adresa pracoviště orgánu veřejné moci, které vykonává úkon podle písmene d), vyjádřená referenční vazbou (kódu územního prvku) na referenční údaj v registru územní identifikace, nebo údaj o převedení výkonu úkonu podle písmene d) na jiný orgán veřejné moci.
  3. Definice agendových činností a činnostních rolí: V rámci ohlášení ohlašovatel provede dekompozici legislativy a sestaví strom agendových činností (tedy postupu agendy a interakcí zejména z pohledu veřejné správy) a stanoví, jaké činnostní role budou jednotlivé činnosti vykonávat.
  4. Působnost v agendě: Je stanovena působnost jednotlivých orgánů veřejné moci (třeba konkrétní ministerstvo, či souhrnné skupiny jako jsou obce, krajské úřady apod.) a u nich jsou stanoveny činnostní role pro výkon jednotlivých činností. Působnost stanovuje/ohlašuje ohlašovatel a daný orgán veřejné moci se přihlašuje k této působnosti a k jejímu rozsahu, vše v rámci agendových informačních systémů v RPP.
  5. Adresy pracovišť OVM, kde jsou vykonávány činnosti agendy: Vytváří faktickou mapu výkonu dané agendy v území a každý OVM, který vykonává působnost je povinen ke svým činnostem přiřadit skutečnou adresu výkonu (nikoliv sídlo OVM).
  6. Agendové informační systémy: Jsou stanoveny agendové informační systémy, které orgány veřejné moci vykonávající působnost v dané agendě k této působnosti používají, těmto systémům jsou pak stanovena i oprávnění využívat služby základních registrů, a tedy využívat referenční údaje a údaje z jiných agendových informačních systémů prostřednictvím eGon Service Bus / Informačního systému sdílené služby. RPP je metainformačním systémem definujícím datový model veřejné správy, oprávnění a pravidla pro ukládání, využívání a zveřejnování údajů.
  7. Výměna (poskytování a využívání údajů) v agendě: Ohlašovatel stanoví, kdo a které údaje smí z agendy využívat anebo je naopak agendě ze svých AIS poskytuje.
  8. Údaje v agendě: Jsou ohlášeny všechny propojované a vedené údaje, včetně jejich kontextů a včetně technických údajů o nich.
  9. Úkony na žádost: Součástí agendy je i seznam a forma úkonů na žádost a určení toho, kdo smí takovou žádost podat
  10. Formuláře: součástí povinností ohlášení agendy je i předání elektronických formulářů či odkazů na ně ministerstvu vnitra.

Klíčové role OVS v agendovém modelu

Existují následující klíčové role, o kterých se hovoří i jinde v rámci architektonických dokumentů:

Klíčové role OVS v agendovém modelu veřejné správy Role Popis/význam hlavní činnosti
Ohlašovatel agendy OVM, který je zodpovědný za legislativní rámec agendy, a tedy určuje i základní parametry jejího výkonu Je gestorem právních předpisů; koordinuje výkon agendy; metodicky řídí výkon agendy; ohlašuje agendu v RPP a její podrobnosti; stanovuje působnost OVM; poskytuje buď centralizovaný AIS, nebo podmínky a standardy pro decentralizované řešení; ohlašuje a spravuje údaje v RPP, včetně údajů v rejstřících OVM a SPUU; v případě centralizovaného AIS poskytuje údaje přes referenční rozhraní ISVS
Orgán veřejné moci působící v agendě OVM, který působí v dané agendě. To znamená, že vykonává fakticky nějakou činnost v rámci dané agendy a k tomu využívá buď centrálně poskytnutý AIS, nebo svůj vlastní Přihlašuje se k působnosti; vykonává jemu svěřené činnosti úředníky v jejich činnostních rolích; zapisuje do RPP údaje o své působnosti; využívá centralizovaný AIS nebo spravuje vlastní; eviduje a spravuje údaje v agendě; vykonává případně funkce editora údajů
Soukromoprávní uživatel údajů Subjekt, který má na základě zákona oprávnění k přístupu k údajům v základních registrech či AISech a přistupuje k nim prostřednictvím AIS spravovaného k tomu určeným OVM Využívá údaje podle oprávnění
Správce centralizovaného AIS pro výkon agendy OVM, který na základě zákona spravuje centralizovaný AIS a poskytuje ho OVM působícím v agendě Spravuje centralizovaný AIS; zpřístupňuje AIS uživatelům působících OVM; realizuje využívání referenčních údajů ze základních registrů do centralizovaného AIS; poskytuje podporu uživatelům; řeší integrační vazby AIS na další systémy
Správce vlastního AIS, pokud není k dispozici centralizovaný AIS Jednotlivé OVM, které pro podporu agendy využívají svůj vlastní agendový IS, protože není k dispozici sdílené centralizované řešení Spravuje svůj vlastní AIS; zapisuje údaje o svém AIS do RPP; řeší vazby na základní registry; řeší vazby na další ISVS; řeší vazby na další svoje informační systémy; spravuje a udržuje datový fond ve svém AISu
Orgán veřejné moci spravující AIS pro přístup soukromoprávních uživatelů OVM, který na základě zákona vytváří a provozuje AIS, jehož prostřednictvím mohou soukromoprávní uživatelé přistupovat k údajům ze základních registrů či jiných AISů Spravuje AIS pro SPÚ; zpřístupňuje funkce AISu soukromoprávním uživatelům; realizuje dohled nad oprávněním k využívání údajů; poskytuje soukromoprávním uživatelům údaje; zajišťuje realizaci reklamací údajů od SPÚ k editorům údajů

Pohled na ohlašovatele a vykonavatele agendy

Pravidla Agendového modelu veřejné správy

Základní povinnosti ohlašovatele agendy

Ohlašovatel agendy je podle zákona č. 111/2009 Sb., o základních registrech zodpovědný za řádné ohlášení agendy a za aktualizace agendy, a především za správnost a pravdivost údajů uvedených v agendě. Zjistí-li kdokoliv nesoulad reality s údaji, měl by to jako u dalších referenčních údajů ohlásit ohlašovateli, a ten musí agendu upravit do souladu se skutečností. To se netýká jen základních informací, ale i všech dalších referenčních a nereferenčních údajů, jako jsou činnosti, působnosti OVM, údaje v agendě, agendové informační systémy apod.

Základními povinnostmi ohlašovatele jsou:

  • Tam, kde je gestorem legislativy, dodržovat veškeré principy pro legislativu, včetně zásad Digitálně přívětivé legislativy
  • Ohlásit agendu
  • Ohlásit každou její změnu
  • Ohlásit působnost všech OVM a definovat výkon jim svěřených činností
  • Zajistit využívání údajů ze základních registrů a související oprávnění pro jejich využívání pro podporu výkonu agendy
  • Ohlásit agendové informační systémy, které spravuje a které jsou poskytovány OVM působícím v agendě
  • Ohlásit údaje v agendě vedených, čerpaných i poskytovaných
  • K centralizovaným agendovým informační systémům vydávat provozní řád
  • Metodicky řídit výkon agendy u OVM, který v agendě působí
  • Spravovat, tzn. ohlašovat a udržovat aktuální, údaje v rejstříku OVM/SPUU. U SPUU se jedná o všechny subjekty, které jsou povinné dle právních předpisů spadající do agendy, jejichž je OVM ohlašovatel. Ohlašovat může ustanovit jiné OVM, které bude tyto úkony činit.

Základní povinnosti OVM působícího v agendě

V rámci agendy veřejné správy mohou veřejnoprávní činnosti vykonávat pouze ty orgány veřejné moci, které jsou v rámci ohlášení agendy vyznačeny jako orgány veřejné moci vykonávající působnost, a to v rámci konkrétních činností. To znamená, že po aplikaci principu referenčních údajů v Registru práv a povinností lze konstatovat, že pokud v rámci dané agendy vykonává veřejnoprávní činnost orgán veřejné moci, který nemá vyznačenou působnost, jedná se o porušení zákona a ohlašovatel agendy musí neprodleně toto napravit. To se týká nejen samotného seznamu působících orgánů veřejné moci, ale také přiřazení jejich činností. Výkon činnosti je byznysovou vazbou a odborně jej nazýváme "činnostní rolí".

Základními povinnostmi orgánů veřejné moci působících v agendě tedy jsou:

  • Vykonávat činnosti dle ohlášení agendy
  • Pokud OVM zjistí nesoulad skutečnosti a údajů v ohlášení agendy, je povinen požadovat po ohlašovateli nápravu.
  • Pokud sám spravuje agendový informační systém pro výkon agendy (není poskytován centrálně), ohlásit tento systém do RPP jako ISVS.
  • Pokud existuje centralizovaný agendový informační systém, tak tento využívat.
  • Přistupovat k údajům v základních registrech a dalších ISVS výhradně na základě oprávnění ohlášeného v agendě.
  • Spravovat jen ty údaje, které jsou ohlášeny v dané agendě.
  • Pokud zjistí nesoulad referenčních údajů v jednotlivých základních registrech se skutečností, zahájit proces reklamace u příslušného editora.

ConnectedDataFund

Interconnected Data Fund Description

The information provided here on the Interconnected Data Fund (PPDF) and all its subdomains (ISZR, eGSB/ISSS, etc.) is based on Global Linked Data Architecture, which is an annex to the NAP itself in extending knowledge base.

The Interconnected Data Fund (also referred to as PPDF) is a subject area consisting primarily of Basic Registry Information System and eGON Service Bus/Shared Service Information System, whose services are published through the Central Service Point. The PPDF and its systems/services are the physical representation of the public administration reference interface. The basic function of PPDF is to implement the principles of "Once-only" and "Data circulate, not people" into the common practice of public administration in the Czech Republic. PPDF is the primary source of valid and legally binding data for legal entities and for all OVMs and SPUUs in the exercise of their competences. Thus, the PPDF will lead to the replacement of manual interactions between authorities by automated data exchange between different Agenda Information Systems.

Agenda Information System is a term from Act 111/2009 Coll. and refers to such Public Administration Information Systems that are used for the execution of an agenda. Therefore, the PPDF texts contain both the terms Public Administration Information System and Agenda Information System. It also includes the term Private Data Use System, which is equal to the Agenda Information System, but has a different administrator than a traditional public authority.

The interconnection between the Agenda Information Systems and the basic registers is provided by Basic Registers Information System, the interconnection between the Agenda Information Systems and each other is provided by eGON Service Bus/Shared Services Information System. All links made within the PPDF are always linked to the basic registers by means of reference links to reference data on subjects of law (natural persons, legal persons and OVMs) and reference data on objects of law (territorial elements and rights and obligations). For the reference links of data on natural persons, the Agency Identifier of Natural Persons (AIFO) is used, for the reference links of legal persons the Person Identification Number (PIN), for the reference links of territorial elements their respective identifiers assigned by RUIAN. In addition to the development and support of the linked principles of data stem management and pseudonymisation, the main objective of the PPDF is the development of additional agenda sources of non-public data from key areas of public administration (transport, health, social services…) by a clearly defined guarantor and editor. There is a greater emphasis on interoperability between EU Member States and PPDF will be ready to provide services for cross-border data exchange. In the realities of 2020, about 3,500 information systems out of a total of about 7,000 are connected to PPDF services. In addition to connecting all public administration information systems, the basic objective of the PPDF is to ensure that the connection for the relevant ISVS is not only reader-type (draw data) but also publisher-type (provide their data). It is only when all relevant public administration information systems are drawing on and providing PPDF services that we can speak of a interconnected data fund.

The basic services of the PPDF for authorised PPDF readers are:

  • Identification (assignment of an identifier) of the subject/object of the right held in the AIS and thus support pseudonymisation
  • Issuing data on the subject/right object according to the required context within the scope of the authorisations held in the RPP for the relevant AIS-supported agenda
  • Notification of changes to reference and agency data for data held in AIS
  • Support for claiming erroneous data

View of the Interconnected Data Fund

Interconnected Data Fund Rules

Data, documents, outputs and extracts

Central to the proper use and understanding of the meaning of the Interconnected Data Fund is an understanding of the difference between Data Provision/Use, Document Provision/Use, Information System Outputs and Information System Extract.

Data Provision/Use

At the business layer, a public authority that carries out the exercise of public administration, operates in an agenda that it has duly reported in the RPP, is obliged to use for these purposes the current state-guaranteed data from the RoW and furthermore to publish and draw on agenda data via the eGon Service Bus / Shared Service Information System. A private law entity (also as a SPUU) may also, subject to the legal authorisation to exercise public administration and to act in a certain agenda announced by the OVM, draw data from the basic registers, but only via the OVM AIS or Czech POINT forms. In Act No. 111/2009 Coll. - Act on Basic Registers, a new global authorisation for drawing OVM data from the RR will be established, while the RPP serves as a source of information for the information system of the RR in controlling user access to data in individual registers and agency information systems. This means that whenever a given subject attempts to retrieve a certain data or even to change (edit) it, the system assesses whether the subject will be allowed to work with the data provided by the public administration on the basis of the legal authorisation. In the RPP as a meta-information system for public administration performance, the authorisations within the agendas for extracting data from the RoI are listed, but also all data published by the state and local government using the eGon Service Bus / Shared Service Information System across the public administration. An important factor at the business layer in the extraction of data from the RoW and also the publication and extraction of data within the individual OVM AIS is to have a properly reported agenda in the RPP, which is a prerequisite.

The list of agendas maintained in the RPP is available at: https://rpp-ais.egon.gov.cz/gen/agendy-detail/

At the application layer, through the web services of the individual reference interfaces, which include the basic registers management information system, eGon Service Bus / Shared Services Information System, Czech POINT and the form-based agency information system FAIS, the institution is obliged to draw reference data from the RO by its AIS and to further provide and use the data via IeGon Service Bus / Shared Services Information System across the public administration. In addition, it is also possible to draw reference data from the CR via data repositories.

One of the rules of retrieving reference data by web services is to first identify your data trunk against the ZR and then log in to receive notifications of changes. Another option, but in extreme cases if the institution's data trunk is not very large, is to perform periodic updates of the entire data trunk to identify the subject of the RR in the exercise of public administration.

Another rule for the handling of personal data is pseudonymisation of data, which means storing the data using the technique of separating the agenda and identification data and linking them by means of an agenda identifier of natural persons (also referred to as AIFO), in order to meet the conditions of security and the various laws and regulations that arise from these circumstances. The retrieved AIFO must not under any circumstances leave the AIS that retrieved it from the ISZR services and must always use the ISZR services when transmitting it (for the purpose of transmitting information about the natural person). More information on how AIFO is used in the context of pseudonymisation is provided in here.

In terms of the technology layer, it is purely up to the individual institution what platform they choose within the internal workings of the authority to connect to in order to use the services of the Interconnected Data Fund, whereby access to the ZR can be via the ISZR directly via AIS or the communication bus.

At the communication layer, the institution is obliged to use the CMS in the exercise of public administration. The CMS is a system whose primary purpose is to provide a controlled and registered connection of information systems of public administration entities to services (applications) provided by information systems of other public administration entities with defined security and SLA parameters, i.e. access to eGovernment services. CMS can thus be called a private network for the performance of public administration on the territory of the state. CMS as a private network of public administration uses dedicated or leased network resources for secure interconnection of public administration officials (also referred to as OVS) working in public administration agencies with their remote agency information systems, for secure network interconnection of agency systems with each other and for secure access of individual OVS to the Internet.

Provision / Use of documents

Documents are transferred through a reference interface in relation to a subject or object of law via the eGON Service Bus / Shared Service Information System, or also via the data box information system. Documents are created by output from the public administration information system according to law no.365/2000 Coll..

Extracts from the public administration information system

An extract from the public administration information system is a document that is created from public and non-public records. An extract may take the form of a partial or full extract of all data held in the public administration information system.

  • Extraction from a public record: the extract is not intended for a specific person and all the information contained is public.
  • Extraction from non-public records: the extract is intended for a specific person who is the subject of a right or another authorised person and includes non-public information.

Extracts are created according to Law No. 365/2000 Coll.

Outputs from the public administration information system

An output from the public administration information system is an electronic document which is an extract from the public administration information system, but which is also secured in a way that ensures data integrity. That is to say, it is an extract from a public administration information system that is electronically sealed/signed and time-stamped by the issuing public administration information system.

There is also a special variant of the output from the public administration information system, the so-called verified output, which is created by a complete conversion of the output from the public administration information system from electronic to documentary form and contains the elements according to Act No.365/2000 Coll.. The certified output is therefore always in documentary form.

Public document

According to the Civil Code, a public document is a document issued by a public authority within the limits of its powers or a document declared a public document by law. If a fact is certified in a public deed, it establishes against everyone full proof of the origin of the deed from the authority or person who established it, of the time of the creation of the deed, and of the fact which the originator of the public deed certified to have occurred or been performed in his presence, until the contrary is proved. Where a public instrument records the manifestation of the will of a person in a legal act and is signed by the actor, it shall constitute full proof against anyone of such manifestation of will. This applies even if the signature of the actor has been substituted in the manner provided by law.

A public instrument is all:

  • listic extracts from the public administration information system,
  • outputs from the public administration information system,
  • verified outputs from the public administration information system.

Full electronic submission

Popis úplného elektronického podání

Úplné elektronické podání (také jako "ÚEP") je možné popsat tak, že klient/občan, ale i zástupce právnické osoby, má možnost vyřídit všechnu svou potřebnou agendu životní situace, prostřednictvím elektronické interakce samoobslužně kdykoli a odkudkoli či asistovaně z kteréhokoli univerzálního kontaktního místa VS, bez nutnosti osobní návštěvy na příslušných úřadech, a následně možnost mít přehled o stavu a vývoji všech svých řešených životních událostí.

Současně pojem ÚEP představuje pokročilou variantu elektronického podání (elektronické formy úkonu klienta, občana a/nebo organizace vůči veřejné správě ČR), která splňuje sadu požadovaných vlastností, daných primárně tzv. architektonickými principy eGovernmentu a dále vlastnosti předpokládané pro podání vůči veřejné správě právními předpisy, zejm. správním řádem a agendovými zákony.

Elektronické podání klienta vůči veřejné správě je považováno za úplné, pokud splňuje všechny architektonické principy eGovernmentu a další náležitosti, zejména pak:

  • Podporuje princip Digital by Default tím, že je navrženo jako vnitřně plně digitální (nikdy se nemusí tisknout nebo osobně řešit), s tím, že ale podporuje asistovanými formami i tzv. elektronicky handicapované.
  • Podporuje princip Whole-of-Government tím, že je dostupné rovnocenným způsobem ve všech elektronických kanálech eGovernmentu (samoobslužných i asistovaných), s upřednostněním univerzálních kontaktních míst (CzechPOINT a PO v PVS).
  • Podporuje princip Once only tím, že pro předvyplnění formuláře i pro navigaci a volbu služby jsou využity všechny údaje o klientovi, které veřejná správa má a ze zákona je v dané situaci smí použít.
  • Podporuje principy Interoperability by Default a Cross-border by default tím, že umožňuje elektronicky obsloužit všechny klienty, rezidenty ČR a EU, pro které je úkon relevantní, a to i vzdáleně ze zahraničí.
  • je po podání automatizovaně strojově zpracováno, převedeno do transakčního záznamu agendového informačního systému.
  • Podporuje princip Inclusion and Accessibility tím, že podporuje asistovanými formami i tzv. elektronicky (nebo jinak) handicapované.
  • Využívá Jednotný identitní prostor veřejné správy a Elektronickou identifikaci pro klienty veřejné správy .
  • Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.

Všechny obslužné kanály veřejné správy musí být cílově vzájemně integrovány tak, aby mezi nimi bylo možno libovolně přecházet i v průběhu vyřizování podání a aby všechny informace byly zachovány, přenášely se do nich (mezi nimi).

Pravidla úplného elektronického podání

Úřad musí respektovat všechny návazné funkční celky jako např. propojený datový fond, portály veřejné správy či komunikační infrastrukturu veřejné správy a procesně zajistit zpracování podání tak, aby probíhalo elektronicky po celou dobu jeho životního cyklu.

Úřad pro splnění požadavků kladených na úplné elektronické podání musí splnit svými obslužnými kanály (např. portál):

  • Využití Jednotného identitního prostor veřejné správy pro úřední osoby a Elektronickou identifikaci pro klienty veřejné správy.
  • Předvyplnění podání všemi státu známými údaji klientovi po prokázání elektronickou identitou. Zajištění tohoto požadavku se splní čerpáním údajů z Propojeného datového fondu.
  • Má služby svých agend v rámci ÚEP a jejich IT aplikace navrženy tak, aby služby bylo možno v obslužných kanálech kombinovat pro efektivním řešení životních událostí.
  • Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.
  • Postupně všechna existující práva a povinnosti ze vztahu k VS budou doprovázena transakční službou (nejenom popisem návodu) v Portálu občana, a to v těch všech případech, kdy elektronická transakční služba bude proveditelná a bude odpovídat oprávněným zájmům klientů a současně i úřadů.
  • Elektronické podání formou ÚEP lze uskutečnit i papírově (off-line), tzn. půjde stáhnout předvyplněný formulář, ručně vyplnit, zaslat datovou schránkou nebo elektronicky podepsané doručit jakkoli jinak (i mailem, vložením do portálu), případně vložit do elektronické aplikace úřadu.
  • V případě menší četnosti podání stačí jeden z obou kanálů (on-line nebo off-line), musí však umožňovat dobrou (personalizovanou) navigaci ke službě a k jejímu předvyplnění.
  • Stejnou službu lze získat s pomocí služby úředníka na kterémkoli fyzickém kontaktním místě asistovanou formou. Pro typové a jednoduché podání pro řešení typových životních situací to takto bude možné na Univerzálních asistovaných kontaktních místech.
  • Zůstanou zachovány tradiční kanály pro příjem listinných podání osobně, diktátem do protokolu nebo poštou – úřední přepážky a podatelny. Jejich úkolem ale bude obdržené vstupy neprodleně plně digitalizovat, aby celé další následné zpracování bylo jednotně plně elektronické.
  • Nedílnou součástí řady podání je splnění finanční povinnosti (poplatku, daně). Platební brána tedy musí být součástí obslužného rozhraní. Pro agendy v samostatné působnosti je platební brána plně v zodpovědnosti koncového úřadu, pro agendy v přenesené působnosti musí o způsobu rozhodnout správce agendy.
  • Elektronické samoobslužné služby pro klienty/občany i pro právnické osoby musí být doplněny interaktivním podpůrným a poradenským kanálem (service-desk, call-me-back, apod.).
  • Podání nemusí vždy činit ta osoba, která je přihlášena elektronickou identitou, ale může se jednat o osobu zastupující jinou osobu. Úřad tedy musí zajisti správu mandátů.
  • Pro individuální přizpůsobení uživatelského rozhraní musí úřad využívat tzv. klientské profily. Každý jedinečný a jednoznačně identifikovaný klient má profil jenom jeden. V tomto profilu jsou uchovávány osobní i agendové údaje ve shodě se pravidly správy údajů Právní aspekty pro pseudonymizaci.
  • Podání zadané či zpracované v rámci řešení pro ÚeP musí být vždy přijímáno na podatelně a evidováno v systému eSSL nebo samostatné evidenci dokumentů v souladu se zákonem o archivnictví a spisové službě. Jejich přijetí musí být potvrzeno příslušnou odpovědní zprávou.

Electronic Deeds and Service

Universal Public Administration Contact Point

Document Management System

Přístupnost informací

Elektronická fakturace

Shared Services (Application and Integration Layer)

Basic registries and reference data

Information Systems Integration

Public administration and private data user portals

Electronic identification for public administration clients

Unified Identity Space for Public Administrations

Unified service channels and user interfaces for civil servants

Public Data Pool

Infrastructure (infrastructure and technology layer)

Public Administration Communications Infrastructure

eGovernmentCloud

Popis eGovernment cloudu

Základním cílem projektu eGovernment Cloud (dále také jako "eGC"), je zvýšení efektivity, rozsahu poskytovaných služeb, kvality a bezpečnosti a zároveň snížení nákladů provozu informačních systémů a aplikací veřejné správy, a to využíváním sdílených ICT služeb na úrovni infrastruktury, výpočetních platforem a standardizovatelných aplikací. Tím dochází k naplnění strategie 3E při současném zvýšení kvality a bezpečnosti při pořizování a provozu informačních systémů veřejné správy využíváním sdílených cloudových služeb eGC. Dalším cílem projektu eGC je v maximální míře usnadnit jednotlivým správcům ISVS architektonické, bezpečnostní, nákupní a projektové procesy využíváním služeb eGC.

Informační koncepce ČR zohledňuje základní cíle a koncepty eGC, stanovené usnesením Vlády ČR ve Strategickém rámci Národního cloud computingu (UV 1050/2016) a rozpracovávané v rámci projektu Příprava vybudování eGovernment cloudu, jehož výstupy byly schváleny v listopadu 2018 vládou ČR (UV 749/2018).

Služby eGC zahrnují tři hlavní kategorie cloudových služeb: IaaS (Infrastructure as a Service – služby na úrovni datových center, sítí a HW), PaaS (Platform as a Service – služby na úrovni standardních SW platforem, jako jsou databáze, webové servery) a SaaS (Software as a Service – kompletní funkcionalita standardních nebo standardizovatelných aplikací poskytovaná jako služba, např. e-mail, ekonomický systém, spisová služba apod.).

Služby eGC jsou poskytovány komerční částí eGC (KeGC - služby provozované komerčními subjekty s využitím jejich vlastních datových center a komunikační infrastruktury) a státní částí (SeGC – služby provozované v datových centrech a na HW a SW platformách v majetku státu a provozované organizacemi řízenými státem – poskytovatelem státního cloud computingu).

Součástí vybudování eGC je i konsolidace datových center a HW platforem, čímž se rozumí postupný přesun provozu většiny informačních systémů a aplikací veřejné správy z datových center jednotlivých institucí do vybraných datových center státu (státní část eGC), resp. do datových center ověřených komerčních subjektů (komerční část eGC). Konsolidovaná infrastruktura a HW/SW platformy budou poskytovány formou IaaS a PaaS služeb eGC. Vybudování těchto služeb zahrnuje mj.:

  • definici minimálních standardů pro poskytování IaaS a PaaS služeb pro státní a komerční část eGC,
  • sjednocení provozního prostředí informačních systémů a aplikací provozovaných ve státní části eGC na několik vybraných platforem,
  • zajištění potřebné bezpečnosti, spolehlivosti, škálovatelnosti a jednotnosti provozu ICT služeb.

Součástí vybudování eGC je dále postupná definice standardů pro vybrané softwarové aplikace podporující stejnou agendu či podpůrný a administrativní proces. Standardizované aplikační služby budou poskytovány formou SaaS služeb eGC. Využití standardizovaných aplikací přispěje ke standardizaci pracovních postupů (byznys procesů) ve veřejné správě.

Vybudování eGC umožní organizacím veřejné správy, aby se více soustředily na svoje klíčové procesy místo podpůrných procesů typu zajištění provozu informačních systémů a aplikací. Organizace však musí i nadále být schopny definovat svoje požadavky na ICT služby a integrovat je do svých klíčových procesů.

Jedním ze základních pravidel pro využití služeb SeGC nebo KeGC je zajištění požadované úrovně bezpečnosti eGC služeb v závislost na bezpečnostní úrovni informačního systému veřejné správy, pro který jsou služby eGC využívány. Tato bezpečnostní úroveň se odvozuje od bezpečnostních dopadů daného IS. Zařazení poptávaného cloud computingu do bezpečnostní úrovně provádí orgán veřejné moci podle vyhlášky č. 315/2021 Sb., o bezpečnostních úrovních pro využívání cloud computingu orgány veřejné moci. SeGC zajistí nejvyšší kritickou úroveň bezpečnosti a je určen pro provoz služeb eGC nejvyšší bezpečnostní úrovně (automaticky to jsou informační nebo komunikační systémy, které jsou kritickou informační infrastrukturou podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti). KeGC je určen pro provoz služeb eGC ostatních bezpečnostních úrovní a v maximální míře umožňuje využití tržních mechanismů pro zajištění optimálních cen.

U moderně navržených ISVS pro provoz v cloudu lze provést dekomponování, což vede ke zvýšení efektivnosti využívání prostředků při vývoji a provozování těchto informačních systémů. Dekompozice zároveň umožňuje hybridní provoz s využitím služeb cloud computingu různé bezpečnostní úrovně (dále jen „BÚ“).

Druhým rozhodujícím kritériem pro využití služeb eGC je kalkulace a porovnání nákladů vlastnictví (TCO) jednotlivých IS v modelu provozu on-premise (na vlastní infrastruktuře) a s využitím služeb eGC. Ke stanovení ekonomické náročnosti je dostupný Kalkulátor nákladů ISVS provozovaného v cloud; včetně uživatelské příručky.

Každý úřad si také musí být vědom toho, že financování cloudových služeb se liší od provozu vlastního řešení. Při provozu a nákupu vlastních technologií jde o tzv. CAPEX, tedy kapitálové výdaje, a pořízené věci zůstávají v majetku úřadu. Naopak nákup cloudových služeb je tzv. OPEX, tedy provozní výdaje, kdy úřadu v majetku nic nezůstává a platí si pouze službu. S tímto odlišným způsobem financování je třeba počítat při tvorbě rozpočtu a jeho čerpání, protože při využívání cloudových služeb pro celou infrastrukturu úřadu se razantně zvýší provozní výdaje a sníží investiční.

Oblast cloud computingu je od 1. 8. 2020 regulována příslušnými ustanoveními zákona č. 365/2000 Sb., o informačních systémech veřejné správy, kde v Hlavě VI zákona je zaveden mechanismus zápisu poptávek a nabídek cloud computingu do katalogu cloud computingu a zavedena povinnost orgánů veřejné správy využívat pouze takový cloud computing, který byl na základě splnění podmínek uvedených v zákoně zapsán Digitální a informační agenturou do katalogu cloud computingu.

Na webových stránkách Digitální a informační agentury je dostupný Metodický návod pro zápis poptávky a nabídky cloud computingu do katalogu cloud computingu.

Poskytovatelé služeb eGC musí splňovat zákonem určené podmínky, které zahrnují zejména oblast bezpečnosti poskytovaných služeb a jejich provozních parametrů, ale také důvěryhodnosti poskytovatele. Splnění podmínek ověřuje Digitální a informační agentura ve spolupráci s Národním úřadem pro kybernetickou a informační bezpečnost a dalšími složkami státu. Požadavky, které musí splnit poskytovatel cloud computingu, aby byla jeho nabídka zapsána do katalogu cloud computingu, stanovuje vyhláška č. 316/2021 Sb., o některých požadavcích pro zápis do katalogu cloud computingu.

Rozsah údajů vedených v katalogu cloud computingu o poptávkách, nabídkách a využívaném cloud computingu specifikuje vyhláška č. 433/2020 Sb., o údajích vedených v katalogu cloud computingu.

Řídící orgán eGovernment Cloudu (také jako ŘOeGC) koordinuje budování a rozvoj eGC, rozvíjí a udržuje metodické postupy pro eGC, kontroluje a řídí soutěžní mechanismus KeGC a nabídku služeb SeGC.

V současné době je umísťování IS orgánů veřejné správy do eGC (využívání služeb eGC) zcela dobrovolné, přičemž se uplatňuje princip mandatory-compare. Podle § 5 odst. 2 písm. j) a k) zákona č. 365/2000 Sb., o informačních systémech veřejné správy, resp. vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy mají orgány veřejné správy povinnost zajistit si ekonomické zhodnocení výhodnosti provozu ISVS. Orgán veřejné správy musí provést kalkulaci TCO, takže umístění on-premise pro nově pořizované systémy nebo v rámci technického zhodnocení anebo rozvoje spravovaného informačního systému veřejné správy bude nadále možné pouze tehdy, pokud kalkulace TCO neprokáže, že je nákladově efektivnější než umístění do eGC.

Bezpečnostní pravidla pro orgány veřejné správy, která musí nastavit, pokud využívá cloud computingu jsou dána vyhláškou č. 190/2023 Sb., o bezpečnostních pravidlech pro orgány veřejné moci využívající služby poskytovatelů cloud computingu.

Co je a co není cloud dle zákona

Upřesnění definice služeb třídy SaaS aneb jaká aplikační řešení, která orgány veřejné správy využívají/poptávají, lze považovat za cloud computing ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy?

Aplikační řešení, která jsou cloud computing třídy SaaS ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy , musí splňovat současně tyto podmínky:

  1. slouží více správcům ISVS (orgány veřejné správy (dále jen „OVS“) v roli tenantů), kteří jej využívají k provozu vlastních ISVS, nebo jiným zákazníkům (mimo OVS) a zároveň
  2. jsou provozovány na sdílené platformě cloud computingu třídy IaaS, příp. PaaS

Podmínka 2) může být splněna jedním ze dvou způsobů:

  • SaaS je provozován na službách IaaS/PaaS samostatně zapsaných do katalogu CC tímto nebo jiným poskytovatelem CC,
  • SaaS je provozován na službách IaaS/PaaS téhož poskytovatele CC, který nabízí SaaS, ale služby IaaS/PaaS využívá pouze pro provoz daného SaaS. V tomto případě služby IaaS/PaaS se do katalogu CC samostatně nezapisují. Existence a účinnost bezpečnostních opatření, která jsou zajišťována jednotlivými vrstvami provozní infrastruktury a která jsou vyžadována pro službu SaaS v dané bezpečnostní úrovni, se ověřují na základě „Podkladů pro ověření SaaS“, které ve své žádosti o zápis služby do katalogu CC uvedl poskytovatel SaaS.

Tyto služby typu SaaS mohou být využívány pouze v souladu s Hlavou VI ZoISVS a mj. musí být celý „stack“ IaaS/PaaS/SaaS zapsán v Katalogu CC. Zároveň musí být zapsáni všichni poskytovatelé CC (ať už materiální poskytovatelé, distributoři nebo koncoví poskytovatelé).

Aplikační řešení, která nejsou CC ve smyslu ZoISVS (a nepovažujeme je za CC třídy SaaS), jsou taková, která

  • slouží více správcům ISVS (OVS), ale jsou pro každého správce provozovány na nesdílené (dedikované) výpočetní infrastruktuře;
  • slouží pouze pro jednoho správce ISVS (OVS), přičemž může jít o aplikaci umožňující vzdálený přístup přes Internet nebo přes vnitřní síť CMS/KIVS pro mnoho externích uživatelů (např. aplikace pro podání přihlášky na střední školu, nebo aplikace využívané jednotlivými uživateli z řad OVS/OVM, avšak s centrální správou uživatelských účtů a báze dat ze strany toho jednoho správce ISVS), i když je provozována na platformě CC třídy IaaS, příp. PaaS (tato platforma však podléhá povinnosti zápisu do katalogu CC).

Upozorňujeme, že je nutné vždy uvažovat o ISVS v rozsahu ZoISVS, tzn. ve vymezení uvedeném v § 1 ZoISVS (zejména s ohledem na výjimky v odst. (2), (3) a (4) § 1 ZoISVS).

Katalog cloud computingu

Katalog cloud computingu dle zákona o informačních systémech veřejné správy naleznete na webu Digitální a informační agentury.

Nástroj pro vyhledávání v katalogu cloud computingu naleznete přímo zde nebo na této stránce níže. Jedná se o vyhledávací nástroj nad katalogem cloud computingu (dále jen „CC“).

Zde zveřejněné služby CC splnily v rámci zápisu nabídek CC veškeré požadavky zákona č. 365/2000 Sb., o informačních systémech veřejné správy pro zápis do katalogu CC, a to v dané bezpečnostní úrovni.

V katalogu CC lze vyhledávat:

  1. konkrétní služby CC materiálních poskytovatelů tzn. nepřímý prodej služeb CC materiálních poskytovatelů a přímý prodej služeb CC od materiálních poskytovatelů (*)
  2. konkrétní služby CC přeprodejců tzn. přímý prodej služeb CC od přeprodejců 1)
Nástroj pro vyhledávání v katalogu cloud computingu

Pravidla eGovernment cloudu

Přístup správců ISVS k eGC

Každý správce centralizovaného poskytovaného agendového informačního systému by měl postupně činit při správě a rozvoji svých informačních systémů takové kroky, aby oddělil vrstvu platformy a technologií od vrstvy komunikační a aplikační vrstvy příslušných informačních systémů. To znamená, že by se svými postupnými kroky měl připravit na to, že od určité doby bude provozovat svoje centralizované agendové informační systémy v cloudu a měl by postupně omezovat svoji závislost na vlastních datových centrech a pouze jím provozovaných technologických platformách.

Provozování AIS OVM v eGC v souvislosti s komunikací pomocí CMS/KIVS

Umístění AIS OVM v eGC znamená, že eGC je jen jiná adresa daného OVM. Zde jsou dvě možnosti přístupu do CMS:

  1. Připojené do CMS/KIVS je OVM a AIS v eGC je přesměrován do CMS/KIVS přes OVM (př. Portál občana). Pro tento scénář je AIS v eGC brán jako interní AIS OVM, který se připojuje do CMS/KIVS přes připojení daného OVM
  2. Poskytovatel eGC má zřízenou KIVS linku do CMS. Skrze tuto KIVS linku si jednotlivá OVM mající ASIy v cloudu vytváří svá VPN do CMS. (př. (AISy Městských policií si sahají na Základní registry)

Publikování portálu OVM

Publikování portálu OVM je specifický případ publikování AIS OVM, kdy se v rámci provozu portálu v eGC umožňuje, aby byly služby portálu dostupné pro klienty, kteří nejsou OVM, prostřednictvím internetu přímo od poskytovatele eGC.

Portál je v případě provozu na vlastní infrastruktuře publikován výhradně prostřednictvím CMS službou CMS2-02 Zveřejnění aplikace a to do:

  1. Do sítě CMS/KIVS, služba CMS2-02-1 a/nebo
  2. Do sítě Internet, služba CMS2-02-2

V případě umístění portálu v eGC, je umožněna publikace portálu z eGC, kdy:

  1. eGC je rozšířeným IP prostorem CMS/KIVS a
  2. CMS/KIVS a eGC jsou propojeny standardním způsobem dle podmínek připojení se k CMS/KIVS.
  3. AIS OVM všech subjektů, kteří přispívají do portálu OVM v eGC, čerpají údaje o subjektu práva prostřednictvím referenčního rozhraní.

Klienti, kteří nejsou OVM, přistupují k portálu v otevřeném internetu přes HTTPS publikovaném přímo z eGC.

Povinnosti komerčních poskytovatelů služeb eGC

Konkrétní povinnosti stanoví zákon o informačních systémech veřejné správy a na základě tohoto zákona pak vydané vyhlášky ministerstva a NÚKIB. Řídící orgán eGovernment Cloudu pak na základě zákona a vyhlášek připravuje a vydává metodické pokyny. Již nyní však platí pravidla pro nutnost připojení skrze infrastrukturu CMS/KIVS a tím i respektování katalogového listu služby připojení přes IPSec

Určování nástrojů osobní produktivity jako ISVS

Orgány veřejné správy se musí při poskytování interaktivních nástrojů osobní produktivity úředníka využívající cloud computing rozhodnout, zda jde o informační systém veřejné správy (ISVS) nebo jeho část ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), a mohou tak podléhat regulaci cloud computingu podle Hlavy VI tohoto zákona.

Dle § 2 odst. 1 písm. b) ZoISVS je: „informačním systémem veřejné správy funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy nebo plnění jiných funkcí státu anebo dalších veřejnoprávních korporací …“

Informační činností dle § 2 odst. 1 písm. a) se myslí: „získávání a poskytování informací, reprezentace informací daty, shromažďování, vyhodnocování a ukládání dat na nosiče a uchovávání, vyhledávání, úprava nebo pozměňování dat, jejich předávání, šíření, zpřístupňování, výměna, třídění nebo kombinování, blokování a likvidace dat ukládaných na nosičích. Informační činnost je prováděna správci, provozovateli a uživateli informačních systémů veřejné správy prostřednictvím technických a programových prostředků“.

Z definice ISVS vyplývá, že cílevědomá, avšak ne-systematická, informační činnost pro účely výkonu veřejné správy nemusí spadat pod rozsah definice. Scénáře interaktivního využívání nástrojů s podporou cloud computingu (jako jsou např. interaktivní nástroje umělé inteligence, volně dostupné on-line mapy nebo jazykové překladače) nesplní podmínku systematické informační činnosti výkonu veřejné správy, pokud využívání určitého konkrétního nástroje k určitému informačnímu účelu není interně v rámci orgánu veřejné správy ustanoveno jako závazné. Jestliže se tedy úředník sám rozhoduje ad-hoc, který a jestli vůbec nějaký on-line nástroj pro daný účel využije, nenaplní se tento atribut definice ISVS.

Naopak se lze domnívat, že systematické využití např. tabulkového kalkulátoru (např. MS Excel) v malé obci pro evidenci poplatků za psy nebo za hrobová místa naplní znaky „cílevědomé a systematické informační činnosti pro účely výkonu veřejné správy“, a tento informační systém by tedy měl být označen a spravován jako ISVS. Za rozlišující kritérium výkladu pojmu „systematická informační činnost pro účely výkonu veřejné správy“ tedy považujeme jakýkoli interní předpis OVS, který zavazuje úředníky využívat vždy určitý konkrétní nástroj (informační systém nebo jeho část) pro zabezpečení určitého účelu výkonu veřejné správy.

Ač tedy nástroje osobní produktivity jednoznačně spadají do definice informační činnosti, je potřeba vždy vážit hledisko systematičnosti pro účel výkonu veřejné správy.

Dále ještě zohledníme metodické vodítko Co je a co není ISVS. V kapitole „Pomůcka pro určování ISVS“ jsou uvedeny dvě pomocné otázky k rozhodování OVS, zda se v konkrétním případě nějakého informačního systému má jednat o ISVS:

  • Bylo by nefunkčností informačního systému bezprostředně narušeno nebo ohroženo plnění povinnosti vyplývající z kompetencí daného orgánu veřejné správy?
  • Jsou v informačním systému uloženy údaje o vykonávané správní činnosti nebo údaje pro podporu výkonu u této činnosti?

Pokud jsou odpovědi na tyto otázky ANO, s největší pravděpodobností se v případě posuzovaného informačního systému jedná o ISVS.

Toto vodítko může potvrdit výše vyslovený názor, že tabulkový kalkulátor instalovaný byť jen na jednom notebooku v rámci malé obce, který je však jediným zavedeným nástrojem pro správu určitých agend (viz výše), splní obě podmínky a měl by být tedy spravován jako ISVS.

Naopak, ad-hoc využití interaktivních nástrojů dle shora uvedených příkladů (interaktivní nástroje umělé inteligence, volně dostupné on-line mapy, on-line jazykové překladače apod.) zpravidla nedá odpověď “ano” na tyto dvě otázky metodického vodítka, a v takovém případě se nekvalifikuje jako ISVS.

NationalDataCenters

1)
z těchto služeb CC si mohou orgány veřejné správy v souladu se ZoISVS vybírat, který CC lze využívat

Discussion

Enter your comment: