Překlady této stránky:

Národní architektonický plán

Úvod

Dostává se vám do rukou Národní architektonický plán (také jako "NAP") jako základní pomůcka a rukověť pro zpracovávání, sjednocování, řízení a rozvoj architektury jak na centrální úrovni, tak v jednotlivých úřadech. V NAP nezjistíte, jak řídit ICT, ani jak spravovat portfolia projektů či tvořit informační koncepci. NAP popisuje věcný a technologický pohled na propojení systémů veřejné správy s centrálními sdílenými službami eGovernmentu a definuje, co mají správci informačních systémů činit ve své kompetenci a architektuře tak, aby byli v souladu nejen se současným stavem českého eGovernmentu, ale i s jeho plánovaným stavem.

Pro rozvoj všech schopností a dovedností veřejné správy, včetně rozvoje digitálních služeb VS, je nezbytné řídit veřejnou správu jako propojený komplexní systém služeb, poskytovaných orgány veřejné správy, s nadhledem a v celkových souvislostech. Protože většina transformačních kroků státu je stejně jako u podnikových korporací v současné době umožněna jen s pomocí ICT - digitalizací procesů a služeb, je celková architektura orgánů veřejné správy, jejich úřadů a veřejnoprávních korporací, současně prostředkem vývoje a řízení transformačních změn a současně prostředkem dlouhodobého řízení a rozvoje ICT na podpor těchto změn.

Posláním eGovernmentu je:

„Co nejefektivnějším způsobem poskytovat klientům veřejné správy služby, co nejvíce jim usnadňující jak dosažení jejich práv a nároků, tak splnění jejich povinností a závazků ze vztahu k veřejné správě“.

Úlohou úřadů a úředníků, podporovaných informačními systémy, je být služebníky a rádci, průvodci klientů na cestě za splněním jejich povinností a dosažením jejich nároků.

Government je činnost související s poskytováním veřejných služeb, řízením veřejných záležitostí na místní i centrální úrovni a zajišťováním záležitostí ve veřejném zájmu. Pokud je poskytování veřejných služeb zajišťováno elektronicky a dochází k digitální interakci mezi veřejností a veřejnou správou hovoříme o eGovernmentu, elektronické veřejné správě, která využívá informační a komunikační technologie k poskytování elektronických veřejných služeb občanům a podnikům. V širším slova smyslu považujeme za eGovernment veškeré elektronizované procesy veřejné správy, včetně interního zpracování agend a provozních procesů.

Cílem veřejného zájmu jsou tedy rychlejší, dostupnější, spolehlivější a levnější služby veřejné správy, které jsou díky jejich elektronické formě lépe obsahově a procesně sladěné, jsou sdílené subjekty veřejné správy, důvěryhodné pro obě strany interakce, propojené za účelem pokrytí životních situací a dostupné odkudkoliv zabezpečenou formou komunikace.

IKČR a NAP navazuje zejména na cíle eGovernmentu formulované ve Strategickém rámci rozvoje veřejné správy ČR pro období 2014-2020 a jeho akčních plánech, na dnes již zrušenou Strategii rozvoje ICT služeb veřejné správy (usnesení vlády ze dne 2. listopadu 2015, č. 889), usnesení vlády ze dne 27. ledna 2020, č. 86 a především na Informační koncepci ČR (usnesení vlády ze dne 3. října 2018, č. 629).

Odbor Hlavního architekta eGovernmentu Ministerstva vnitra ČR

Odbor Hlavního architekta eGovernmentu Ministerstva vnitra ČR (také jako "OHA"), jako nadresortní architektonický útvar eGovernmentu, rozpracovává principy stanovené vládou ČR v Informační koncepci ČR (také jako "IKČR") do referenčních modelů, závazných architektonických vzorů a dalších dokumentů Národního architektonického plánu.

Tyto informace následně slouží orgánům veřejné správy (také jako "OVS") k sestavování informačních koncepcí jejich úřadů a z nich vyplývajících projektových záměrů. OVS jsou podle příslušných ustanovení zákona o informačních systémech veřejné správy (také jako "ISVS") povinny požádat OHA o schválení návrhů dokumentací programů obsahujících pořízení nebo technické zhodnocení informačních systémů veřejné správy, investičních záměrů akcí pořízení nebo technického zhodnocení informačních systémů veřejné správy nebo projektů informačních systémů veřejné správy určených k výkonu státní správy. Organizační složky státu jsou i nadále povinny žádat o schválení záměrů výdajů na ICT podle příslušných ustanovení usnesení vlády ze dne 27. ledna 2020, č. 86.

OHA vydává v návaznosti na požadavky zákona o ISVS a výše zmíněného usnesení vlády stanoviska k těmto žádostem zejména na základě posouzení shody architektury předkládaných záměrů s cíli a pravidly IKČR, NAP a dalších návazných dokumentů OHA.

Informační koncepce České republiky

Informační koncepce České republiky je základním dokumentem, který stanovuje na základě zmocnění podle § 5a odst. 1 zákona 365/2000 Sb., o informačních systémech veřejné správy, cíle České republiky v oblasti informačních systémů veřejné správy (také jako ISVS) a obecné principy pořizování, vytváření, správy a provozování informačních systémů veřejné správy v České republice. IKČR se aktualizuje v pětiletých cyklech a je vždy schvalována vládou.

Pro efektivní realizaci cílů České republiky v oblasti informačních systémů veřejné správy IKČR zavádí Národní architekturu VS ČR (také jako "NA"), Národní architektonický rámec VS ČR (také jako NAR) a Národní architektonický plán VS ČR jako prostředky pro popis architektury orgánů veřejné správy a architektury jimi využívaných informačních systémů veřejné správy. NAR a NAP popisují základní nástroje pro formulaci cílů a principů Informační koncepce ČR a informačních koncepcí jednotlivých orgánů veřejné správy.

IKČR v navazujícím dokumentu č. 1: Metody řízení ICT veřejné správy ČR definuje pravidla, včetně orgánů a rolí odpovědných za jejich uplatňování v celém životním cyklu ICT služeb veřejné správy, tedy definuje pravidla strategického řízení IT, plánování, přípravy a implementace ICT projektů, provozu ICT služeb, řízení ekonomiky a bezpečnosti ICT služeb a pravidla kontroly a auditu (governance) ICT. IKČR v této příloze současně definuje základní požadavky na řízení a rozvoj orgánů veřejné moci a jejich útvarů informatiky tak, aby byly lépe schopny naplňovat cíle rozvoje služeb informačních systémů veřejné správy a řídit jejich životní cyklus.

IKČR v navazujícím dokumentu č. 2: Slovník pojmů eGovernmentu zavádí jednotný výklad pojmů a jejich případných synonym z platné legislativy, potřebných jako jeden z nástrojů koordinovaného budování eGovernmentu podle Národního architektonického plánu a pro koordinované řízení informatiky veřejné správy.

IKČR v navazujícím dokumentu č. 3: Národní architektonický rámec zavádí závaznou metodiku modelování, udržování a používání popisu architektury orgánů veřejné správy.

IKČR v navazujícím dokumentu č. 4: Národní architektonický plán orgánům veřejné správy – správcům informačních systémů - poskytuje jasnou a konkrétní představu toho, jak bude vypadat informatika VS ČR ve stanoveném horizontu 5 let, které prvky informatizace veřejné správy budou centrální a sdílené, které lokální prvky musí být jednotné podle předložených vzorů a které mohou být libovolné, jejich vzájemné vazby a návaznosti při současném dodržení stanovených architektonických principů.

Orgány veřejné správy podle IKČR a jejích příloh vytvářejí svou informační koncepci. Informační koncepce orgánů veřejné správy musejí být v plném souladu s IKČR a musejí z ní vycházet. V rámci NAP je v každé části kapitol Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady a Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury uvedeno, jakou část má úřad do své informační koncepce zapracovat.

Struktura Národního architektonického plánu

Struktura Národního architektonického plánu

  1. Kapitola Úvod - Obecný úvod a uvedení do problematiky
  2. Kapitola Architektonická vize eGovernmentu ČR - Popis cílů a možností, jak se k cílovému stavu dostat
  3. Kapitola Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury - Popis architektury eGovernmentu a úřadu skrze vrstvy architektury a její pravidla
  4. Kapitola Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR - Popis funkčních celků a tematických oblastí eGovernmentu z pohledu poskytovatelů těchto služeb.
  5. Kapitola Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady - Popis pravidel využívání funkčních celků a tematických oblastí v úřadu

Působnost Národního architektonického plánu

NAP je závazný pro všechny státní orgány a orgány územních samosprávných celků využívající centrální sdílené služby eGovernmentu, které § 1 odst. 1 zákona o ISVS souhrnně označuje pojmem orgány veřejné správy, tj. na „státní orgány nebo orgány územních samosprávných celků“, tedy včetně obcí a krajů.

V návaznosti na požadavky stanovené prováděcím právním předpisem předpokládaným v § 5a odst. 2, větě třetí, zákona o ISVS, představuje IKČR se svými následnými dokumenty včetně NAP základní obsahový rámec pro vytvoření, resp. aktualizaci vlastních informačních koncepcí jednotlivých orgánů veřejné správy, s jejichž vytvářením § 5a odst. 2 zákona o ISVS počítá.

NAP se v oblasti samosprávy vyznačuje některými odlišnostmi, které jsou dány definicí samosprávy. Jedná se zejména o:

  • Každá obec či kraj jsou samostatné subjekty a je jim možno ukládat povinnosti pouze zákony
  • Rozhodování obce je kolektivní (rozhoduje zastupitelstvo)
  • Obec může vykonávat mimo samosprávných činností i přenesenou působnost
  • Velikost samosprávných subjektů je velmi rozlišná – od krajů, které mají i více než milion obyvatel až po obce, které mají jen stovku obyvatel

Tyto odlišnosti se NAP snaží podchytit v oblasti některých ukládaných povinností - v doporučeních a ve využívání centrálních sdílených služeb eGovernmentu se však rozdíly mezi samosprávou a státní správou nedělají a obě části veřejné správy jsou z hlediska NAP rovnocenné.

Úřadem se pro účely NAP rozumí každý orgán, který je povinnou osobou z hlediska tohoto dokumentu. Pokud není uvedeno jinak, jsou to v souladu se zákonem o ISVS tzv. orgány veřejné správy, jak je zmíněno výše.

Ostatní orgány veřejné moci (také jako "OVM") a soukromoprávní uživatelé údajů (také jako "SPUÚ"), kteří nejsou OVS, například školy nebo nemocnice, mohou NAP využívat jako doporučení a tzv. dobrou praxi (best practices). V případě využívání centrálních sdílených služeb eGovernmentu jsou však i tyto organizace povinny řídit se principy a cíli NAP.

Periodicita a aktualizace dokumentu

NAP bude Ministerstvem vnitra vyhodnocován a aktualizován každý rok, vždy s výhledem na následujících 5 let, má tedy charakter tzv. klouzavého plánu.

K NAP budou přijímány připomínky a další relevantní podklady od organizací veřejné správy i mimo ni, které budou zapracovávány vždy s novou verzí.

Po každé aktualizaci bude NAP předkládán znovu ke schválení spolu s informací o dosažení definovaných cílů.

Základní pojmy řízení architektury veřejné správy a úřadu

Podstatné pojmy jsou souhrnně vedeny ve Slovníku pojmů eGovernmentu.

Základní architektonické principy

Domény Národní architektury veřejné správy

Pro modelování Národního architektonického plánu VS ČR i pro formulování principů a pravidel IKČR a jejich dekompozici se využívají následující architektonické domény architektury úřadů (a celé veřejné správy ČR), které jsou v souladu s Národním architektonickým rámcem.

Architektonické domény jsou děleny na horizontální domény (také nazývané vrstvy), odpovídající čtyřvrstvé vizi architektury VS a na vertikální domény, představující složky motivace a governance veřejné správy.

Horizontální domény (vrstvy) základních prvků architektury:

  • Byznys architektura – tedy architektura všech součástí výkonu veřejné správy a podpůrných provozních funkcí, zejména zaměřená na působnost OVM, služby, procesy, organizaci, role a zodpovědnosti.
  • Architektura informačních systémů, členěná na:
    • Informační (datovou) a
    • Aplikační architekturu
  • Technologická architektura, pro potřeby VS ČR dále dělená dle čtyřvrstvé vize architektury na:
    • architekturu IT technologií, také zvanou platformovou a
    • architekturu komunikační infrastruktury a datových center

Vertikální domény motivačních složek architektury:

  • Architektura strategie a směrování, původně také zvaná motivační architektura (v užším smyslu), nyní jedna ze složek motivace úřadu
  • Architektura výkonnosti, s měřítky dosahování strategie i provozní efektivity
  • Architektura rizik a bezpečnosti, postihující specifické bezpečnostní atributy napříč doménami včetně požadavků na kybernetickou bezpečnost
  • Architektura shody s pravidly a udržitelnosti, obsahující všechny prvky regulace fungování úřadů, od právních předpisů, přes normy a standardy až po vlastní zásady udržitelnosti.

Poslední doménou modelování je světle červená oblast, která představuje tzv. akční plán architektury úřadu (Roadmap) a umožňuje vizualizovat balíčky práce, projekty a jimi dosahované stavy architektury (přechodné a cílové).

Domény NAP

Koncepce referenčních modelů architektury úřadů VS

Referenční modely představují buď povinnou, nebo fakultativní (podle doprovodné informace u každého z nich) podobu architektury, tj. způsobu modelování a interpretace architektur úřadů.

Referenční modely budou vydávány převážně pro architektury celých úřadů nebo jejich podstatných částí, segmentů.

Pro vyšší využitelnost budou vedle generických, celostátně platných referenčních modelů, vydávány i referenční modely specifické pro určité odvětví (segment) veřejné správy, například zdravotnictví, oblast prostorových dat, infrastruktura apod., nebo pro úřady z jednotlivých vrstev hierarchie státní správy a samosprávy, se zahrnutím všech typů působnosti na dané úrovni (přímé, přenesené, samosprávné, soukromoprávní).

Lze očekávat vydání referenčních modelů na těchto úrovních:

  • Referenční architektury ústředních správních úřadů
  • Referenční architektury územních samospráv
    • Zjednodušený příklad architektury kraje a krajské korporace
    • Zjednodušený příklad architektury ORP a jeho korporace
    • Zjednodušený příklad architektury malé obce
  • Referenční architektury dalších typů orgánů veřejné moci - budou-li takové identifikovány.

Architektonické vzory klíčových oblastí úřadu

Budou vydávány architektonické vzory těch oblastí architektury úřadů (zejména procesní a aplikační), které sice zůstávají většinou v lokální zodpovědnosti, ale jejichž logická podoba musí být pro splnění cílů NAP centrálně předepsána a následně v řešeních dodržena. Jedná se zejména o tyto kategorie referenčních modelů procesní a aplikační architektury:

  • Multikanálová uživatelská rozhraní
    • pro klienty VS
    • pro zaměstnance VS
  • Klíčové části agendových IS
    • Sdílený agendový Front-office (CRM)
    • Specifický agendový Middle-Office (odborné části agendových IS), některé nadresortní (dotace, kontroly, údržba síťové infrastruktury státu, …)
    • Sdílený agendový Back-Office (platební, znalostní a další systémy)
  • Správa spisů, dokumentů a jejich toku (workflow)
  • Provozní ERP systémy
  • Prostorová data a služby nad prostorovými daty
  • Rozšiřující systémy správy zdrojů úřadu
  • Identity management
  • Integrační platformy
  • Správa kmenových dat a číselníků (s vazbou na ZR i bez)
  • Business Intelligence (a její využití jak pro manažerské rozhodování, tak pro podporu transakčních agendových i provozních systémů)

Architektonické vzory využití sdílených služeb eGovernmentu

OHA bude postupně vydávat vzorové referenční schopnostní enterprise architektury a architektury řešení těch oblastí architektury úřadů, jejichž podoba musí být pro splnění cílů koncepce centrálně předepsána a následně v řešeních dodržena. Proto se nazývají povinnými architektonickými vzory, které budou OHA vyžadovány v rámci posuzovaných projektů ICT.

Typicky se bude jednat o oblasti architektury využívající sdílené služby eGovernmentu nebo o další oblasti, v nichž bude pro naplnění zákonných povinností nebo dosažení efektivity žádoucí jednotné, standardizované řešení. OHA bude vydávat také detailní architektonické vzory rozhraní pro využití sdílených služeb eGovernmentu, na úrovni jednotlivých služeb a další prvků řešení a designu těchto rozhraní a způsobu jejich využití v lokálních architekturách úřadů.

NAP zde ukládá povinnost respektovat v návrzích řešení tyto vzory tak, jak budou OHA publikovány, postupně a samostatně.

Architektonická vize eGovernmentu ČR

Vize architektury eGovernmentu, jako elektronizované veřejné správy, představuje cílovou podobu, jak bude eGovernment ČR vypadat a fungovat, až se podaří realizovat podstatnou část opatření uvedených v Informační koncepci ČR a v Národním architektonickém plánu.

Vize architektury veřejné správy zejména ukazuje, jak budou existující a dobudované pilíře sdílených služeb eGovernmentu používány k realizaci užitečných služeb veřejné správy pro její klienty na jedné straně a pro efektivní správu jejích zdrojů na druhé straně.

V průběhu časového horizontu NAP vydaného v září 2019 tj. v letech 2019 až 2024, budou stále více prosazovány změny, směřující k cílové vizi eGovernmentu a jeho IT podpory.

Naplňování této vize musí být nejen nedílnou součástí plánování a prosazování cílů digitalizace veřejné správy ČR v samotných úřadech a jejich útvarech informatiky, ale i základem politických cílů reformy veřejné správy ČR, které musí digitalizaci služeb veřejné správy a efektivní podporu výkonu veřejné správy s využitím ICT aktivně rozvíjet.

Celková architektonická vize informační podpory eGovernmentu

Veřejná správa ČR plně využije potenciál digitalizace, konsolidace a sdílení služeb na všech čtyřech vrstvách své architektury – byznysové, aplikační technologické (platformové) a komunikační (infrastrukturní).

Informační systémy veřejné správy se již nebudou navrhovat, implementovat a provozovat jako nedělitelný blok procházející všemi vrstvami architektury (z angl. pojmu Full-Stack), ale budou koncipovány ve vrstvách - všude kde to je možné se využijí sdílené služby na příslušné vrstvě. Primárně půjde o transformaci dosud roztříštěných a izolovaných ISVS do logicky centralizovaných agendových ISVS:

  • spravovaných celoplošně OVS odpovědným za agendu,
  • v datové vrstvě propojených navzájem propojeným datovým fondem a
  • využívající sdílené ICT platformy a virtualizace, např. formou PaaS či Cloudových služeb a
  • sdílenou komunikační infrastrukturu a sdílená datová centra.

Architektura veřejné správy bude plně podporovat orientaci na služby klientům a přitom informačními technologiemi plně a rovnocenně podpoří jak klienta při samoobslužných funkcích, tak úředníka v asistenčních a interních funkcích.

Bude zdůrazněna zodpovědnost úřadů veřejné správy za kvalitu výkonu svých služeb. Z pohledu občana bude veřejná správa sjednocována do dvou základních vnímaných oblastí - jako služby státu, dostupné kdekoli (v přímé i přenesené působnosti, zcela bez místní příslušnosti), a služby samosprávy, srozumitelně spojené s místem života a s jeho lidským společenstvím (obcí).

Obě tyto klíčové kategorie individuálních věcných služeb veřejné správy pro klienty budou prezentovány v univerzálních i místních kontaktních místech pomocí tzv. Katalogů uživatelských služeb, orientovaných primárně na řešení životních událostí klientů.

Současně a v návaznosti na to budou přibývající centrální a sdílené ICT služby pro podporu veřejné správy publikovány pro potřeby řízení informatiky úřadů v podobě Katalogu ICT služeb pro výkon veřejné správy. Prvním a základním předobrazem tohoto katalogu je Informační koncepce ČR a její přílohy včetně Národního architektonického plánu.

Klíčovým trendem a způsobem optimalizace veřejné správy bude hledání jednoty a podobnosti a hledání potenciálu k úsporám a efektivitě pomocí sdílení, a to na všech vrstvách architektury veřejné správy.

Následující schéma staví do kontrastu vzájemné doplnění místní individuální funkce úřadu a odpovídající sdílené služby. Potenciál pro poskytování a využívání sdílených služeb, a to jak centrálních, korporátních (v ministerstvu, kraji nebo ORP) nebo místních služeb, sdílených celým úřadem, existuje na všech úrovních veřejné správy a ve všech vrstvách architektury veřejné správy.

Přehled vrstev včetně funkcí a služeb

Základy a podstaty změn pro jednotlivé architektonické vrstvy

Byznys architektura - vrstva výkonu veřejné správy

Výkon veřejné správy byl dlouhou dobu realizován pouze ve fyzické a listinné podobě, tuto formu vládnutí, správy věcí veřejných, můžeme nazvat cizím názvem „Government“. S rostoucími možnostmi informačních technologií a prudkým nárůstem jejich využívání se z obyčejného "papírového" Governmentu stává jeho elektronická neboli digitální forma - „eGovernment“ neboli elektronické vládnutí. Na úrovni byznys architektury úřadu je důležité dobře znát jak reálný byznys úřadu, tj. všechny jeho procesy, funkce, role, zodpovědnosti apod., tak způsob centrální koordinace digitálních aspektů byznysu úřadu v rámci tzv. agendového modelu veřejné správy

  • Veřejná správa funguje vždy výhradně v mantinelech zákonů a zákonných povinností a používá metody, způsoby a prostředky které ji zákon umožňuje.
  • Základním zdrojem byznys modelu veřejné správy, včetně byznys modelu jednotlivých úřadů, je agendový model veřejné správy, legislativa vyjádřená eSbírkou a údaje o agendách zapsané v Registru práv a povinností.
  • Pro chod sdílených služeb IT podpory platí jen to, co je zapsáno v RPP. Údaje, které jsou v RPP v rozporu se skutečným stavem či legislativním záměrem, musí ohlašovatel příslušné agendy upravit.
  • Jakákoliv veřejnoprávní činnost úřadu musí vycházet z agendy a činností v RPP.
  • Nejsou-li správně uvedené údaje o agendě, nebudou moci úřady působící v agendě využívat nástrojů eGovernmentu a nebudou tak řádně plnit své zákonné povinnosti a poskytovat kvalitní služby klientům.

Základní právní rámec týkající se elektronizace na byznys vrstvě architektury veřejné správy je definován především následujícími zákony:

Zákonem o základních registrech se řídí zejména situace, kdy orgán veřejné moci působící v určité agendě v některém z agendových informačních systémů (AIS) má právo a povinnost na čerpání (využívání) referenčních či agendových údajů. Správné využívání údajů z registrů a jiných agendových systémů je podmíněno realizací správných procesních kroků, zajišťujících vedení věcně správného a aktuálního i historického datového kmene úřadu s pravidelným získáváním notifikací o změnách referenčních a agendových údajů.

Dle zákona o elektronické identifikaci se provádí identifikace a autentizace klienta veřejné správy - subjektu práva. Osoba (klient), se kterou (a pro kterou) se budou provádět jednotlivé úkony, bude ztotožněna v rámci základních registrů a bude jí poskytnut identifikační prostředek, vždy prostřednictvím osobou vybraného kvalifikovaného poskytovatele identifikační služby.

Dalším klíčovým prvkem digitalizace na této vrstvě jsou právní úkony podání a doručování přes datové schránky, které upravuje zákon o elektronických úkonech a autorizované konverzi. Toto podání má poté náležitosti plnohodnotného právního úkonu a jedním ze státem garantovaných elektronických podání.

Klient má právo na poskytování o něm vedených údajů z informačních systémů úřadů, což upravuje zákon o informačních systémech veřejné správy a řeší primárně tzv. Portál občana - součást portálu veřejné správy.

Klient má též právo na poskytování veřejných informací z informačních systémů úřadů, tj. informací podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, nebo podle dalších zvláštních předpisů upravujících poskytování informací veřejnosti, například zákona č. 123/1998 Sb., o právu na informace o životním prostředí, v podobě otevřených dat. Má též právo na poskytování výpisu individuálních údajů, které jsou o něm vedeny, dle zákona č. 365/2000 Sb.

schématické vysvětlení pojmů při práci s elektronickými údaji mezi klienty a úřady.

Podstata změn v byznys architektuře

Hlavní změnou je podstata toho, že digitalizace se stává běžnou součástí fungování veřejné správy.

V dalším vývoji eGovernmentu se zavádí transakční samoobsluha pro subjekty práva a její efektivní asistovanou alternativu pro elektronicky handicapované.

Individuální služby veřejné správy, představující konkrétní výstup procesů výkonu veřejné správy, prostřednictvím kterého klient (občan nebo zástupce organizace) využívá svá zákonná oprávnění (nároky) nebo naplňuje své zákonné povinnosti (závazky), budou stále více zaměřeny na praktické řešení individuálních životních situací, které klientovi ve vztahu k veřejné správě nastanou nějakou životní událostí, ať již z jeho vůle, z moci úřední, působením třetí osoby nebo jiné skutečnosti.

Součástí této změny bude rychle rostoucí podíl digitálních služeb, které bude moci klient získat a být obsloužen v univerzálních kontaktních místech, ať již samoobslužných (jako Portál občana) nebo asistovaných (jako CzechPOINT, Call-centrum veřejné správy a také univerzální přepážky úřadů územních samospráv).

Všechny služby veřejné správy tedy musí být postupně upravovány tak, aby byly rovnocenně, kdykoli a odkudkoli dosažitelné všemi obslužnými kanály.

Všechny lokální územní a resortní agendové portály (jako ePortál, Portál farmáře, eAgri, BusinesInfo, EPO, eHealth a eJustice, a další) budou postupně ve federativním uspořádání připojeny k centrálnímu Portálu občana, který tak bude jediným společným vstupním bodem ke všem elektronickým službám VS ČR.

Elektronické služby budou důsledně realizovány v autentizovaných prostorech obslužných kanálů, s plným využitím předvyplněných údajů z propojeného a z veřejného datového fondu VS. Elektronizace obsluhy klientů a výměny informací ve veřejné správě bude řešena tak, že bude přirozenou součástí práce úředníků, nebude je nijak zatěžovat navíc, nýbrž naopak jejich práce bude elektronizací usnadněna a urychlena, a to jak při:

  • vlastním výkonu agendových služeb nebo služeb pro řešení životní situace
  • výměně informací mezi úřady
  • asistenci klientům při podání nebo převzetí dokumentů
  • interních provozních úkonech zaměstnance a úřadu.

Elektronické služby pro klienty budou vycházet z jednotné a státem garantované elektronické identifikace občanů ČR (NIA) a identifikací občanů EU (eIDAS).

Důležitou roli ve zvyšování právního povědomí občanů i úředníků sehrají služby eSbírka a eLegislativa, jako jedny z klíčových znalostních systémů eGovernmentu.

Otevřená data se stanou pro orgány veřejné správy přirozeným a primárním způsobem zveřejňování informací, které jsou evidovány v ISVS při výkonu agend a lze je poskytovat veřejnosti jako informace podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, nebo podle zvláštních předpisů, jako je kupříkladu zákon č. 123/1998 Sb., o právu na informace o životním prostředí.

Otevřená data se též stanou pro orgány veřejné správy primárním způsobem získávání veřejných informací potřebných při výkonu agend, které jsou evidovány jinými orgány veřejné správy při výkonu jejich agend evidovány v jimi spravovaných ISVS.

V oblast provozních procesů veřejné správy bude pokračovat jejich korporátní i celostátní sjednocování a centralizace, s možností vzniku korporátních i celostátních center sdílených služeb, zejména v oblastech účetnictví a rozpočetnictví, nákupu a logistiky, personalistiky a mezd, správy majetku, informačních technologií, právních a komunikačních služeb apod.

Bude se zvyšovat míra vnitřní elektronizace provozních procesů i elektronická výměna dokumentů v obchodním styku, nejdříve pak zavedením eFakturace. Dostatek včas dostupných elektronických provozních a ekonomických informací povede k další optimalizaci a automatizaci provozních procesů (správa nemovitostí, controlling atd.)

Společně s tím poroste podíl samoobslužně elektronicky vykonávaných procesů, tzv. zaměstnaneckých samoobsluh, tak, aby do konce horizontu této koncepce byly procesy týkající se jednotlivých zaměstnanců, jejich vybavení a pracovního prostředí plně elektronické, tj. bezpapírové, s výjimkou samozřejmého zajištění podpory elektronicky handicapovaných zaměstnanců. Tyto vnitřní elektronické služby budou vycházet z jednotné identity úředníků, , resp. zaměstnanců ve všech typech zaměstnaneckých a služebních poměrů, v rámci tzv. autentizačního informačního systému podle § 56a zákona o základních registrech (JIP/KAAS). Tyto služby budou postupně publikovány na Portál úředníka a naplňovat ho obsahem.

Byznys architektura úřadů, zejména pak přehledové mapy schopností či procesů, se stane východiskem pro návrhy, plánování a řízení transformačních změn úřadů směrem k naplňování této vize, ale také východiskem pro navazující detailní modelování a optimalizaci procesů a služeb veřejné správy pro řešení životních událostí klientů, pro řízení a zlepšování výkonnosti a kvality těchto služeb a zodpovědnosti za ně.

Veřejná správa se při řízení celého úřadu naučí nesoustředit se jenom na jednotlivé nepropojené celky, ale naopak na co největší komplexitu při rozhodování i při výkonu veřejné správy. Znamená to především, že se naučí myslet v tzv. “multiagendovém přístupu”, tedy, že veškeré procesy, které lze použít ve více agendách, budou takto použity, a naopak u procesů, kde to zatím nelze, se bude hledat řešení, jak toho docílit. Cílem je poskytování komplexní služby klientovi, nehledě na to, v jaké je to agendě, nebo jaké prostředky jsou na poskytování služby vázány.

Za tímto účelem se bude prosazovat architektura úřadu jako celostní disciplína, jdoucí napříč celým úřadem - a de facto i nad něj. Také se zavede jednotné řízení procesů napříč všemi agendami, nikoliv po jednotlivých agendách či souborech činností. To znamená ustavení centrální rolí architektů úřadu i zvýšení spolupráce odborných gestorů v úřadu mezi sebou.

Konkrétně je nanejvýš vhodné společné činnosti a principy dělat v celém úřadě opravdu tak, aby byly společné. Kupříkladu, principy výkonu spisové služby jsou stejné pro celý úřad a pro všechny agendy, i když v jednotlivých agendách mohou být samozřejmě odlišnosti (jiný AIS integrovaný na eSSL apod.), nicméně budou nastaveny společné principy, a ty také společně kontrolovány.

Mezi provozními schopnostmi v byznys architektuře úřadu bude posílen význam řízení a správy informačních technologií a podíl informatiků na procesech řízení změn (již od návrhu proveditelné digitálně přívětivé legislativy), přes realizaci transformačních změn po zajištění dodávky očekávaných přínosů.

Kromě procesních a dalších činností zaměřující se na služby veřejné správy se zde uplatňuje i tvorba a údržba provozních řádů ISVS, kterých je úřad správce. Samotná tvorba provozních řádů ISVS je byznysová (procesní) záležitost, avšak obsah provozních řádů je většinou aplikační záležitost. Splnění této povinnosti musí být úřad schopen doložit dle § 5 zákona 365/2000 Sb.

Aplikační architektura - vrstva informačních systémů veřejné správy

Do aplikační vrstvy architektury se neřadí pouze jednotlivé informační systémy veřejné správy či agendové informační systémy, ale také provozní informační systémy a veškeré aplikační komponenty, které jsou v úřadu provozovány, nebo na které se úřad jakýmkoliv způsobem integruje.

Při vytváření modelu aplikační vrstvy architektury úřadu se velice často zapomíná právě na integrace, které z jedné strany reflektují byznys požadavky (jako je využívání údajů ze základních registrů a to integrací na rozhraní informačního systému základních registrů) a z druhé strany dodržování ostatních povinností týkajících se informačních systému veřejné správy, využívání základních komponent eGovernmentu, provozování IS jak u sebe tak v cloudu, užívání ostatních IS, a vzájemné vazby mezi mými informačními systémy a v neposlední řadě i vazby mezi informačními systémy OVS a IS jiných správců.

  • Součástí aplikační architektury úřadu jsou nejen IS, které OVS sám spravuje či provozuje, patří do ní i služby IS, které užívají jeho uživatelé, či IS, na které se integrují jeho aplikace.
  • Informační systém (dle zákonných zmocnění) je nutno vnímat jako logický celek, který je realizován jednotlivými aplikačními komponentami.
  • V modelech aplikační vrstvy architektury úřadu jsou nejen elementy pro logické IS a jejich komponenty, ale také jejich funkce a služby, integrační rozhraní (vnitřní i vnější) a elementy vyjadřující vzájemnou spolupráci aplikačních komponent.

Na aplikační vrstvě architektury úřadu jsou základní právní omezení definována především následujícími zákony:

Dle zákona o informačních systémech veřejné správy je účelné definovat správu ISVS, s rozlišením kompetencí a odpovědnosti věcného správce, technickeho správce a provozovatele. Zákon o kybernetické bezpečnosti odděluje kompetence a odpovědnosti správce informačního systému, správce komunikačního systému, provozovatele

schématické vysvětlení hierarchie a struktury ISVS

Podstata změn v aplikační architektuře

Informační systémy veřejné správy slouží primárně pro podporu výkonu veřejné správy nebo pro samotný výkon služeb veřejné správy. Budou poskytovat vhodné prostředky a funkce pro úředníka, který je zodpovědný za výkon činností v daných agendách nebo pro klienta, který se samo-obslouží. Ideální informační systém by měl úředníka či klienta provázet jeho činnostmi a v maximální míře mu jeho práci usnadnit, třeba automatizováním činností, u kterých je to možné včetně činností spojených s využíváním dat z jiných agentových ISVS.

Neznamená to primárně plně automatizované rozhodování veřejné správy, ovšem maximální usnadnění rozhodování a obsluhy klientů úředníky. Úředník nemá čas trávit administrativou, nebo dokonce získáváním či ověřováním rozhodných skutečností, to za něj bude dělat systém, ať už na základě žádosti či práva subjektu práva, nebo z moci úřední. Informační systém úředníkovi nabídne vždy relevantní informace a podklady pro rozhodování, je-li vůbec správní rozhodování v dané věci na místě. Výsledkem pak bude možnost připravit úředníkovi rozhodnutí v dané věci s využitím aktuálních a relevantních údajů.

Část změn aplikační architektury bude vyplývat přímo ze změn byznys architektury výkonu služeb veřejné správy. Tzn. například, že aplikace na podporu těchto služeb budou stále jednotnější z hlediska podpory řešení životních situací napříč resorty a napříč obslužnými kanály.

Aplikační podpora jednotlivých služeb veřejné správy musí být realizována tak, aby cílově bylo možno tyto služby dynamicky procesně orchestrovat do univerzálních obslužných kanálů kontaktních míst veřejné správy pro konfigurovatelné (složené) služby komplexního řešení individuálních životních situací klientů VS a otevřít je poskytovatelům služeb třetích stran pomocí otevřených API (tam kde to dovolují zásady kybernetické bezpečnosti).

Aplikační podpora bude realizována tak, aby zajišťovala zveřejňování údajů jako otevřená data a umožnila využívání otevřených dat ostatními orgány veřejné správy, pro jejichž potřeby je především nutno zajistit dostupnost otevřených dat.

Dále budou aplikace AIS upraveny tak, aby podporovaly službu pro subjekt práva s elektronickou identifikací, poskytující mu všechny údaje, které jsou o něm vedeny v neveřejných evidencích, jak ji přináší novela zákona o ISVS, účinná od 1. 7. 2018.

Sjednotí se a budou silně konsolidovat jak aplikace na podporu klienta, zejména celostátní Portál občana, i s ním federalizované portály ústředních správních úřadů a portály územních samospráv, tak aplikace na podporu práce úředníka, zejména transakční Portál úředníka, umožňující jednotný uživatelský zážitek a navigaci ke všem klíčovým systému úřadu, kde úředník působí a postupně i k rostoucímu množství do Portálu úředníka integrovaných služeb centrálních sdílených interních informačních systémů veřejné správy.

Před integrací uživatelů v obslužných aplikacích občana a úředníka, tzv. Front-Office integrace, má přednost integrace údajů výměnou elektronických informací mezi úřady, tzv. Back-Office integrace.

Bude docházet ke generační obnově velkých agendových systémů, k jejich komponentizaci a flexibilnímu otevírání službám více dodavatelů.

Současně bude v úřadech samotných napříč agendami, i v celém eGovernmentu napříč úřady a resorty identifikováno stále více aplikačních služeb, které budou poskytovány jako centrální sdílené služby, a to zejména jako sdílené služby eGovernment cloudu.

Příkladem jsou ISVS pro podporu služeb, realizovaných v přenesené působnosti. Výrazně se zvýší zodpovědnost úřadu ohlašovatele agendy za aplikační podporu agendy i zodpovědnost za data agendy. Tato koncepce předpokládá, že každý ohlašovatel agendy s přenesenou působností se stane věcným a technickým správcem odpovídajícího logicky centralizovaného elektronického registru (agendového IS), připojeného k Propojenému datovému fondu. Společně s přenesením agendy na úřady územních samospráv (KÚ, ORP, obce) nabídne ohlašovatel pro jejich uživatele i jím garantovanou dostupnou centrální aplikační službu, integrovatelnou s lokálními systémy (zejména eSSL, ERP) úřadu. V žádném případě není možné požadovat dvojí pořizování dat, samosprávní úřad může užívat i lokální aplikaci, pokud bude odpovídat za její legislativní přizpůsobování a bude využívat nabídnuté datové rozhraní na centrální ISVS (registr) takové služby. Ohlašovatel agendy prostřednictvím jím garantované centrální aplikační služby též zajistí poskytování údajů vedených v centrální aplikační službě v podobě otevřených dat.

Úměrně sjednocování a centralizaci provozních procesů veřejné správy na úroveň korporací a státu se budou sjednocovat, případně konsolidovat, případně centralizovat aplikace podporující tyto procesy. Podstatnou součástí změn v těchto aplikacích bude rapidně rostoucí podpora zaměstnaneckých samoobsluh.

S rozvojem eGovernment cloudu poroste nabídka SaaS služeb eGC (Software as a Service, služby na aplikační úrovni), zaměřená zejména na standardizované implementace provozních informačních systémů (jako je e-mail, eSSL, ERP, PIS) a standardní agendy obcí. Na SaaS služby eGC budou kladeny minimálně stejné architektonické požadavky jako na ISVS provozované on-premise.

Podstata změn v datové architektuře

Bude se výrazně rozšiřovat rozsah dostupných agendových a referenčních údajů v rámci propojeného datového fondu ČR.

V souvislosti s rostoucí výměnou elektronických údajů a zodpovědností za jejich kvalitu, i s jejich rostoucím ohrožením a ochranou, dojde k podstatnému nárůstu profesí, spojených se správou dat a údajů a jejich využíváním.

Bude docházet k posunu zaměření úsilí od stávajícího soustředění na referenční údaje a agendové údaje, přes důraz na transakční údaje a dokumenty, postupně i k analytickým a statistickým údajům a k efektivní podpoře jejich automatizovaného sběru a využití při řízení veřejné správy.

V případech, kde zákon umožňuje zveřejnění údajů o subjektech a objektech práva, vedených v základních registrech nebo agendových informačních systémech, budou tyto údaje poskytovány v podobě otevřených (optimálně také propojených) dat a v podobě propojených otevřených dat.

Na podporu národní i mezinárodní interoperability služeb veřejné správy bude docházet k postupnému sjednocování prvků konceptuálních datových modelů datového fondu jednotlivých ISVS a jim odpovídajících legislativních pojmů.

Sémantický slovník pojmů jako prostředek harmonizace sémantiky dat vedených v jednotlivých ISVS bude vytvářen na bázi výčtů údajů vedených k agendám v Registru práv a povinností dle § 51 odst. 5 písm. g), h) a i) zákona o základních registrech a bude je postupně rozpracovávat do podoby sdílených informačních modelů (ontologií), které budou propojeny s údaji vedenými v agendách a též propojovány se slovníky a ontologiemi vznikajícími z iniciativy EU (např. ISA Core Vocabularies). Logická schémata dat vedených v ISVS popisující jejich strojové (syntaktické) vyjádření na logické úrovni budou propojena na pojmy sémantického slovníku pojmů, čímž bude realizováno propojení sémantiky (významu) dat napříč jednotlivými ISVS. Díky propojení sémantického slovníku pojmů na údaje vedené k agendám a jejich propojení na legislativu bude též realizováno propojení sémantiky s legislativou.

Sémantický slovník pojmů bude využíván jak pro propojený datový fond, tak pro veřejný datový fond. Údaje zveřejňované jako otevřená data budou muset být opatřena publikovaným logickým schématem popisujícím strojově čitelným způsobem jejich datové struktury. Prvky logického schématu pak bude možné propojovat strojově čitelným způsobem na sémantický slovník pojmů a propojení publikovat jako otevřená data.

S využitím sémantického slovníku pojmů bude rozšířena funkcionalita NKOD o zobrazování kvalitnější dokumentace sémantiky datových sad a širší možnosti vyhledávání souvisejících datových sad. Konzumenti otevřených dat budou využívat sémantický slovník pojmů pro integraci otevřených dat získaných od různých poskytovatelů.

Technologická / Platformová architektura - vrstva HW a SW technologií

IT technologická architektury (také jako "platformová architektura") je vrstva zabývající se technologiemi, které svými funkcionalitami a službami podporují aplikace, systémy a obecně prvky z aplikační architektury. Oblasti platformové architektury se dají rozdělit na:

  1. Výpočetní výkon,
  2. datová úložiště,
  3. koncová zařízení (Firewall, Switch, obecně aktivní prvky).

Pro zachycení v této vrstvě není rozhodující, zda se jedná o vlastní HW a SW, či je kupovaný jako služba (Platform as a Service - PaaS). Důležité je zachytit, v jaké struktuře a komu se služby technologické vrstvy poskytují. Typickým příkladem jsou vlastní servery a disková pole poskytující služby výpočetního výkonu a datového úložiště pro informační systém veřejné správy. Servery si následně mezi sebou mohou poskytovat služby load-balancingu či replikace dat.

Na technologické vrstvě jsou základní právní omezení definované především následujícími zákony:

schématické vysvětlení platformové vrstvy

Podstata změn v IT technologické architektuře

Zásadním trendem na úrovni technologické vrstvy je využití sdílených platforem výpočetního výkonu a datových úložišť, a to jak on-premise (virtualizace), tak cílově zejména v prostředí cloudových služeb. Staví-li se výpočetní platformy v režimu Active - Active je nezbytné mít zajištěny minimálně 3 lokality, kdy 2 lokality slouží pro samotné výpočetní platformy a třetí lokalita pro umístění technologií dohledující zbylé lokality a rozhodující o jejich chování.

Služby eGovernment cloud nabídnou ekonomicky výhodné, standardizované a bezpečné služby sdílených platforem (PaaS – na úrovni operačních systémů a databází) a infrastruktury (IaaS – výpočetní výkon, datová úložiště, umístění v DC). Postupně tak bude docházet k využití služeb eGC pro všechny ISVS a provozní informační systémy (migrace do eGC). To umožní úřadům kompletně oddělit „komoditní“ komponenty architektury informačních systémů a zaměřit své síly na specifické komponenty, které souvisejí s jejich agendami a kompetencemi.

Bude pokračovat budování sítě státních center sdílených služeb a regionálních datových center propojených bezpečnou datovou komunikační infrastrukturou, která budou poskytovat sdílené ICT služby orgánům veřejné správy.

Svou úlohu budou i nadále plnit současně provozovaná a nově budovaná Národní datová centra, která splní kvalifikační předpoklady. Do takových NDC budou umísťovány především všechny centralizované ISVS pro služby státní správy v přenesené působnosti, poskytující své aplikační služby přes CMS.

Obě formy sdílených technologických služeb (NDC a eGC) se budou vzájemně doplňovat, přecházet jedna v druhou, NAP zdůrazňuje jejich kompatibilitu a provázanost.

Pro zajištění dostupnosti otevřených dat poskytovaných z ISVS za účelem jejich využívání v jiném ISVS bude vytvořeno společné úložiště v rámci NDC nebo eGC.

Jedním ze dvou hlavních kritérií pro využití služeb Státní část eGovernment Cloudu (také jako SeGC) nebo Komerční část eGovernment cloudu (také jako KeGC) je úroveň bezpečnostních dopadů daného IS. SeGC zajistí maximální úroveň bezpečnosti a je určen pro provoz služeb eGC bezpečnostní úrovně 4 (Kritická). KeGC je určen pro provoz služeb eGC bezpečnostních úrovní 1-3 (Nízká, Střední, Vysoká) a v maximální míře umožňuje využití tržních mechanismů pro zajištění optimálních cen. 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. Správce eGC zveřejní dynamický nákupní systém (také jako DNS) pro nákup eGC služeb vedených v jeho katalogu. Portál pro objednávání a správu služeb nebude spuštěn spolu s DNS, ale jeho spuštění se dá očekávat v roce 2020.

Komunikační architektura - vrstva komunikační infrastruktury veřejné správy

Komunikační vrstva je pro účely architektury veřejné správy ČR speciálně oddělená vrstva, obsahující společné prvky s technologickou vrstvou, avšak zaměřující se na jiný typ služeb s rozdílnou odpovědností. Komunikační vrstva tedy obsahuje pouze fyzická datová centra a komunikační cesty, prostřednictvím kterých se zprostředkovává vnější a vnitřní propojení. V rámci veřejné správy se na této vrstvě musí tedy vždy objevit datové centrum (fyzická budova), komunikační sítě (internet, KIVS) a komunikační uzly (CMS).

Na komunikační a síťové vrstvě jsou základní právní omezení definované především následujícími zákony:

schématické vyjádření komunikační vrstvy

Podstata změn v komunikační infrastruktuře

Rozvoj bezpečné a spolehlivé komunikační infrastruktury CMS/KIVS zabezpečí splnění rostoucích nároku OVS na bezpečnou publikaci aplikačních služeb státu a přístup k nim, jak pro klienty VS, tak i pro jednotlivé OVS.

Součástí vize sdílené infrastruktury je povinné publikování digitálních služeb státu výhradně přes CMS. Komunikační infrastruktura státu bude konsolidována do té míry, že pro všechny digitální služby lokálních OVS, opírající se o centrální sdílené služby eGovernmentu, bude z každého OVS zajištěno jediné bezpečné (zdvojené, jištěné) připojení KIVS na CMS a všechny ostatní vícenásobná síťová připojení budou eliminována, s výjimkou spojení pro zajištění bezpečnosti státu a krizového řízení.

Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury

Tato kapitola popisuje architekturu úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu. Jde o jiný přístup k popisu požadavků na využívání systémů a služeb eGovernmentu než v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivých úřadů, kde se požadavky popisují v celé šíři (v celé architektuře) sdílené služby, funkčního celky či tematické oblasti.

Skladba této kapitoly odpovídá doménám národní architektury

Pravidla architektury strategie a směřování úřadu

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

Pro architekturu strategie a směřování je podstatný především soulad se strategickými dokumenty, jejich principy a cíli. Mezi tyto dokumenty patří:

  1. Strategie Digitální Česko a z ní zejména Informační koncepce ČR
  2. Informační koncepce úřadu
  3. Národní architektonický plán
  4. Strategický rámec rozvoje veřejné správy 2014+
  5. Koncepce klientsky orientované veřejné správy 2021+
  6. Strategie rozvoje infrastruktury pro prostorové informace v České republice do roku 2020 (GeoInfoStrategie)

V modelu vlastní celkové architektury úřadu by praktickému používání při řízení úřadu měly sloužit zejména diagramy strategických cílů, architektonických principů, architektonických požadavků a omezujících podmínek, vytýčených směrů rozvoje a očekávaných výstupů. Tyto by měly sladěným způsobem kombinovat objekty převzaté z nadřazených strategií, viz výše a z vlastních strategií a koncepcí úřadu.

Pravidla výkonnostní architektury úřadu

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

Pro tuto doménu architektury nejsou v současnosti Národním architektonickým plánem stanovena žádná pravidla.

Pravidla byznys architektury výkonu veřejných služeb úřadu

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady.

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

Z hlediska řízení informatizace představuje byznys architektura zadání pro efektivní IT podporu výkonu veřejné správy. Proto je aktuální model cílového stavu byznys architektury úřadu povinným předpokladem a nedílnou součástí informační koncepce každého úřadu, orgánu veřejné správy.

Rozdělení procesů a funkcí veřejné správy

Pro rozhodování o variantách podpory potřeb výkonu veřejné správy úřadu je nutné všechny tyto byznys potřeby VS vyhodnocovat a třídit z několika úhlů pohledu.

Vedoucí útvaru informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model procesní, respektive funkční dekompozice úřadu a její diagram, tzv. Mapu byznys portfolia/architektury úřadu.

Tento model musí z podstaty komplexního řízení informatizace úřadu obsahovat identifikované všechny činnosti (schopnosti, procesy, funkce nebo služby, dále zastoupeny pouze pojmem funkce), které organizace vykonává, ať již jsou aktuálně manuální nebo elektronizované. Jako součást prostředků dlouhodobého řízení rozvoje IS úřadu musí být u všech těchto funkcí úřadu vyhodnoceno, do jaké míry uspokojivě a efektivně jsou podpořeny informačními technologiemi a do jaké míry tak má být cílově učiněno v časovém horizontu informační koncepce úřadu (5 let). Tato část Informační koncepce OVS pak musí obsahovat a zohledňovat zejména:

  • rozhodnutí o konsolidaci IT podpory byznys funkcí úřadu,
  • rozhodnutí o možnostech sdílené IT podpory byznys funkcí úřadu,
  • optimalizaci funkcí úřadu s podporou ICT - doplnění a rozvoj nedostatečné ICT podpory funkcí úřadu.

Přitom je nutné pohlížet na identifikované funkce úřadu a rozhodovat o nich přinejmenším z následujících čtyřech hledisek:

  1. Hledisko míry podpory externích služeb pro klienty veřejné správy.
  2. Hledisko míry (a potenciálu) podobnosti, jednotnosti a centralizace procesů.
  3. Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí.
  4. Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet.

Podle všech výše uvedených úhlů pohledu se liší potřeby funkcí úřadu na jejich aplikační podporu, proto je nutno mezi nimi rozlišovat a následně podle tohoto navrhovat řešení této aplikační podpory a volit způsob její realizace. Je důležité tyto vlastnosti funkcí úřadu znát a rozvoj aplikací úřadu podle nich prokazatelně řídit.

Detailní referenční modely byznys architektury, rozpracovávající zde uvedená pravidla, včetně jejich grafického vyjádření, stanovuje a publikuje odbor Hlavního architekta Ministerstva vnitra ČR, ve spolupráci s odborem eGovernmentu Ministerstva vnitra ČR a organizacemi zastupujícími jednotlivé úrovně státní správy a samosprávy.

Hledisko míry podpory externích služeb pro klienty veřejné správy

Pro usnadnění modelování byznys vrstvy architektury úřadu navrhuje Národní architektonický plán následující Referenční model byznys architektury úřadu. Ten dělí funkce úřadu do vrstev podle jejich „vzdálenosti“ od poskytování služeb pro externí klienty takto:

  • Hlavní procesy, funkce úřadu - úřad vykonává v interakci s externím klientem nebo pro výkon služby veřejné správy externímu klientovi
  • Podpůrné procesy, funkce úřadu - úřad vykonává jako předpoklad, přímou podporu nebo návaznost na individuální poskytování služeb externím klientům
  • Funkce a procesy správy sdílených zdrojů - úřad vykonává pro zajištění všech ostatních předpokladů a zdrojů dle své role a pozice ve veřejné správě, bez přímé souvislosti s podporou služeb svým individuálním externím klientům.
  • Řídící a rozvojové funkce - vykonává úřad, aby byl schopen plánovat, realizovat, monitorovat a vyhodnocovat kvalitu a výkonnost svých funkcí a jejich další rozvoj.
  • Provozní funkce - vykonává úřad jako správu základních zdrojů pro zajištění své udržitelné existence (provozu), bez ohledu na to, jaké jsou jeho hlavní, podpůrné a sdílené zdrojové funkce.

 Základní dělení funkcí, procesů a služeb úřadu

Referenční model byznys architektury úřadu dále dělí hlavní funkce pro výkon služeb zejména externím klientům (občané a zástupci organizací), ale i interním klientům (úřady a úředníci) na:

  • Obslužné funkce - představující interakci s klienty ve všech a v kterémkoli obslužném a komunikačním kanálu, angl. Front-Office (dále také FO), cílově co nejvíce společně a jednotně, napříč agendami.
  • Odborné funkce - představující specializaci na výkon a rozhodování v agendě či provozní funkci, angl. Middle-Office (dále také MO). Dále mohou být děleny na:
    • Generické odborné funkce veřejné správy (vidimace, konverze apod.)
    • Agendově specifické funkce veřejné správy
  • Funkce společného zázemí agend - představující funkce vykonávané typicky (ale ne výhradně) mimo interakci s klientem, z angl. Back-Office (dále také BO), společně a jednotně pro více (až pro všechny) agend úřadu.
  • Funkce správy spisů a případů - sloužící ke správě dokumentů a informací propojujících jednotlivé fáze (a funkční oblasti) vyřizování případů (řízení) klientů, interních i externích. Všechny povinnosti vedení řádných dokumentů a spisů ve spisové službě nesmí nahrazovat evidence případů, které slouží jen pro zvláštní záležitosti vymykající se zaběhlým a řádným postupům.
  • Funkce integrace a spolupráce mezi úřady při výkonu služeb klientům.

Další dělení (klasifikace) funkcí, procesů a služeb hlavní oblasti v kontextu ostatních funkčních oblastí

Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí

Identifikované funkce v modelu byznys architektury úřadu je nutné posuzovat z hlediska dostupnosti již sdílených byznys služeb nebo potenciálu na vymístění (outsourcing) k poskytovateli takové sdílené služby - uvnitř úřadu nebo samosprávné jednotky z vlastního rozhodnutí, jinde ze zákona nebo jiného předpisu.

Přitom rozlišujeme následující možnosti (úrovně) sdílení na:

  • Celostátně (celoplošně) sdílené služby. Ty se na této i na všech další úrovních dělí ještě na:
    • služby externí na podporu klientů veřejné správy (a případně OVM) - služby hlavních a podpůrných procesy
    • služby interní na podporu úřadů a úředníků - služby sdílených zdrojových, řídících a provozních procesů
  • Sdílené služby veřejnoprávních korporací (správců rozpočtových kapitol, krajských a místních (ORP) územních korporací)
  • Sdílené služby uvnitř úřadu - typicky služby pro obslužné funkce (FO), pro funkce zázemí agend (BO) a pro funkce správy dokumentů, spisů a případů
  • Individuální (dílčí, specifické, nesdílené) funkce - typicky odborné agendové funkce (MO)

Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet

Jako protipól funkcí předaných k vykonání jinému úřadu, organizaci, vyskytují se v orgánech veřejné správy funkce vykonávaném pro někoho jiného, tj. cizím jménem, na cizí účet, případně obojí. U všech identifikovaných funkcí úřadu je nutné - vždy posuzovat i tento aspekt, tj. u činností (procesů, funkcí, služeb) čím jménem a na čí účet jsou vykonávány. Typickým příkladem takto převzatých funkcí jsou:

  • Výkon služeb veřejné správy v přenesené působnosti
  • Výkon korporátních nebo státních středisek sdílených služeb

Ohlášení agend úřadu v RPP

Zákon 111/2009 Sb. o základních registrech zavedl jednoznačnou hierarchii agend a agendových informačních systémů spolu s vyznačením jak údajů, které jsou v rámci agendy vedeny, tak údajů, které je agenda oprávněna při své činnosti využívat ze základních registrů a dalších agend. V rámci tohoto textu jsou uvedeny důsledky plynoucí pro návrh architektury informačních systémů na všech vrstvách modelu.

Agendu definuje ústřední správní úřad zodpovědný za výkon agendy v právní terminologii. Při popisu údajů se tedy nevyužívá technologická terminologie, ale terminologie uvedená v příslušném právním předpise.

Úřad působící v agendě již nemůže ovlivnit ohlášení agendy, může případně požadovat na ústředním správním úřadě, který agendu ohlásil, její úpravu.

Logika ohlášení agend stanovuje, jaké údaje jsou v agendě vedeny o jednotlivých subjektech/objektech práva tak jak jsou definovány v legislativním textu. V rámci přijaté notace je kód agendy označován velkým písmenem A následovaným přiděleným číslem agendy. Jednotlivé subjekty/objekty, o kterých jsou v agendě vedeny údaje (kontexty) jsou dále postupně číslovány. Následuje číslo údaje v rámci kontextu.

Tedy například

  • Agenda A998 Agenda o podmínkách provozu vozidel na pozemních komunikacích
  • má uveden jako první kontext 998-1 Silniční vozidlo
  • který má jako první údaj 998-1-1 Údaje o vlastníkovi a provozovateli, není-li totožný s vlastníkem

Smyslem této registrace není detailní datový rozpad na položky ve smyslu informatickém, ale stanovení údaje, na který může být vztaženo oprávnění k využívání. Je tedy zřejmé, že údaj 998-1-1 se následně rozpadá na informatické položky (viz zákon č. 56/2001 Sb., o podmínkách provozu vozidel na pozemních komunikacích,§ 4 odst. 2) písmeno a).

Každá informatická položka tedy musí být uvedena jako další vrstva v notaci

998-1-1-1 Jméno vlastníka silničního vozidla.

Smyslem této notace, oznámení agend v Registru práv a povinností a následné technologické specifikace je jednoznačné oddělení právních a informačních zodpovědností. Při návrhu publikace prostřednictvím eGSB / ISSS tedy správce agendy definuje právní rozdělení kontextů a údajů a správce příslušného agendového informačního systému následné informační rozdělení těchto údajů. Toto rozdělení pak jednoznačně definuje položku v předávané datové větě v rámci propojeného datového fondu a řízení oprávnění přístupu k této položce.

Správce Agendového informačního systému tedy musí spolupracovat se správcem agendy na ohlášení agendy tak, aby bylo možné provést jednoznačnou dekompozici údaje v kontextu na jedno informační položky. Definice těchto informačních položek je následovně součástí definice datového rozhraní.

Zvolený princip zamezuje záměnám údajů podle jejich názvů (jméno vlastníka vozidla je určitě něco jiného než jméno vlastníka nemovitosti, ačkoli se obě položky jmenují jméno) a je nutné při návrhu všech datových rozhraní používat výše uvedenou číselnou hierarchickou notaci.

Správce agendy při ohlášení také určuje, jaké údaje ze základních registrů či jiných agend má oprávnění při své činnosti využívat a správce agendového informačního systému pak při návrhu datového rozhraní čerpá z definice datových položek jednotlivých ISVS, které údaje/data publikují do propojeného datového fondu veřejné správy.

Pokud je agenda vykonávána prostřednictvím více Agendových informačních systémů, pak správce agendy musí určit toho správce agendového informačního systému, který bude závazně určovat rozpad údaje na datové položky, a ostatní správci agendových informačních systémů musí tento rozpad respektovat.

Rozdělení obslužných a komunikačních kanálů veřejné správy

Obslužné a komunikační kanály úřadu veřejné správy vůči jeho externím klientům je pro účely jejich efektivního řízení a jejich IT podpory možné dělit z několika úhlů pohledu, a to podle:

  • Sdílení a subjektivity provozovatele obslužného kanálu na vlastní, centrální, v přenesené působnosti, u poskytovatelů služeb (třetích osob) a další
  • Podle míry zapojení klienta na
    • samoobslužné nebo
    • asistované (osobní, vně listinné či hlasové, ale vnitřně plně elektronické)
  • Podle vazby na místo a agendu na
    • univerzální - bez místní a věcné příslušnosti,
    • územní - s místní, ale bez věcné příslušnosti a
    • agendové - s věcnou příslušností (jedné nebo více agend téhož ústředního správního úřadu), ale bez místní příslušnosti (historicky a v oprávněných případech i místní příslušností).
  • Podle komunikačního média a prostředku podání/doručení na osobní - sepsání protokolu, listinné - poštou, kurýrem nebo na podatelně a na elektronické - Datovou schránkou, elektronicky podepsaným dokumentem do elektronické podatelny nebo do specifické aplikace úřadu (dle zvláštních zákonů) nebo postupem popsaným na úřední desce úřadu.

Cílem je, co nejvíce potřeb klientů obsloužit v prvním stupni obsluhy, tj. v univerzálních kontaktních místech (také jako "UKM") - klientských centrech, jako je samoobslužný Portál klienta (občana, podnikatele, zástupce organizace a cizince) v PVS a asistovaný CzechPOINT. Přitom pro nezbytné individuální služby budou nadále k dispozici specializovaná kontaktní místa úřadů.

Výchozím předpokladem při návrhu řešení by měla být maximální snaha, aby v rámci UKM nalezl klient maximum dostupných informací o svých kontaktech a řízeních s veřejnou správou.

V případě asistovaných kontaktních míst (univerzálních i v územních či agendových OVS) však zprostředkuje informace o všech informacích ze vztahu klienta a veřejné správy úředník, výhradně na základě explicitního zmocnění klientem. To je jediný případ, kdy smí úředník najednou vidět více než jednu agendu současně, přitom ale smí vidět pouze stavové informace z notifikací, tj. zda by měl klient agendě věnovat pozornost pro nějaké právo nebo povinnost. Na základě takového přehledu může dát klient pokyn, aby pro něj vyřízení jednotlivých agend po jedné úředník zprostředkoval.

Všechny úkony v obslužných kanálech musí být adekvátně evidovány a zaznamenány v transakčním logu příslušných IS a ve spisové službě úřadu.

Úřad veřejné správy je povinen v legislativě (může-li ji ovlivnit), v procesech úřadu a v jejich aplikační podpoře (v rozsahu dle platné legislativy) zajistit plnou rovnoprávnost všech obslužných kanálů a umožnit klientovi volbu mezi kanály.

Preference kanálu, efektivnějšího z pohledu úřadu, tedy typicky elektronického samoobslužného kanálu, je možná pouze zvýšením jeho atraktivity pro klienta, nikoli regulatorním opatřením (nařízením, sankcí).

Pro informatickou podporu v úřadu dále vyplývá, že na konci horizontu pravidel této IKČR, aktuálně v roce 2023, platí pro všechny agendy úřadu, že:

  • Všechna řešení (zákonná, byznys i informatická) musí být navržena tak, aby vnitřně byla plně elektronická a vně podporovala všechny obslužné kanály (konverze dokumentů).
  • Všechny kontaktní kanály, včetně specializovaných, budou podporovat navigaci ke službě (vyhledání služby) podle životních situací, vyplývajících z životních událostí klientů.

Budou navrženy takové úpravy právního prostředí, byznys procesů a funkcí a IT řešení, aby v dlouhodobém horizontu podporovaly rovnost a provázanost obslužných kanálů (Multichannel) - tj. řízení je možné v kterémkoli kanálu začít, v jiném sledovat jeho průběh a v jiném řízení dokončit.

Vliv byznys architektury úřadu na možnosti řešení její IT podpory

Z charakteru činností úřadu, viz dekompozice výše, vyplývá, jaké jsou možnosti pro sdílení a dosažení efektivní aplikační podpory těchto činností.

Tam, kde úřad ze zákona zůstává zodpovědný za určitou činnost (agendu, podpůrnou funkci) nemůže využít sdílených řešení a ani na úrovni centrálních prvků eGovernmentu nebudou taková sdílená řešení připravována, dokud se zákonné podmínky pro tuto oblast nezmění.

Příkladem je ERP nebo spisová služba. Zde jak procesy, tak jejich aplikační podporu musí mít každý úřad vlastní, zůstává věcným správcem těchto řešení. PPokud je tedy úřad věcným správcem nějakého řešení, zachovává si za něj zodpovědnost a měl by mít pravomoc o něm okamžitě rozhodovat – mělo by to být řešení v pravomoci tohoto úřadu.

V takovém případě, pro taková řešení jako je ERP nebo eSSL může OVS využít sdílené služby pouze na IT technologické a platformové úrovni, SW řešení mu musí poskytnuto maximálně tzv. multitenantní formou (více samostatných nájemníků) na společné technické infrastruktuře, aby individuální zodpovědnost OVS za činnost a údaje zůstala zachována.

Pravidla aplikační architektury IS VS úřadu

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady.

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

Z hlediska řízení informatizace představuje aplikační architektura těžiště řízení efektivní IT podpory výkonu veřejné správy. Rozvoj každého informačního systému úřadu se děje prostřednictvím rozvoje jeho aplikačních komponent, a to v kontextu všech ostatních aplikačních komponent úřadu a dostupných sdílených aplikačních služeb eGovernmentu. Proto je aktuální model cílového stavu aplikační architektury úřadu základem informační koncepce každého úřadu, orgánu veřejné správy.

Informační systémy veřejné správy slouží pro podporu výkonu agendy či agend veřejné správy. Musí tedy sloužit pro úředníka jako prostředek, který ho provádí jeho úřední činností a který mu pomáhá při jeho úřední práci, shromažďuje a doplňuje potřebné údaje, hlídá naplnění určitých povinností a nabízí řešení, ale třeba by měl být schopen i připravit návrh rozhodnutí v dané věci. Úředník by v ISVS, resp. v AIS měl dostat komplexní nástroj, který za něj vyřeší veškerou či alespoň značnou část administrativy a úředník tak bude mít čas na práci s klientem a na skutečné správní rozhodování tam, kde je takového rozhodování třeba. Stručně řečeno se mění evidenční úloha těchto IS na úlohu procesní.

Principy klasifikace aplikací dle referenčního modelu

Informační systémy veřejné správy (ISVS), tak jak je definují jejich agendové nebo jiné zákony, se tedy obvykle skládají z jedné nebo více aplikačních komponent. Aplikační komponenty ISVS a ostatních informačních systémů úřadu, lze pro účely jejich správy dělit například podle toho, jaké skupiny byznys funkcí úřadu podporují, podle míry sdílení aplikačních služeb a podle klientů těchto služeb, nebo podle vztahu IS k řetězci obsluhy klientů veřejné správy.

Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model dekompozice aplikačních komponent a aplikačních funkcí úřadu a její diagram, tzv. Mapu aplikačního portfolia/architektury úřadu.

Podporu pro rozhodování při řízení životního cyklu aplikačních komponent informačních systémů VS a současně vyjádření nejlepší praxe jejich inventarizace a třídění poskytuje tzv. Referenční model aplikační architektury, který základem aplikační mapy úřadu.

Rozdělení aplikačních komponent úřadu do vrstev

Dělení vychází z účelu aplikačních komponent shora počínaje úlohou uživatelského rozhraní a navigace až po platformy, zcela nezávislé na druzích uživatelů a poskytovaných služeb úřadu. V aplikační mapě se toto dělení uplatní jako vrstvy vertikální dimenze.

Rozdělení transakčních a informačních (analytických) komponent

Dále dělení aplikací vychází z byznys logiky podporovaných byznys funkcí, kde na jedné straně jsou to funkce (služby) pro vnější klienty, partnery a veřejnost, na druhé straně jsou funkce detailně podporující jednotlivé klíčové zdroje úřadu (znalosti, zaměstnance, majetek a zásoby (a jejich dodavatele), případně svěřené registry).

Pokud zákon pro nějakou agendu definuje i způsob IT podpory evidence údajů, a zmocňuje tak k implementaci ISVS, není tím stanoveno, že by tento systém nemohl některé své komponenty využívat společně s ostatními agendami (a agendovými systémy) téhož úřadu. Na druhou stranu dosud není možné, nestanovuje-li to explicitně zákon, sdílet v ISVS aplikační komponenty vlastněné jiným úřadem (ani příslušnou korporací, tj. rezortem, krajem nebo ORP).

Z toho vyplývá aktuálně proveditelný požadavek na optimalizaci procesů a aplikačního portfolia úřadu tak, že pro průřezové procesy agend (podobné, příbuzné či jednotné byznys funkce a procesy) využije jednotných nebo dokonce centrálních sdílených komponent aplikačního portfolia úřadu (např. pro obsluhu klientů na přepážkách, portálovou samoobsluhu, řízení kontrol na místě, příjem a párování plateb apod., transkripce jmen osob ze zemí používajících jiné písmo, než latinka) v rámci svého úřadu, případně zákonem nebo jiným předpisem mu zpřístupněných centrálních sdílených aplikačních služeb na vyšší úrovni VS (korporace, centrální eGovernment).

Pokud se takto sdílí v úřadu několik komponent napříč agendami, používají tyto pro externí označování klienta nikoli AIFO, ale nejlépe nějaké společné veřejné klientské číslo občana a organizace v rámci systému kmenových dat úřadu. AIFO, jako neveřejný identifikátor, bude využíváno pouze při externí výměně údajů o klientovi v agendě prostřednictvím Back-End integrace přes referenční rozhraní.

Průřezové, IT a bezpečnostní služby

Rozsah a obsah aplikací pro obslužné, odborné a funkce zázemí agend se liší podle segmentů veřejné správy. Odlišnosti ostatních kategorií jsou minimální, převažují obdobné a jednotné aplikační funkce.

Obsah aplikací pro průřezové, IT a bezpečnostní služby je v referenčním modelu představen ve formě typových, logických aplikačních komponent. Tyrkysové komponenty představují výsledky zobecnění dosavadní praxe autorů, zatímco oranžové komponenty byly převzaty z referenčního modelu EU (EIRA).

Povinností ředitele informatiky úřadu (technického správce) je zohlednit vzájemnou podobnost aplikací podle jejich kategorie při rozhodování o konsolidaci aplikací nebo o návrhu aplikační podpory v kategoriích, kde je tato nedostatečná nebo chybí.

Referenční model aplikační architektury s plným detailem třídění a s odlišným obsahem klíčových transakčních komponent pro jednotlivé odlišující se segmenty veřejné správy (např. zdravotnictví, pojistné agendy, dotační agendy, správa síťové infrastruktury apod.) bude vydán v následujících verzích NAP.

 Průřezové, IT a bezpečnostní služby

Pravidla pro uživatelská rozhraní a přístup k informačním systémům

Uživatelská rozhraní ISVS i provozních systémů musí být především ergonomicky optimální pro nejlepší podporu odpovídajících uživatelských rolí a jejich výkonu externích i interních funkcí veřejné správy.

  • Úřad musí mít všechny svoje formuláře primárně v autentizované zóně portálu a umožnit předvyplnění údajů z PPDF s využitím zaručené identity klienta
  • Agendové a místní portály se budou rozšiřovat z informačních na transakční
  • Transakční obsah portálu (formuláře nebo uživatelská rozhraní portálových aplikací) musí být integrován (federalizován) s PVS - Portál občana
  • Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace. Tato identifikace je nyní zajištěna pouze prostřednictvím národního identitního schématu

Kromě výjimečně zdůvodnitelných případů, například modelovacích nebo GIS nástrojů, nebo při nedostupnosti dostatečně propustného internetového připojení, nesmí být žádná byznys logika obsažena v uživatelském rozhraní, nýbrž musí být z aplikačních serverů dostupná jednotně pro všechny použité typy UI (lokální klient, webový klient, mobilní klient). Důvodem je usnadnění jednotné údržby byznys logiky při neustálých změnách (parametrizaci) funkcí IS.

NAP předpokládá postupné sjednocování vzhledu a chování portálových aplikací ústředních správních úřadů pro dosažení jednotného uživatelského zážitku klienta. To platí zejména poté, co budou elementární služby úřadů dostupné „proklikem“ z portálu občana. Pro tento účel je zveřejněný grafický manuál MVČR

Cílem je pro menší ústřední úřady a územní samosprávy umožnit místo budování lokálních portálů využívat SaaS služeb Portálu občana v PVS, a to v prvním kroku pro svěřené služby státní správy v přenesené působnosti, později i pro služby samosprávy a hospodářskou činnost obce. Proto tento účel bude v PVS možnost služby graficky lokalizovat, avšak při zachování jednotné navigace a nástrojů obsluhy.

Pravidla pro obslužné agendové aplikace (FO)

Cílově musí být obslužné aplikační funkce jednotné a centralizované v úřadu, resortu (nebo korporaci) a státu tak, aby klientům veřejné správy umožňovaly dobrý a jednotný „zážitek“ a efektivní obsluhu, a to úměrně výše uvedenému členění obslužných kanálů veřejné správy a požadavků na jejich podporu.

To znamená, že aplikace obslužných kanálů stejného typu, například externí portál, musí být hierarchicky federativně integrované nebo zcela centrální. Aplikace různého typu, například uživatelské rozhraní pro fyzickou přepážku a pro portál musí být vzájemně integrovány tak, že užívají společnou aplikační logiku komunikace s klienty, která není vestavěna ani do portálu, ani do přepážkového SW, ale právě do společného aplikačního SW obslužných kanálů, také označovaného CRM, což ve veřejné správě znamená Citizen Relationship Management.

CRM společně s komunikačními technologiemi (web, mail, telefon, chat, SMS, DS, a další) zajistí jednotnou vícekanálovou obsluhu (multichannel, omnichannel).

Podstatnou část agendové byznys logiky čerpají a prezentují obslužné kanály z agendově specifických (MiddleOffice) systémů a ze systémů agendového zázemí (Back-Office).

Pravidla pro odborné (specifické) agendové aplikace (MO)

Ve všech případech, kdy má být veřejná služba v agendě zajišťována v přenesené působnosti nebo ve vlastní působnosti plošně v pobočkové síti (územní dekoncentráty - FŘ, OSSZ, Okresní soudy) je povinností ústředního správního úřadu ohlašujícího tuto agendu vystupovat jako věcný správce jejího ISVS a zajistit pro takovou agendu centrální agendový informační systém, pokrývající odborné agendové funkce (MO), případně funkce agendového zázemí (BO).

Tento systém musí být dostupný prostřednictvím síťové infrastruktury státu ve všech obslužných místech veřejné správy, agendových i univerzálních. Musí být uzpůsoben k integraci na lokální i na celostátní aplikační komponenty pro obsluhu klientů (FO), pro lokální společné funkce zázemí agend (platby, vedení spisu apod.) (BO), zejména pak musí být integrovatelný na lokální spisovou službu, lokální saldokontní účetnictví klientů a lokální EkIS úřadu.

Uživatelské rozhraní těchto centrálních AIS musí být zařaditelné a volatelné z jednotné transakční navigace v centrálním portálu úředníků (intranetu veřejné správy) i (dočasně) v lokálním intranetu úřadu.

Pro aplikační architekturu úřadu potom platí, že úřad musí pro logicky centralizovaný AIS buď:

  1. využívat tuto centrálně sdílenou aplikační komponentu, tj. poskytnout uživatelům úřadu uživatelský přístup k této komponentě prostřednictvím JIP/KAAS a integrovat tuto komponentu na Back-Office s ostatními nezbytně místními komponentami úřadu, jako je spisová služba úřadu nebo systém řízení obsluhy klientů.
  2. b) využívat vlastní standardizovaný agendový systém úřadu pro tuto agendu (nebo multi-agendový), integrovaný na centrální sdílenou komponentu, sloužící jako její „tlustý klient“, avšak s plnou odpovědností úřadu za jeho legislativní aktualizaci.

Pro obě varianty platí závazně jak pro věcného správce centrálního systému, tak pro lokální úřad architektonický požadavek, že ani interní zaměstnanci, ani externí klient nesmějí v rámci poskytnutí jedné služby této agendy v žádném případě zadávat žádné údaje dvakrát.

Výše uvedená centrální odborná agendová aplikace musí být správcem (ohlašovatelem agendy) poskytnuta včetně samoobslužného zákaznického portálu občana/podnikatele, zajišťujícího splnění principu Once Only. Současně tato centrální aplikace publikuje v agendě evidované agendové údaje do PPDF a publikuje veřejné údaje agendy do VDF jako otevřená data.

Pravidla pro aplikace agendového zázemí (BO)

Pokud úřad je činný ve více agendách, které všechny vedou na obdobné funkce zázemí agend (BO), například vedení spisu, příjem poplatku, výplata dávky, apod., bude pro tyto funkce užívat sdílené řešení (spisovou službu, saldokontní účetnictví, …) a měl by postupně sjednotit legislativu a procesy v těchto oblastech funkcí.

Klíčovou komponentou této oblasti z pohledu klientů i úřadu je komponenta pro vedení kmene klientů a jejich pohledávkových/závazkových účtů (saldokonto). Tyto komponenty by měly být v každém úřadu centrální a jednotné, napříč agendami.

Sdílená řešení pro agendové zázemí mohou být sdílena nejen pouze v úřadu, cílově ale také v resortu/korporaci nebo celostátně, jakmile to bude legislativně a technicky možné a dostupné.

Systém elektronické spisové služby je z hlediska procesů úřadu natolik zásadní a natolik specifický, že ač je dle definice nástrojem agendového zázemí (BO), byla pro tyto systémy a pravidla pro ně vytvořena zvláštní kategorie, viz dále.

Pravidla pro aplikace spisové služby, správy případů a workflow

Odlišné procesní nároky pro správu klientských případů a spisů, jednoznačně vztažených ke klientům (data vlastněná klienty a propůjčená do správy úřadům) a případů a spisů interní správy OVS (bez vazeb na klienta). Je doporučeno uvědomit si tyto odlišnosti, jim přizpůsobit vazby na AISy na jedné straně a vazby na provozní systémy (ERP, HR, nákup apod.) na druhé straně.

Z pohledu zákona o archivnictví a spisové službě existuje tzv. kategorie „určených původců“, která má povinnost vykonávat spisovou službu v elektronické podobě v elektronických systémech spisové služby. I přes rozdíly uvedené v předchozím odstavci o vazbách tedy každý určený původce musí pro evidenci všech dokumentů zavést, provozovat a využívat systém elektronické spisové služby, sdílený všemi agendami a útvary úřadu, pokud se z pohledu dobrého hospodáře nevyplatí užívat pro některou agendu samostatnou evidenci podle zákona o archivnictví. V takovém případě musí být obě (všechny) evidence integrovány v souladu s Národním standardem. Obdobně a přiměřeně by měli k výše uvedené problematice s ohledem na architektonické principy přistupovat i úřady, které nejsou určenými původci.

Pokud úřad pro své agendy vede více dokumentů v téže věci, je povinen evidovat tyto dokumenty v tzv. spisu. Proto by pak měl jako společnou a sdílenou komponentu zvážit právě funkci správy spisů. Pokud navíc postupně stále více agend je ve svém vyřizování elektronizováno a automatizováno jako tzv. elektronického oběhu dokumentů (Workflow), měl by úřad disponovat jedinou sdílenou komponentou pro řízení tohoto workflow nad elektronickými dokumenty. Elektronický nástroj pro workflow by měl podporovat oba základní typy předávání práce:

  • transakční workflow – kdy mezi pracovníky přechází odkaz na rozpracovanou transakci v agendovém nebo provozním IS, společně s odkazy na odpovídající dokumenty nebo spisy, které jsou přílohou.
  • dokumentové workflow – kdy mezi pracovníky přechází jenom odkaz na dokument nebo spis ve spisové službě, případně, kdy je dokument nebo spis prostřednictvím workflow předáván

Uživatelský klientem pro workflow by měl(o) být současně (optimálně):

  • uživatelské rozhraní aplikace AIS, provozního systému nebo spisové služby, to podle typu workflow, viz výše
  • společné rozhraní přistupující do „workflow-inboxu“ v Portálu úředníka, kde jsou odkazy na veškerá probíhající workflow
  • rozhraní pro mailovou schránku úředníka umožňující práci s workflow obou typů"

Pravidla pro kategorii znalostních systémů

Znalostní systémy v úřadu musí být konsolidovány tak, aby všechny informace a znalosti úřadu, s výjimkou informací o individuálním výkonu moci v agendě a klasifikovaných informací, byly dostupné pro vzdělávání a podporu výkonu služeb pro všechny zaměstnance úřadu, se společným vyhledáváním informací v intranetu úřadu / Portálu úředníka..

Pro informační systémy poskytující informace o platném, historickém i připravovaném právu platí, že v úřadech mohou být provozovány jenom takové systémy a pouze pro takové funkce, které nejsou podporovány centrálním systémem eSbírka/eLegislativa.

Pravidla pro identity management (IDM)

Každý úřad je povinen zvážit ve své architektuře pořízení řešení pro centrální správu identit a oprávnění uživatelů (také zvané IDM (Identity Management), nebo IAM (Identity & Access Management)) úřadu a její integraci s personálním systémem úřadu na jedné straně a s centrálním jednotným identitním prostorem úředníků VS ČR na druhé straně (aktuálně řešení JIP/KAAS).

  • Povinnost napojení identifikace a autentizace klientů na kvalifikovaný systém, který je v současnosti pouze NIA
  • Povinnost napojení identifikace, autentizace a autorizace úředníků na JIP/KAAS
  • Doporučení realizovat centrální správu identit úřadu (IDM), napojenou u úředníků na HR (HCM)

Pravidla pro integrační platformy

Častým problémem je, že u správců ISVS jsou tyto informační systémy budované jako autonomní bloky, které nejsou řádně a správně propojeny a integrovány s dalšími informačními systémy a komponentami v úřadu. Je nutno na to myslet již při sestavování prvotní architektury a důsledně zajistit tyto integrace, a to formou otevřených, a především popsaných a nahraditelných rozhraní, nikoliv jako blackboxy (peer-to-peer, P2P) na dohodě dodavatelů.

Každý informační systém veřejné správy musí být integrován s:

  • Elektronickým systémem spisové služby – pro vedení spisové služby, případně se samostatnou evidencí dokumentů pro odbornou správu dokumentů a pro úkony spojené s dokumenty, kdy výše uvedené systémy jsou nástroji buď pro výkon spisové služby, případně pro evidenci dokumentů. Tyto systémy musí pak být vždy v souladu s Národním standardem dle zákona č. 499/2004 Sb
  • Provozními systémy typu IDM a monitoringu
  • Auditovacími a logovacími systémy - pro zajištění logování nakládání s údaji evidovanými v ISVS včetně ale nikoliv pouze osobních údajů
  • Ekonomickým informačním systémem pro zajištění finančních operací a jejich evidence - u systémů pro agendy, kde se buď vyplácí, nebo přijímají finanční prostředky.

Preferovaným způsobem integrace aplikací je využití standardní integrační platformy (též Enterprise Application Integration, dále též jen „EAI“, nebo synonymum Enterprise Service Bus, dále též jen ESB), která nahradí P2P integraci úřadu a poskytuje funkce pro zejména asynchronní integraci (nečekající na potvrzení zápisu do databáze či odpověď), obsloužení front, logování apod.

Každý úřad bude využívat vlastní nebo sdílenou EAI propojenou na centrální eGSB / ISSS.

Tato pravidla v souladu s NAP předpokládají vícestupňovou hierarchickou strukturu integračních platforem.

Pro zapojení úřadů do sdílení v rámci propojeného datového fondu je vybudována centrální integrační platforma eGSB / ISSS. Na ni se úřady přednostně napojují prostřednictvím korporátních integračních platforem resortů (krajů, ORP) nebo prostřednictvím vlastních EAI, pokud takovou mají.

Korporátní EAI slouží primárně pro potřeby interní integrace v rámci kapitoly nebo veřejné korporace, jako externí integrace pro úřad ministerstva nebo územního celku a jako sdílená služba pro podřízené organizace korporace, pro které není výhodné vybudovat EAI vlastní.

Místní integrační platformy budují ty úřady, pro které je investice do platformy jejich vnitřní i vnější aplikační integrace vzhledem k četnosti a komplexnosti rozhraní nebo vzhledem k objemu přenášených zpráv ekonomicky a provozně výhodná.

Pravidla pro systémy zveřejňující a využívající otevřená data

Jako otevřená data jsou v kompletní podobě zveřejňovány údaje evidované v ISVS, pro které platí:

  • povinnost zveřejnění v podobě otevřených dat je výslovně stanovena právním předpisem; nebo
  • jde o ISVS, jehož obsah je zcela či zčásti veřejný a zároveň se nejedná o předchozí případ. V tomto případě je nutné provést posouzení, zda zveřejnění údajů v této formě nebude mít za následek nepřiměřený zásah do práva na ochranu osobních údajů, popř. se jím významně zvýší možnost narušení bezpečnosti ČR.; nebo
  • jde o údaje, které by bylo možné poskytnout na základě žádosti podle předpisů upravujících svobodný přístup k informacím (srov. § 5 odst. 7 zákona o svobodném přístupu k informacím) a zároveň se nejedná o předchozí dva případy. V takovém případě zveřejní údaje ve formě otevřených dat jen v rozsahu, v jakém by bylo možné je poskytnout, pokud by byly předmětem žádosti podle zákonů upravujících svobodný přístup informacím, přičemž je nutné provést též posouzení, zda by zveřejnění v této formě znamenalo možnost narušení bezpečnosti ČR.

Zveřejňovat údaje z ISVS jako otevřená data znamená povinnost poskytovat je všem odborníkům na zpracování dat (programátorům, datovým analytikům a novinářům, vědcům, studentům, apod.) a OVS v podobě, která aktivně podporuje jejich strojové zpracování a replikaci, a zejména tomuto účelu neklade žádné (technické, právní ani ekonomické) překážky.

V případě, že jsou z ISVS zveřejňovány údaje v podobě otevřených dat, je též naplněn případný legislativní požadavek poskytnutí veřejného dálkového přístupu k těmto údajům.

Sdílení veřejných údajů evidovaných v ISVS mezi orgány veřejné správy musí být zajištěno prostřednictvím otevřených dat ve VDF. OVS, jehož evidence údajů v jím spravovaném ISVS je primární evidencí, je musí zveřejňovat jako otevřená data. OVS, který tyto údaje využívá v jím spravovaném ISVS, je musí získávat jako otevřená data, pokud jsou jako otevřená data zveřejňovány.

Tytéž údaje je možné ve veřejné správě zveřejňovat jako otevřená data pouze jednou. V případě, že údaje vedené v ISVS jsou předávány do jiného ISVS za účelem shromažďování údajů od různých OVS a následného zveřejnění, nejsou tyto předávané údaje zveřejnovány jako otevřená data z prvního ISVS, ale pouze z druhého ISVS. Zveřejňování zajistí správce druhého ISVS. V případě centrálních aplikačních služeb jsou vedené údaje poskytovány v podobě otevřených dat správcem centrální aplikační služby a samosprávní úřad v takovém případě již své příslušné údaje jako otevřená data nezveřejňuje.

Pravidla pro využití SaaS služeb eGC

SaaS služby eGC mohou být teoreticky využity pro nahrazení kterékoliv služby na aplikační vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou SaaS. Na SaaS služby eGC budou kladeny stejné architektonické požadavky jako ISVS provozované on-premise a bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů daného ISVS.

Praktické využití SaaS služeb eGC je očekáváno zejména a nejdříve v kategoriích podpůrných systémů, spisové služby a agendového zázemí, v případě obcí i v kategorii agendových aplikací pro samosprávnou působnost.

Pravidla datové architektury IS VS

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady.

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

Datová architektura IS VS je formálně součástí jedné vrstvy společně s aplikační architekturou. Zde jsou popsány rozděleně z důvodu důrazu na práci a pravidla pro systém a práci a pravidla pro data/údaje, se kterými pracují.

Tato pravidla aktuálně nepředepisují žádné povinně standardizované individuální prvky datové architektury veřejné správy s výjimkou těch, které jsou postupně publikovány jako součást referenčních a agendových údajů veřejné správy ČR.

Zásadním požadavkem informační koncepce je adopce (uplatnění) společného přístupu k datové architektuře pro všechny orgány veřejné správy. Správce každého informačního systému musí vědět:

  • Jaké údaje (data) se vyskytují v informačních systémech veřejné správy, které jsou využívány pro podporu agendy
  • Odkud tato data pochází. Tedy zda jde o údaje vytvářené v rámci činnosti agendy, získané ze základních registrů, agendových zdrojů, využívané z jiných agend, z otevřeného datové fondu a podobně
  • Komu údaje poskytuje (ať už na základě oprávnění o využívání údajů jiné agendy nebo na žádost)
  • Jak zabezpečuje ochranu údajů ať už při přístupu k údajům, tak vedené záznamů (logů) o těchto přístupech a ochrana těchto logů.

Požadavky na změnu přístupu k datové architektuře jsou tedy platné pro všechny ISVS na území státu.

Každý správce ISVS, který obsahuje nějaký datový fond, je povinen zajistit (správce ISVS musí):

  1. Referenčnost - ztotožnit všechny subjekty/objekty vedené v základních registrech (fyzické osoby – ROB, právnické osoby – ROS, adresní body a další územní prvky - RUIAN) a začít přijímat notifikace o změnách údajů o těchto subjektech/objektech jak ze základních registrů, tak od dalších agendových zdrojů.
  2. Jednoznačnost - rozdělit si datový fond na části
    1. Referenční údaje – musí být v souladu se základními registry
    2. Agendové údaje – pochází od editorů základních registrů (např. Evidence Obyvatel) nebo jiných agendových informačních systémů (např. registr řidičů) v rámci agendy jsou pouze využívány
    3. Vlastní údaje agendy – údaje vytvářené v rámci agendy (mohou být dále poskytovány jiným agendám jako agendové)
  3. Bezpečnost a důvěrnost – musí být zajištěna jak z hlediska ochrany osobních údajů, tak i z hlediska zabezpečení proti ztrátě či neoprávněnému pozměnění údajů

Tento způsob řízení datové architektury musí úřad uplatňovat nejenom pro jednotlivé ISVS, ale souhrnně za celý OVS, jeho úřad a korporaci.

Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model základní (konceptuální) dekompozice údajů úřadu a její diagram, tzv. Mapu datové architektury úřadu.

Detailní referenční modely datové architektury, rozpracovávající zde uvedená pravidla, včetně jejich grafického vyjádření tj. Map, stanovuje a publikuje OHA MV, ve spolupráci s OeG a organizacemi zastupujícími jednotlivé úrovně státní správy a samosprávy.

Rozdělení / klasifikace dat ve veřejné správě

IKČR ukládá úřadům udržovat aktuální klasifikace základních informačních (datových) objektů architektury úřadu. Tyto identifikované objekty musí být klasifikovány do následujících kategorií a je nutné s nimi v aplikační architektuře nakládat způsobem, odpovídajícím jejich klasifikaci.

Všechny údaje spravované v IS úřadu, tvoří tzv. datový fond úřadu. Základní existenciální (statické, kartotéční) údaje o subjektech (klientech, dodavatelích, zaměstnancích, apod.) a o objektech veřejné správy (evidovaná vozidla, kulturní památky, hospodářská zvířata, vl. majetek úřadu, apod.) představují tzv. datový kmen úřadu, nebo jeho kmenová data. Naproti tomu údaje o řízeních (operacích, úkonech) se subjekty nebo nad objekty veřejné správy se nazývají transakční data úřadu. Kmenová a transakční data jsou dvě nejdůležitější součásti datového fondu úřadu, další kategorie dat jsou představeny níže.

Zásadním požadavkem informační koncepce z hlediska klasifikace dat ve veřejné správě je zavedení pojmu agendový údaj. V současné době je již zaveden zákoně o základních registrech (§ 2) pojem referenční údaj. Agendový údaj má obdobnou datovou kvalitu při jeho využívání, ale za jeho kvalitu a záruku ručí jeho poskytovatel, což je ve většině případů ohlašovatel agendy. Jde například o údaje týkající se řidičů, vozidel, vzdělání fyzických osob, kvalifikace osob fyzických či právnických k provádění činnosti dle zákona (lékař, vzdělávací instituce, akreditační středisko apod.).

Použitím výše uvedených principů můžeme údaje vedené v datovém fondu informačního systému veřejné správy (agendě), a souhrnně v datovém fondu úřadu, rozdělit z několika hledisek. Prvotním hlediskem je klasifikace datových objektů z hlediska zodpovědnosti za jejich validitu, viz výše bod jednoznačnost.

Dále mohou být jednotlivé datové objekty datového fondu ISVS a úřadu klasifikovány dle jejich typu (z hlediska stability, dynamiky či způsobu zacházení):

  • Kmenová data
  • Transakční data individuálních řízení v agendách
  • Dokumenty
  • Prostorová data
  • Analytická (agregovaná, anonymizovaná nebo jinak transformovaná) data
  • Signálová data (datový proud v reálném čase)
  • Metadata prostorových dat, analytických dat, dokumentů a multimediálních objektů
  • Provozní a bezpečnostní auditní data (logy)
  • Parametrizační, customizační data, řídící číselníky (jazyky, měny, směrovací čísla, typy daní, kategorie sazeb, druhy paliv, kategorie vozidel, NACE, atd.)
  • Data programového kódu (zdrojový kód v databázi)

Další zásadní klasifikace datových objektů nejen v datovém kmeni, ale i v dalších výše uvedených datových objektech je podle obsažení osobních údajů:

  • Obsahující osobní údaje
  • Obsahující zvláštní kategorie osobních údajů (dříve jako citlivé osobní údaje)
  • Neobsahující osobní údaje.

Základním nástrojem pro správu datových objektů o subjektech a objektech práva obsažených v datovém kmeni agendy je Registr práv a povinností. Při ohlášení agendy je nutné uvést výčet údajů vedených v agendě dle zákona 111/2009 Sb. o základních registrech § 51 odst. 5) písm. h). Tyto podklady slouží pro oznamovatele jiných agendy, kteří dle písmene j) tohoto ustanovení registrují požadavek na využívání těchto údajů.

V rámci RPP jsou udržovány informace o takto poskytovaných a využívaných údajích z legislativního hlediska, tj. tak jak jsou uvedeny v odpovídajícím právním předpisu. Z hlediska technického využití je pak správce ISVS, který údaje poskytuje prostřednictvím eGSB / ISSS publikovat odpovídající technický předpis jak XML šablonu v rámci WSDL předpisu využívání publikovaných služeb eGSB / ISSS.

Z technického hlediska je tedy závazný předpis, jakým jsou data publikovány pro využívání na rozhraní Informačního systému základních registrů a eGSB/ISSS. Tím je sjednoceno referenční rozhraní veřejné správy a zajištěna jednoznačná technologická prezentace právních pojmů z hlediska přenášených údajů.

Současně se nepředpokládá možnost výměny údajů mezi informačními systémy veřejné správy mimo referenční rozhraní.

Pravidla pro číselníková data

Každý, kdo poskytuje údaje v propojeném datovém fondu, má povinnost zveřejňovat s tím spojené číselníky v podobě otevřených dat ve SVDF. Jedná se o číselníky, které vytváří v rámci své činnosti, nikoli o číselníky využívané při vedení údajů.

Pokud tedy například v rámci vyplňování údajů je používán Číselník zemí (CZEM), pak tento číselník správce nepublikuje, pouze uvádí, že využívá daný číselník publikovaný Českým statistickým úřadem.

Pro každý číselník tedy musí být být známo:

  • Správce číselníku (OVS)
  • Místo publikace číselníku a jeho technický formát
  • Způsob aktualizace číselníku

Číselníky evidované dle výše uvedených principů jsou závazné při výměně údajů mezi agendami.

Pravidla pro referenční a agendová kmenová data

V rámci svého lokálního informačního systému mohou, respektive musí být úřadem pro výkon agendy využívány referenční a agendové údaje. Tyto údaje mohou být využívány on-line při jejich potřebě dotazem na referenční rozhraní (ISZR a eGSB/ISSS), nebo může být v uložena jejich kopie pro subjekty a objekty vedené v rámci agendy.

Agendový údaj:

  • Vzniká v dané agendě její činností (definováno příslušným zákonem) a správce agendy je zodpovědný za jeho správnost – agendový zdroj – současný stav
  • Je využíván v jiných agendách – současný stav (agenda má při své činnosti oprávnění využívat údaje jin agendy)
  • Jeho použití z agendového zdroje zajišťuje, že je konáno „úředně správně“ obdobně jako u referenčního údaje – nutné legislativně doplnit

Povinnosti z hlediska agendových údajů – záměr:

  • Správce (agendy) registruje u Registru práv a povinností údaj jako agendový
  • Správce publikuje údaj v rámci vybraného kontextu s vazbou na subjekt/objekt prostřednictvím eGSB / ISSS
  • Správce publikuje změny agendového údaje
  • Správce přijímá reklamace na stav agendového údaje
  • Agenda využívající agendový údaj registruje tento požadavek v Registru práv a povinností
  • Agenda využívá údaj prostřednictvím eGSB / ISSS
  • Pokud agenda ukládá ve svém datovém fondu tento údaj, pak ho udržuje v souladu se skutečností odběrem změn
  • Pokud je při činnosti agendy zjištěna pochybnost o správnosti údaje, pak oznámí správci údaje

Z hlediska efektivity výkonu veřejné správy je zásadní, jak efektivně jsou referenční a agendové údaje z referenčního rozhraní využívány. Současně je nutné architektonicky zabezpečit, aby výkon veřejné správy byl maximálně odolný vůči výpadkům centrálních komponent.

  1. Pokud nejsou tyto údaje ve větším množství v rámci agendy využívány, pak je nejefektivnější a nejbezpečnější jejich využívání na základě on-line dotazů v okamžiku potřeby. V datech agendy pak nejsou údaje trvale uloženy, ale je uložen pouze jejich tvar získaný v okamžiku dotazu a v souvislosti s daným účelem.
  2. Pokud jsou tyto údaje využívány agendou ve větším množství, nebo v případě nedostupnosti centrálních systémů hrozí nebezpečí z prodlení, pak je efektivní údržba lokální kopie referenčních a agendových údajů o subjektech a objektech agendy pro potřeby jejího výkonu. V tomto případě je nezbytně nutná systematická údržba těchto údajů tak, aby byly v souladu s údaji vedenými v základních registrech a agendových zdrojů. Za tímto účelem je nutné využívat procesu notifikace změn a aktualizace údajů o subjektech a objektech, pro které byla tato změna notifikována.

Princip notifikace je zásadně typu pull a bez předávání údajů při notifikaci. Tedy agenda využívající údaje požádá o seznam subjektů či objektů, pro které za uplynulé období (typicky jeden den) došlo ke změně údaje. Daný seznam pak využije k aktivnímu dotazu na zdroj údajů, kde získává údaje dle svých oprávnění. Je tak tedy zajištěno, že během notifikací nemohou být předány údaje, na které agenda nemá oprávnění. Současně při dotazech na fyzickou či právnickou osobu je vytvořen záznam v základních registrech a dotčený subjekt práva získá informaci o tom, že agenda aktualizovala údaje o něm ve svém datovém kmeni.

V případě, že OVS využívá více než jeden vlastní (lokální) agendový informační systém a využívá referenčních a agendových kmenových údajů, musí být implementováno lokální řešení správy kmenových dat, které po iniciálním ztotožnění udržuje přijímáním notifikací z PPDF kmenová data úřadu aktuální a nezatěžuje propojený datový fond průběžnými on-line dotazy. Osobní údaje získané tímto způsobem jsou uloženy mimo jiné agendové informační systémy a jednotlivými systémy jsou využívány pouze v případě potřeby. Tím je zajištěno oddělení a zabezpečení osobních údajů s nezpochybnitelným auditem přístupu k osobním údajům.

Pravidla pro otevřená data (OD)

Pro OVS platí povinnost publikace údajů VS v podobě otevřených dat dle následujících pravidel:

  • Při publikaci veřejných informací určených k širokému použití veřejnosti je nutné dodržovat pravidla stanovené pro otevřená data (OD).
  • Při publikaci veřejných informací určených ke sdílení mezi veřejnoprávními subjekty navzájem i pro sdílení veřejných údajů mezi veřejnoprávní a soukromoprávní sférou, je nutné dodržovat pravidla stanovená pro veřejný datový fond (VDF).

Otevřená data musí především naplnit legislativní požadavky ve smyslu zákona 106/1999 Sb. o svobodném přístupu k informacím se zohledněním zákona o ochraně osobních údajů a nařízením GDPR. Navíc musí způsob jejich zveřejnění naplnit následující podmínky, jejichž splnění musí zajistit OVS, který otevřená data zveřejňuje:

  • Otevřená data musí být katalogizována v NKOD v podobě jednotlivých datových sad.
  • Datová sada musí být tvořena logicky souvisejícími údaji, logicky organizovanými do záznamů se stejnou datovou strukturou.
  • Z datové sady nesmí být záměrně odstraňovány vybrané údaje nebo celé záznamy, které zveřejněny být mohou.
  • Datová sada musí být poskytována v podobě jednoho či více datových souborů ke stažení z Webu, které nazýváme distribuce datové sady.
  • Distribuce datové sady se smí vzájemně lišit pouze v datovém formátu, nikoliv ve svém obsahu. Každá distribuce musí obsahovat kompletní množinu záznamů tvořících datovou sadu.
  • Alespoň jedna z distribucí musí být poskytována v otevřeném a strojově čitelném formátu ve smyslu definice otevřených dat podle § 3 odst. 11 zákona č.106/1999 Sb a musí:
    • Být opatřena podmínkami užití, které neomezují žádné (legální) užití jejího obsahu, především nesmí zamezovat komerčnímu užití či vyžadovat registraci uživatelů.
    • Musí být poskytována bez zbytečných překážek. Není možné podmiňovat přístup k distribuci registrací, uzavřením smlouvy, získáním aplikačního klíče, přihlašováním apod. Přístup k distribuci může být subjektu omezen pouze v případě a po dobu, kdy jeho chování při získávání distribuované datové sady vykazuje známky kybernetického útoku.
    • Musí být publikována dle otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím, zveřejněných na Portálu otevřených dat (POD).
  • Každá distribuce v otevřeném a strojově čitelném formátu musí být opatřena logickým datovým schématem vyjádřeným ve vhodném a běžně používaném jazyku pro popis datových schémat, pokud takový jazyk pro daný formát existuje. Logické datové schéma popisuje reprezentaci datové struktury záznamů tvořících datovou sadu v příslušném formátu. Distribuce musí být vůči svému logickému datovému schématu validní.
  • Datová sada musí být detailně zdokumentována především za účelem maximálního možného zamezení dezinterpretace jejího obsahu. V případě, že z datové sady byly před jejím zveřejněním odstraněny některé údaje nebo celé záznamy z důvodu nemožnosti jejich zveřejnění, musí být tato skutečnost uvedena v dokumentaci a zdůvodněna. V případě, kdy je datová sada anonymizovanou podobou, souhrnem nebo statistikou zdrojových údajů, musí být způsob anonymizace nebo vytvoření souhrnu či statistiky zdokumentován.
  • Obsah distribucí datové sady musí být aktualizován dle periodicity, kterou OVM deklarovalo při katalogizaci datové sady v NKOD.
  • Jsou povoleny pouze zpětně kompatibilní změny v datové struktuře záznamů tvořících datovou sadu. Změny v datové struktuře musí být implementovány do logických datových schémat distribucí.
  • V případě změn, které nejsou zpětně kompatibilní, musí být založena nová datová sada a distribuce původní již nesmí být aktualizována.
  • U datových sad, jejichž distribuce již nejsou aktualizované, musí být zajištěna dostupnost jejich distribucí po nejdelší možnou dobu, minimálně však po dobu 3 let.

Pravidla pro data veřejného datového fondu

Datová sada zveřejněná jako otevřená data ve VDF musí k výše uvedeným podmínkám pro otevřená data splňovat ještě následující doplňující podmínky, které zajistí použitelnost a důvěru v data ve VDF:

  • Prvky definované logickými datovými schématy distribucí datové sady, jejichž sémantika je významná, musí být propojeny na pojmy sémantického slovníku pojmů za účelem harmonizace sémantiky datových sad dle k tomu určené OFN zveřejněné na POD.
  • V případě duplicit u publikovaných datových sad, nebo doplňování údajů různými publikujícími ke stejné publikované entitě je nutné doplnit vazby na již publikované údaje ve VDF. Povinnost doplnění vazeb spadá na toho publikujícího, který publikuje doplňující údaje.
  • U každé datové sady publikované do VDF musí být uvedena informace o notifikačním mechanismu o změnách dle příslušné OFN uvedené na POD.
  • OVS, který datovou sadu zveřejňuje, musí zajistit a garantovat dostupnost distribucí datové sady v otevřeném a strojově čitelném formátu pro všechny OVS, které je využívají při výkonu svých agend.
  • Správce ISVS, ze kterého je datová sada získána, zodpovídá za věcnou správnost obsahu datové sady. To znamená, že zodpovídá za:
    • správnost jednotlivých záznamů tvořících datovou sadu a jednotlivých údajů, které ji tvoří,
    • aktuálnost publikovaných datových sad,
    • pravidelnou aktualizaci datových sad,
    • předávání oznámení o aktualizacích notifikačnímu HUBu.

Pravidla pro analytická data

Každý úřad, který ze zákona udržuje primární individuální evidenční data o subjektech či objektech práva ve svých agendových systémech, může pro potřebu řízení agend i pro jinou veřejnou potřebu vytvářet z těchto údajů vytvářet anonymizované statistické údaje.

Anonymizované statistické údaje jsou tříditelné podle všech parametrů (klíčů), které nejsou údaji specificky chráněnými a nezakládají možnost profilace.

Statistická data mohou být vytvářena s přiměřenou periodou podle povahy evidovaných údajů v primární evidenci (den, týden, měsíc, čtvrtletí, rok). Jako statistická data budou zveřejňována po provedení nezbytných úprav (např. agregace) data, která jinak nemohou být zveřejněna z důvodu ochrany osobních údajů. Statistická data jsou vytvářena tak, aby v nejvyšší možné míře zachovávala informační hodnotu původních dat.

Takto připravované statistické údaje musí být zveřejňovány jako otevřená data a mohou být zveřejňovány na portálu úřadu také jako zrakově čitelné údaje.

Úřady, jejichž specifické agendové zákony nepředpokládají vytváření statistických údajů a jejich využívání k řízení a optimalizaci výkonu agendy a k zveřejnění jako otevřená data, musí usilovat o odpovídající legislativní úpravu.

Statistická data téhož (nebo velmi blízkého obsahu) je možné ve veřejné správě vytvářet pouze jedenkrát, proto je tím pověřen správce agendového informačního systému primární evidence příslušného subjektu nebo objektu práva a příslušného údaje.

Statistické údaje, které mohou orgány nyní ze zákona pověřené sběrem takových statistických údajů získat z jejich primárních evidencí, nesmějí být duplicitně získávány sběrem od subjektů.

Pravidla pro prostorová data

Každý agendový informační systém spravující prostorová data, která mohou být sdílena v rámci propojeného datového fondu veřejné správy, musí:

  • Být obsahově popsán do úrovně datových prvků v informačním systému o informačních systémech veřejné správy do úrovně datových prvků. Datový prvek odpovídá třídě prostorových dat v geografických informačních systémech.
  • Publikovat služby sdílení prostorových dat
  • Datové prvky prostorových dat, které jsou ve vztahu příbuznosti, podobnosti nebo identicity k prvkům RÚIAN, musí obsahovat identifikátor prvku RUIAN (např. budovy digitální technické mapy, adresní místa agendou dotčených nemovitostí, aj.)

Hierarchie povinnosti využívání údajů dle jejich závaznosti

  1. Propojený datový fond
    1. Referenční údaje ze základních registrů (využívá se [služeb ISZR)
    2.    Údaje publikované agendami a jejich AISy (využívá se eGSB / ISSS)
  2. Veřejný datový fond
    1. Veřejné rejstříky a seznamy publikované způsobem umožňujícím dálkový přístup)
    2. Otevřená data z ISVS publikovaná a se zapsanými metadaty v NKOD)

Pravidla technologické / platformové architektury IS VS

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady.

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

Klasifikace IT technologické architektury

IT technologická architektury (také jako "platformová architektura") je vrstva zabývající se technologiemi, které svými funkcionalitami a službami podporují aplikace, systémy a obecně prvky z aplikační architektury. Oblasti platformové architektury se dají rozdělit na:

  1. Výpočetní výkon,
  2. datová úložiště,
  3. koncová zařízení (Firewall, Switch, obecně aktivní prvky).

Pravidla návrhu a využití On-Premise architektury

Veškeré IT technologie, s výjimkou koncových vstupně výstupních zařízení interních uživatelů musí být umístěna a provozována v pro tento účel vyhrazených prostorách, dále také zvaných serverovny nebo datová centra, vyhovujících stanoveným standardům.

Standardy pro serverovny a datová centra bude vydávat MV ve spolupráci s bezpečnostními organizacemi veřejné správy a odbornými IT organizacemi.

Podle IKČR je nepřípustný výskyt tzv. šedého IT, tj. aplikací a platformového SW a HW, pořízených, nebo umístěných nebo užívaných v odborných útvarech OVS bez dodržení centrálního dohledu (governance) útvaru IT úřadu.

Pokud je pro některé malé úřady nehospodárné nebo technicky či personálně nemožné dodržet tato pravidla, je jedinou možností svěřit svá IT řešení do péče jiných organizací veřejné správy, u nichž pravidla budou dodržena, a využívat IT podporu svých procesů veřejné správy jako jejich službu.

Pravidla využití PaaS a IaaS služeb eGC

PaaS a IaaS služby eGC mohou být využity pro nahrazení kterékoliv služby na technologické vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou PaaS nebo IaaS. Na PaaS a IaaS služby eGC budou kladeny minimálně stejné architektonické požadavky jako na platformy provozované on-premise. Pro služby eGC a on-premise budou stejné i bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů ISVS tyto platformy využívající.

Praktické využití PaaS a IaaS služeb je očekáváno zejména ve formě skupin služeb odpovídajících provozní platformě určitého ISVS nebo provozního informačního systému, případně jeho jasně definované části (např. web front-end), a to buď na úrovni plně spravované technologické platformy včetně správy OS (PaaS), nebo na úrovni virtualizovaných výpočetních a diskových zdrojů (IaaS), jejichž správu bude úřad provádět vlastními silami nebo s využitím služeb třetí strany. Z pohledu eGC je pro dosažení vyšší úrovně efektivity preferováno použití služeb PaaS.

Dalším příkladem využití PaaS služeb je využití plně spravovaných platforem databázových nebo aplikačních serverů včetně zajištění SW licencí.

Pravidla pro režim Active - Active jednotlivých výpočetních uzlů

Staví-li se výpočetní platformy v režimu Active - Active je nezbytné mít zajištěny minimálně 3 lokality, kdy 2 lokality slouží pro samotné výpočetní platformy a třetí lokalita pro umístění technologií dohledující zbylé lokality a rozhodující o jejich chování.

Pravidla fyzické a komunikační infrastruktury IS VS

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady.

Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.

KIVS/CMS je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů státní správy a samosprávy ke službám (aplikacím), které poskytují informační systémy jiných subjektů státní správy a samosprávy s definovanou bezpečností a SLA parametry, tj. přístup ke službám eGovernmentu. KIVS/CMS tak můžeme nazvat privátní sítí pro výkon veřejné správy na území státu. KIVS/CMS jako privátní síť veřejné správy využívá dedikovaných resp. pronajatých síťových prostředků pro bezpečné propojení úředníků orgánů veřejné správy (OVS) pracujících v agendách veřejné správy s jejich vzdálenými agendovými informačními systémy, pro bezpečné síťové propojení agendových systémů navzájem a pro bezpečný přístup jednotlivých OVS do Internetu.

Připojení k CMS je možné realizovat prostřednictvím:

  • Neveřejného KIVS operátora (Krajské sítě, Metropolitní sítě, ITS Ministerstva vnitra a další)
  • Veřejného KIVS operátora (Soutěž KIVS operátora přes centrálního zadavatele MVČR)
  • IPsec VPN
  • SSL VPN

Pro OVS jsou přípustné pouze první 2 varianty - Neveřejný a veřejný KIVS operátor, komunikace mezi jednotlivými OVS je tak vedena výhradně prostřednictvím KIVS/CMS, tzn. jednotlivé OVS mají povinnost přistupovat k informačním systémům veřejné správy (ISVS) pouze prostřednictvím KIVS/CMS.

S výjimkou tzv. provozních informačních systémů, které jsou uvedeny v § 1 odst. 4 písm. a) až d) zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), je § 6g odst. 3 tohoto zákona správcům ISVS uložena povinnost poskytovat služby informačních systémů veřejné správy prostřednictvím CMS. Organům veřejné správy je prostřednictvím § 6g odst. 4 ZoISVS uložena povinnost využívat sítě elektronických komunikací CMS.¨

Protože skrze CMS se publikují služby tzv. referenčního rozhraní, definovaného v § 2 písm. j) ZoISVS, má vztah k CMS i povinnost uložená v § 5 odst. písm. d) ZoISVS, tj. povinnost správců ISVS zajistit, aby vazby jimi spravovaného ISVS na ISVS jiného správce byly uskutečňovány prostřednictvím CMS.

S ohledem na výše popsané vlastnosti CMS, jakož i s ohledem na výše popsané právní aspekty, lze také dodat, že využívání, popř. nevyužívání CMS je relevantním faktorem pro posuzování plnění souvisejících právních povinností, a to zejména povinností v oblasti kybernetické bezpečnosti nebo ochrany osobních údajů, jakož i povinnosti řádného a hospodárného nakládání s veřejnými finančními prostředky a povinnosti k předcházení vzniku škod.

Specifická pravidla pro architekturu úřadů

Pravidla pro architekturu dle velikosti a možností úřadů

Pro obce 1. a 2. typu má vize architektury veřejné správy následující podobu:

Architekturu IT úřadu obce 1. a 2. typu (do určité velikosti, viz níže) tvoří pouze koncová zařízení pro uživatele, síťovou infrastrukturu jim jako sdílenou poskytuje kraj, aplikační služby pro státní správu v přenesené působnosti poskytnou ohlašovatelé agend a aplikační služby pro samosprávní působnost poskytne vyšší stupeň územní samosprávy (ORP, kraj) jako sdílenou službu.

Pro oblast samosprávy tak vychází koncepce z následujících principů:

  1. NAP je závazný pro všechny subjekty samosprávy, které mají více než 10 zařízení.
  2. Informační systémy pro činnosti a agendy v přenesené působnosti přebírají v plném rozsahu od centrálních úřadů. Samosprávné činnosti si každý územněsprávní celek zajišťuje sám.
  3. Subjekty s méně než 10 zařízeními si pořizují pouze uživatelský HW a SW, tj. tato koncová zařízení, SW produkty pro výkon veřejné správy jim jako službu zajišťují subjekty, v jejichž správním obvodě leží.

Pravidla pro architekturu dle pozice úřadu ve struktuře VS ČR a vztahu ke sdíleným službám

Úřady, zodpovědné ze zákona jako věcní správci sdílených prvků služeb eGovernmentu, považují tyto jim svěřené prvky za nedílnou součást architektury svého úřadu. Vedle celkové architektury svých úřadů ještě samostatně modelují modely architektury těchto svěřených sdílených prvků, a to i na úrovni podrobnosti tzv. architektury řešení. Tyto úřady pro tyto prvky modelují také tzv. rozšířené modely, tj. modely zahrnující také prvky typové (logické) prvky architektury na straně typových (typických) odběratelů jejich sdílených služeb.

Úřady, užívající služeb sdílených prvků eGovernmentu, nemodelují tyto informační systémy v žádném případě jako aktivní prvky (aplikační a technologické komponenty a rozhraní) - nemají je v rozsahu své zodpovědnosti, nýbrž výhradně jako služby (byznys, aplikační nebo technologické a infrastrukturní - podle potřeby vyjádření) a rozhraní vlastních komponent na tyto systémy.

Úřady zodpovědné za implementaci a provoz centrální registrů a AIS pro služby v přenesené působnosti, modelují architekturu svých úřadů přirozeně i včetně těchto systémů. Současně jsou povinny vytvářet a udržovat také tzv. rozšířené modely, tj. modely zahrnující také prvky typové (logické) prvky architektury na straně typových (typických) odběratelů jejich sdílených služeb, ukazující veškerý potřebný kontext (například integraci centrálního AIS na lokální eSSL a EkIS).

Úřady užívající tyto centrální AIS pro služby v přenesené působnosti, nemodelují ve svých architekturách úřadu tyto jako aktivní prvky (nemají je ve své zodpovědnosti), nýbrž jako služby těchto systémů a rozhraní vlastních komponent na tyto systémy.

Pohledy celkové skladby architektury veřejné správy

Pohled úředníka

Pohled klienta - právnické osoby

Pohled klienta - fyzické osoby

Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR

Tato kapitola nahlíží na sdílené služby, funkční celky a tematické oblasti veřejné správy ČR tzv. „shora“ a přináší jak definice klíčových pojmů a prvků architektury VS, tak přehled centrálních sdílených služeb eGovernmentu, dostupných pro použití v lokálních architekturách úřadů. Základní pilíře a budoucí směry rozvoje eGovernmentu lze postihnout dále popsanými klíčovými sdílenými službami, funkčními celky či tematickými oblastmi. Jejich prostřednictvím jsou poskytovány centrální sdílené služby eGovernmentu i sdílené agendové služby, které jsou souhrnně zahrnuty do architektonické vize eGovernmentu. V této části popisované sdílené služby, funkční celky a tematické oblasti je povinné zohlednit v informační koncepci úřadu a v architektuře úřadu na základě zákona 365/2000 Sb. a Informační koncepce ČR dle Způsobů využívání sdílených služeb, funkčních celků a tematických oblastí úřady.

Tematické oblasti

Sdílené služby a funkční celky

Agendový model veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady.

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

Identifikace klientů veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Fyzická identifikace

Fyzickou identifikací je myšlena situace, kdy klient veřejné správy je osobně přítomen v místě, kde je mu služba poskytována nebo je po něm vyžadována součinnost. K fyzickému prokázání totožnosti se používají identifikační doklady, které musí obsahovat:

  • Aktuální a platné údaje o jeho držiteli
  • Fotografii držitele

Jako identifikační doklad se používá občanský průkaz a cestovní pas. Identifikačním dokladem není řidičský průkaz, protože nesplňuje potřebné parametry při jeho vydávání, ačkoliv obsahuje například fotografii držitele.

Aby mohla fyzická identifikace fungovat jak při aktuální potřebě (člověk se v daný čas dostaví na místo), tak i při historické potřebě (ověření platnosti identifikačního dokladu z historické smlouvy), budou služby eGovernmentu poskytované přes Referenční rozhraní rozšířeny o službu, která na jakékoliv historické číslo a typ identifikačního dokladu vrátí, zda byl v požadované době platný a aktuální údaje držitele tohoto historického identifikačního dokladu.

Fyzická identifikace pro osoby bez identifikačního dokladu

Ačkoliv předcházející text předpokládá identifikaci pouze prostřednictvím identifikačních dokladů, existují situace, kdy osoba nemá možnost se tímto identifikačním dokladem prokázat. Typicky jde o děti pod 15 let či cizince. Základním předpokladem, aby mohla proběhnout identifikace i těchto osob je jejich evidence v informačním systému veřejné správy, napojený na propojený datový fond a následné vydávání potvrzení či úřední/veřejnou listinu, které může zastat roli identifikačního dokladu. Pro osoby do 15 let to může být rodný list vedeny v jednom z editorských agendových informačních systémů nebo povolení o přechodném pobytu pro cizince.

Některé z těchto listin - například povolení k trvalému pobytu, azylový štítek či vízový štítek jsou již dnes vedeny v základním registru obyvatel, avšak jejich použití pro identifikaci není plně dořešeno.

Elektronická identifikace

Elektronickou identifikací je myšlena situace, kdy klient veřejné správy není přítomen v místě poskytování služby. Identifikace tedy probíhá vzdáleně, bez fyzického kontaktu.

Pro jednoznačnou elektronickou identifikaci a autentizaci klientů veřejné správy byl vytvořen technický a právní rámec, který umožňuje všem správcům informačních systémů veřejné správy tuto činnost vykonávat v souladu s Informační koncepcí ČR a bez nutnosti vytváření vlastních nákladných řešení a zvyšování administrativní zátěže.

Zákon č. 250/2017 Sb., o elektronické identifikaci, zavádí v §2 povinnost provádět prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace. Tento paragraf nabývá účinnosti 1. července 2020. Po tomto datu nebude možné pokračovat v praxi vydávání přístupových údajů klientů veřejné správy mimo systémy kvalifikovaného systému elektronické identifikace, pokud jiný zákon tuto cestu neumožňuje.

Podporu celého procesu elektronické identifikace prostřednictvím kvalifikovaného systému elektronické identifikace je vytvořena platforma Národní identitní autority (také jako NIA), která vykonává činnosti Národního bodu dle § 20 a následujících a národního uzlu eIDAS pro spolupráci s oznámenými systémy elektronické identifikace dle nařízení Evropské parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES.

Mandáty, práva a role v elektronické identifikaci pro klienty veřejné správy

Kvalifikovaný poskytovatel elektronických služeb bude nadále zodpovědný za řízení oprávnění (autorizaci) fyzické osoby, která prokázala takto svoji totožnost. Nadále tedy musí provádět správu oprávnění na základě údajů o osobě, které získá z Propojeného datového fondu a vlastních údajů vedených v agendě.

Pohledy na elektronickou identifikaci klientů VS

Propojený datový fond

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Propojený datový fond (také jako PPDF) je tematická oblast tvořená především Informačním systémem základních registrů a eGON Service Bus / Informačním systémem sdílené služby, jejichž služby jsou publikovány prostřednictvím Centrálního místa služeb. PPDF a jeho systémy/služby jsou fyzickou reprezentací referenčního rozhraní veřejné správy. Základní funkcí PPDF je realizace zásad „Once-only“ a „Obíhají data, nikoli lidé“ do běžné praxe veřejné správy ČR. PPDF je primárním zdrojem platných a právně závazných údajů pro subjekty práva i pro všechny OVM a SPUÚ při výkonu jejich působnosti. Tak povede PPDF k náhradě manuálních interakcí mezi úřady pomocí automatizované výměny údajů mezi jednotlivými Agendovými informačními systémy.

Agendový informační systém je termín ze zákona 111/2009 Sb., a označuje takové Informační systémy veřejné správy, které slouží k výkonu agendy. Texty k PPDF tedy obsahují jak pojmy Informační systém veřejné správy, tak Agendový informační systém. Obsahuje i pojem Soukromoprávní systém pro využívání údajů, který je roven Agendovému informačnímu systému, jen má jiného správce než klasický orgán veřejné moci.

Propojení mezi Agendovými informačními systémy a základními registry zajišťuje Informační systém základních registrů, propojení mezi agendovými informačními systémy navzájem zajišťuje eGON Service Bus / Informační systém sdílené služby. Veškeré vazby činěné v rámci PPDF jsou vždy propojeny se základními registry pomocí referenčních vazeb na referenční údaje o subjektech práva (fyzických osobách, právnických osobách a OVM) a referenční údaje o objektech práva (územní prvky a práva a povinnosti). Pro referenční vazby údajů o fyzických osobách se využívá Agendový identifikátor Fyzické osoby (AIFO), pro referenční vazby právnických osob Identifikační číslo osoby (IČO), pro referenční vazby územních prvků jejich příslušné identifikátory přidělené RUIAN. Kromě rozvoje a podpory navázaných principů správy datového kmene a pseudonymizace, je hlavním cílem PPDF rozvoj o další agendové zdroje neveřejných údajů z klíčových oblastí výkonu veřejné správy (doprava, zdravotnictví, sociální služby…) jasně definovaným garantem a editorem. Mezi členskými státy EU se klade větší důraz na interoperabilitu, PPDF bude připraven poskytovat i služby pro přeshraniční výměnu dat. V reáliích roku 2020 je ke službám PPDF připojeno cca 3 500 informačních systémů z celkového počtu cca 7 000. Základním cílem PPDF je kromě připojení všech informačních systémů veřejné správy také zajištění, aby připojení pro relevantní ISVS nebylo jen čtenářského typu (čerpání údajů), ale i publikátorského typu (poskytují své údaje). Teprve až budou všechny relevantní informační systémy veřejné správy služby PPDF čerpat a poskytovat, může se hovořit o propojeném datovém fondu.

Základními službami PPDF pro oprávněné čtenáře PPDF jsou:

  • Ztotožnění (přidělení identifikátoru) subjektu/objektu práva vedeném v AIS a tím i podpora pseudonymizace
  • Výdej údajů o subjektu/objektu práva dle požadovaného kontextu v rozsahu oprávnění vedených v RPP pro příslušnou agendu podporovanou AIS
  • Notifikace o změnách referenčních a agendových údajů pro údaje v AIS vedené
  • Podpora reklamace chybných údajů

Pohled na propojený datový fond

Veřejný datový fond

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Veřejný datový fond (také jako "VDF") je princip vytváření a dotváření obrazu propojeného datového fondu dle principů otevřených dat za účelem podpory sdílení údajů OVS při výkonu veřejné správy i mimo jejich rozsah práv a povinností zachycených v RPP a mimo PPDF.

VDF zastřešuje a reprezentuje skutečné fyzické datové zdroje otevřených dat roztroušené ve webovém prostoru VS. Vlastní zastřešení a vymezení je realizováno nástroji určenými pro správu metadat otevřených dat, což nejen konkretizuje samotný pojem VDF, ale nabízí i prostředky pro další kategorizace v rámci celého datového fondu ČR.

Význam a role VDF se projevuje ve dvou oblastech VS.

První se týká interního režimu VS, kde je hlavním prostředkem sdílení veřejných údajů mezi veřejnoprávními subjekty navzájem a také rozšiřuje vzájemné sdílení informací o ty údaje, které v PPDF vůbec nejsou. Význam VDF v této oblasti nejlépe vystihuje znění dílčího cíle 5.10 z Informační koncepce ČR.

“Veřejný datový fond tvořený publikovanými veřejnými údaji veřejné správy je základní metodou pro sdílení veřejných informací mezi veřejnoprávními subjekty navzájem i pro sdílení veřejných údajů mezi veřejnoprávní a soukromoprávní sférou v ČR. Veřejný datový fond se od pouhé publikace automatizovaně čitelných Open Dat posune též k publikaci právně závazných, platných a pravidelně aktualizovaných datových sad s jasně definovanou zodpovědností OVS za takové sady.”

Druhou důležitou oblastí, ve které VDF sehrává významnou roli, je oblast směřování ČR k otevřenému vládnutí a postupnému zpřístupňování informací VS veřejnosti. VDF je tvořen publikovanými informacemi VS v podobě otevřených dat a tak se stává součástí všech veřejně přístupných otevřených dat v ČR.

Datové zdroje VS ČR

Datový zdroj je způsob přístupu k datům. Data VS ČR jsou přístupná prostřednictvím datových zdrojů v následujících kategoriích:

PPDF - propojený datový fond je popsán zde.

OD - otevřená data - je tvořen všemi publikovanými daty VS ve formátu otevřených dat, která musí splňovat požadavky na otevřená data odpovídající definici uvedené v § 3 odst. 11 zákona č.106/1999 Sb. Součástí otevřených dat jsou také všechna otevřená data samospráv, otevřená data využívaná v konceptu SMART Cities a data publikovaná v rámci VDF.

Pro data ve formátu otevřených dat platí, že jsou:

  • Volně přístupná na webu jako datové soubory ke stažení ve strojově čitelném a otevřeném formátu - CSV, XML, JSON, RDF a v dalších formátech s otevřenou specifikací.
  • Opatřená podmínkami užití neomezujícími jejich užití.
  • Evidovaná v Národním katalogu otevřených dat (NKOD) jako datové sady opatřené přímými odkazy na datové soubory, které je tvoří.
  • Opatřená úplnou, volně dostupnou a otevřenou dokumentací.
  • Opatřená kontaktem na kurátora pro zpětnou vazbu (chyby, žádost o rozšíření, apod.)
  • Jsou publikovány dle otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím.

VDF - veřejný datový fond - je podmnožinou otevřených dat. Je tvořen datovými zdroji, které veřejně zpřístupňují data dostupná v PPDF a datovými zdroji, která veřejně zpřístupňují data, jež PPDF vůbec neobsahuje, ve formátu otevřených dat. Jedná se např. o data nutná pro správnou interpretaci dat z PPDF (např. číselníky) nebo o data obsažená v agendách, které nemají ze zákona povinnost publikovat svoje údaje jiným agendám, a tedy ani nejsou součástí PPDF. VDF tedy slouží ke zpřístupnění dat PPDF jednotlivým OVS v těch případech, kdy příslušná OVS nemají možnost tato data sdílet prostřednictvím PPDF (nemají přidělena práva v RPP), nebo takových dat, které vůbec nejsou součástí PPDF a v obou případech taková data ke své práci potřebují. Veškerá publikovaná data ve VDF musí být ve formátu otevřených dat a musí splňovat požadavky kladené na otevřená data dle zákona č.106/1999 Sb. a dále pak požadavkům právních předpisů na zpracování a ochranu osobních údajů. Nad rámec těchto pravidel musí poskytovatel u svých dat publikovaných ve VDF garantovat jejich aktuálnost, dostupnost a správnost tak, aby je ostatní OVS mohly využívat při své práci.

Součástí VDF jsou rovněž data s řízeným přístupem. Jedná se o datové sady, které naplňují všechny stanovené podmínky pro otevřená data s výjimkou požadavku, aby jejich poskytovatel nijak neomezoval jejich následné využití. Příkladem takové praxe je podmínění poskytnutí dat předchozí registrací, aby mohl poskytovatel sledovat, jak je s daty nakládáno. Jedná se o takové případy, kdy úplnému otevření dat brání objektivní důvody vyplývající například z legislativy nebo věcně technického charakteru dané datové sady.

Ačkoli data s řízeným přístupem nejsou otevřená data, hledí se na ně v kontextu VDF jako na otevřená data a musí tedy splňovat všechny požadované podmínky kladené na otevřená data včetně katalogizace v NKOD, s výjimkou upravených podmínek pro jejich užití. Pro úpravu platí, že v podmínkách užití dat musí být uvedena a zdůvodněna všechna stanovená omezení, musí být stanoveny podmínky pro získání souhlasu k užití a musí být uveden kontakt na publikující organizaci pro zažádání o přístup k publikovaným datovým sadám.

Udělování fyzického přístupu k takovým datovým sadám a správu a registraci povolených uživatelů plně spadá na publikující organizace.

Přístupy k datům VS

OVM (případně SPUÚ) při výkonu veřejné správy používají údaje vedené v systému základních registrů a údaje vedené o jednotlivých entitách v jiných agendových systémech, pokud mají dle zákona povinnost publikovat svoje údaje jiným agendám. Tyto údaje tvoří PPDF a jednotlivá OVM k nim mají přístup prostřednictvím referenčního rozhraní veřejné správy na základě svých práv a povinností zachycených v RPP.

OVM může pro svou práci vyžadovat i údaje nad rámec oprávnění definovaných v RPP, případně může potřebovat údaje, které PPDF neobsahuje. V takových případech může přistupovat k veřejně dostupným údajům prostřednictvím VDF a k získání potřebných dat využije vhodnou publikovanou sadu otevřených dat prostřednictvím NKOD.

Pokud taková sada neexistuje, požádá ohlašovatele odpovídající agendy o doplnění údajů v podobě otevřených dat do VDF.

Veřejnost má otevřený přístup ke všem otevřeným datům a tedy také k údajům ve VDF prostřednictvím NKOD a Portálu otevřených dat (POD).

Základní charakteristiky VDF

VDF obsahuje datové zdroje, které slouží jako doplňkový zdroj dat pro OVM v takových případech, kdy OVM nemají k použití takových dat přímo z PPDF přidělena práva v RPP, nebo taková data PPDF vůbec neobsahuje.

V konečném důsledku se tímto způsobem rozšiřuje sdílení údajů VS nad rámec zajišťovaný referenčním rozhraním v propojeném datovém fondu (viz. cíl 5.10 informační koncepce). Významným a hodnotným efektem VDF je také jeho zpřístupnění veřejnosti ve formátu otevřených dat v rámci možností a podmínek vymezených v zákonech u jednotlivých agend.

Data ve VDF musí být poskytovány v podobě otevřených dat a musí tak splňovat všechny požadavky kladené na otevřená data dle zákona č.106/1999 Sb. VDF je základním prostředkem a metodou pro sdílení veřejných informací mezi veřejnoprávními subjekty navzájem a pro sdílení veřejných údajů mezi veřejnoprávní a soukromoprávní sférou.

Pokud OVS využívá data z VDF, považuje je za správná a nemusí ověřovat jejich správnost.

Poskytovatel dat do VDF tudíž musí:

  • garantovat správnost publikovaných údajů,
  • garantovat kvalitu publikovaných údajů,
  • garantovat aktuálnost publikovaných údajů,
  • garantovat pravidelnost aktualizace publikovaných údajů,
  • zajišťovat automatickou notifikaci všech změn zaregistrovaným zájemcům s využitím funkcionality POD.

Nástroje VDF

VDF vytvořený na základě principů otevřených dat vytváří virtuální distribuovaný datový prostor, ve kterém OVS sdílí s veřejností i mezi sebou navzájem veřejné údaje evidované v jimi spravovaných ISVS. Správa takového virtuálního prostředí a udržení kvality, konzistence a aktuálnosti publikovaných dat je založena na správě metadat publikovaných datových sad, popisu datových zdrojů a sémantickém mapování prvků struktur datových sad na sémantický slovník pojmů VS s pomocí k tomu určených nástrojů.

Správa dat VDF bude v základu probíhat stejným způsobem jako jsou již spravována otevřená data VS s několika dalšími rozšířeními. Základem bude katalog dat NKOD, který bude upraven a doplněn tak, aby mohl rozlišovat jednotlivé kategorie dat, umožňoval registrace uživatelů a zajišťoval notifikace změn.

Přehled všech nástrojů využitých při práci s daty VDF a otevřenými daty uvádí následující obrázek.

POD zastřešuje nástroje a funkční oblasti NKOD nutné pro katalogizaci a správu všech kategorií dat v PPDF.

Základní zajišťované funkce:

  • katalogizace otevřených dat (VDF a OD),
  • automatická notifikace změn v publikovaných datových sadách.

Základní logické celky POD:

  • NKOD - upravený a doplněný pro správu informací o jednotlivých kategoriích dat a jejich zařazení do VDF.
    • NKOD je nástroj, ve kterém jednotlivé OVS katalogizují jimi zveřejňovaná otevřená data a jiné OVS a veřejnost v něm otevřená data vyhledává a získává k nim přístup.
    • Existence NKOD a povinnost jednotlivých OVS v něm katalogizovat svá otevřená data je dána zákonem č. 106/1999 Sb., o svobodném přístupu k informacím, který zavádí definici otevřených dat a zakládá existenci NKOD.
  • Katalog uživatelů otevřených dat (KUOD) - bude evidovat, jaké OVS využívají jaká otevřená data ve VDF.
  • Katalog (registr) uživatelů dat s požadavkem notifikace změn v publikovaných datových sadách - seznam uživatelů s požadavky na zasílání notifikací o změnách pro konkrétní publikované datové sady.
  • Notifikační HUB - nástroj zajišťující s pomocí KUOD s požadavkem notifikace automatickou distribuci notifikací změn v publikovaných sadách při ohlášení změny ze strany publikujícího OVS. Při registraci datové sady předává publikujícímu OVS URI pro zasílání informací o změnách.
  • Registr požadovaných datových sad VDF - seznam požadavků na doplnění chybějících obrazů PPDF do VDF.

Sémantický slovník pojmů - slovník pojmů veřejné správy, jako nástroj harmonizace sémantiky otevřených dat, bude vytvořen na bázi výčtů údajů vedených k agendám v RPP dle § 51 odst. 5 písm. g), h) a i) zákona č. 111/2009 Sb. o základních registrech a bude je postupně rozpracovávat do podoby opakovaně použitelných a sdílených informačních modelů (ontologií), které budou propojeny na údaje vedené k agendám a též propojovány se slovníky a ontologiemi vznikajícími z iniciativy EU (např. ISA Core Vocabularies). Logická datová schémata popisující jejich strojové (syntaktické) vyjádření na logické úrovni budou propojena na pojmy sémantického slovníku pojmů, čímž bude realizováno propojení sémantiky (významu) dat napříč jednotlivými datovými sadami a jejich zdroji. Sémantický slovník pojmů bude nedílnou součástí VDF a stane se základem popisu sémantiky publikovaných dat a jejich vzájemného propojení.

Nástroj pro správu sémantického slovníku pojmů (NSSSP) – umožní správu sémantického slovníku pojmů všemi OVS a popisovat jejich data za účelem sémantické harmonizace.

Portál otevřených dat (POD) – vstupní brána do světa otevřených dat VS. Obsahuje NKOD, vzdělávací informace, publikační standardy, šablony, doporučené postupy, související dokumenty a informace o otevřených datech zveřejněných ve Standardech publikace a katalogizace otevřených dat

Lokální katalog otevřených dat - LKOD - volitelně implementován pro potřeby katalogizace otevřených dat konkrétního poskytovatele dat. NKOD pravidelně automaticky přebírá informace o zveřejněných datových sadách z jednotlivých lokálních katalogů.

Katalog aplikací nad otevřenými daty – seznam všech služeb (aplikací) využívajících publikované datové sady s možnostmi vyhledávání dle využívaných datových sad, nebo na základě životních situací konzumenta dat.

Obsahové rozdělení datových zdrojů VDF

VDF je tvořen dvěma druhy datových zdrojů:

  • datové zdroje obsahující veřejný obraz PPDF,
  • datové zdroje rozšiřující obraz PPDF o data, která v PPDF nejsou.

Veřejně přístupným obrazem datového zdroje chápeme data z tohoto zdroje transformovaná do strojově čitelné podoby, kterou lze zveřejnit. V případě, že lze datový zdroj zveřejnit celý v jeho původní podobě, je touto transformací identita. Tj. datový zdroj je v tomto případě sám sobě veřejně přístupným obrazem. U ostatních datových zdrojů transformace v maximální možné míře zachovává detaily původních dat a provádí tak typicky jen nezbytně nutnou anonymizaci. Ta většinou znamená buď projekci dat (tj. odstranění některých typů údajů z datové sady) nebo jejich statistickou agregaci.

Pro datové zdroje vytvářející veřejně přístupný obraz PPDF by měla platit následující jednoduchá obecná pravidla.

  • Pro každý datový zdroj v PPDF musí existovat nějaký obraz ve VDF a to:
    • pro datové zdroje s legislativně stanoveným dálkovým přístupem budou předmětem publikace vždy primární data,
    • u datových zdrojů bez legislativně stanoveného dálkového přístupu budou v případě, že tomu nebude nic bránit, publikována primární data, v opačném případě bude jejich publikace provedena formou statistik a agregací s co nejjemnější granularitou.

Výčet datových zdrojů tvořící obsah VDF

  • Obrazy základních registrů - jako obraz registru budou publikovány statistiky z registru
  • Obrazy veřejných rejstříků (veřejné rejstříky právnických a fyzických osob podle zákona č. 304/2013 Sb. (Zákon o veřejných rejstřících právnických a fyzických osob.).
    • spolkový rejstřík,
    • nadační rejstřík,
    • rejstřík ústavů,
    • rejstřík společenství vlastníků jednotek,
    • obchodní rejstřík,
    • rejstřík obecně prospěšných společností.
  • Obrazy údajů evidovaných v RPP dle § 51 odst. 5 písm. h) zákona č. 111/2009 Sb. o základních registrech.
  • Obrazy všech rejstříků, u kterých zákon definuje jejich dálkový přístup, pokud neexistují žádné právní překážky nebo významná rizika (v případě rejstříků bez stanoveného dálkového přístupu v zákonech - publikace agregací nebo statistik).
  • Publikované (i lokální) číselníky, jejich sémantické provázání, případná konsolidace a uvedení kontextů zachycujících jejich použití.
  • Publikované statistiky a jiné údaje využívané OVS, a které jsou vhodné pro veřejné zpřístupnění.

Zjednodušený koncept publikace dat do VDF

Cílem publikace dat VS do VDF je vytvoření harmonizovaného a konzistentního obrazu PPDF ve VDF, sémanticky provázaného i na odpovídající pojmy legislativy s pomocí Sémantického slovníku pojmů, včetně zachycených vzájemných souvislostí. Aby byla zajištěna konzistence VDF, a aby se z něj vytvořil rovnocenný obraz PPDF je proto nutné, aby publikované datové sady datových zdrojů v PPDF byly publikované i na úrovni propojených dat. Toho se dosáhne publikací konkrétních distribucí datových sad z PPDF se strojově čitelnou vazbou na sémantický slovník pojmů.

  • Základem publikace do VDF je tedy sémantický slovník pojmů vytvořený na základě údajů v RPP, a který popisuje PPDF a tedy i budoucí obrazy ve VDF.
  • Vlastní publikace bude realizovaná distribucemi datových sad s využitím takového formátu, který umožní zaznamenání souvislostí v datech a vazeb na sémantický slovník pojmů ve strojově čitelné podobě.

Publikované obrazy datových zdrojů PPDF ve VDF vytvoří infrastrukturu pro všechna otevřená data VS, což prakticky znamená, že publikující organizace nebudou muset při publikaci nových datových sad publikovat data, která již vypublikovaná budou, ale pouze budou publikovat nové rozšiřující informace k jednotlivým entitám VDF. Do jejich povinností ale přibude povinnost doplnit vazby nově publikovaných údajů na již existující entity ve VDF.

Publikovaná datová sada z datového zdroje PPDF musí k tomu, aby se stala součástí VDF:

  • musí splňovat všechny podmínky kladené na otevřená data ve smyslu zákona č. 106/1999 Sb. o svobodném přístupu k informacím,
  • musí být publikována dle předepsaných otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím
  • musí mít doplněn kontext, který mapuje strukturální prvky datové sady na sémantický slovník pojmů.

Dále platí následující pravidla:

  • V případě duplicit u publikovaných datových sad ve VDF, nebo doplňování údajů různými publikujícími ke stejné publikované entitě, spadá povinnost doplnění vazeb na již publikované údaje vždy na toho publikujícího, který publikuje doplňující údaje.
  • U každé datové sady publikované do VDF musí být uvedena informace o notifikačním mechanismu o změnách dle příslušné OFN uvedené na POD.
  • K zajištění právní závaznosti publikovaných dat musí být garantována jejich kvalita, aktuálnost a bezodkladná aktualizace, prostřednictvím organizačního a procesního zajištění v organizaci poskytovatele dat.

Správa dat VS ČR

Zapojení VDF do výkonu veřejné správy vyžaduje zajištěnou garanci kvality publikovaných datových sad, což znamená zajistit publikaci skutečně právně závazných, platných a pravidelně aktualizovaných datových sad s jasně definovanou zodpovědností OVS za takové sady. Je zřejmé, že takový stav bude obtížné dosáhnout stávajícími přístupy k publikaci otevřených dat ve VS, kdy publikace probíhá ne příliš koordinovaně, často nestandardními způsoby a s absencí používání doporučených standardů.

K zajištění kvalitního veřejného datového fondu bude nutné přistoupit k plánovanému a přesně definovanému vytváření VDF a také ke změně stávajícího paradigmatu správy dat VS ČR - oddělit data VS od aplikací a posunout je do centra řízení informatiky v souladu s postavením dat v legislativě. Správa a řízení dat VS se zdá být v budoucnu nezbytná i ve světle proklamací, že data jsou to nejcennější co organizace, a tedy i veřejná správa a v konečném důsledku i veřejnost, mají.

K zajištění kvality publikovaných datových sad, budou vydány:

  • “Pravidla a postupy publikace dat do VDF”,
  • “Pravidla a postupy publikace otevřených dat”,
  • “Datová politika VS ČR”.

Dále budou k zajištění snadného využití publikovaných datových sad soustavně rozvíjeny stávající a vytvářeny nové OFN (Otevřené formální formy), určující koncepční i technické vzory pro vlastní publikaci dat. OFN jsou a budou publikovány na Portálu otevřených dat a jsou dle zákona č.106/1999 Sb. pro publikující organizace závazné.

Pohledy na veřejný datový fond

Evidence subjektů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Propojený datový fond je postaven na výměně údajů o jednoznačně identifikovatelných subjektech a objektech. Při evidenci, správě a propojování údajů je nezbytné správně využívat k tomu určené identifikátory a nezneužívat dosud evidované identifikátory.

Podstatnou službou, která je součástí rozvoje služeb propojeného datového fondu je služba, která vrátí AIFO (agendový identifikátor fyzické osoby) pro současné i historické číslo a typ dokladu. Tato služba je nezbytná pro nahrazení perzistentních a významových identifikátorů typu Rodného čísla jako identifikátoru fyzické osoby nejen v procesech a dokumentech veřejné správy, ale i soukromoprávní sféře.

Identifikátory fyzických osob

V rámci propojeného datového fondu je stanoven soubor závazných architektonických doporučení týkajících se výměny údajů i vedení datového fondu (evidence údajů). To se pochopitelně týká i fyzických osob. Níže je tabulka s přehledem identifikátorů týkajících se fyzické osoby:

Název Popis Příklady Slouží k
Agendový identifikátor fyzické osoby (AIFO) Identifikátor, který přiděluje ORG pro danou agendu a je jedinečný pro osobu a agendu. AIFO v agendě evidence obyvatel, AIFO v agendě řidičských průkazů Technický identifikátor pro účely jednoznačné identifikace fyzické osoby v agendě a jako identifikátor osoby při výměně údajů. Je pouze v agendě, nikdy se neposkytuje a nepředává, překládá se výhradně přes ORG.
Pseudonym od NIA (BSI) Identifikátor, který přiděluje NIA pro každého kvalifikovaného poskytovatele služebBSI pro portál občana, BSI pro portál ČSSZ, BSI pro všeobecnou fakultní nemocnici Speciální typ stykového identifikátoru pro účely jednoznačné identifikace fyzické osoby, který lze proti službám základních registrů přeložit na AIFO.
Stykový Identifikátor (SI) Jednoznačný identifikátor pocházející z veřejné listiny, kterým lze identifikovat osobu při komunikaci s veřejnou správou. Jakýkoliv stykový identifikátor musí být v ROB, kromě BSI. Typ a číslo dokladu (OP, pas, ŘP) Využívá se při prezenční či listinné či elektronické komunikaci s klientem, namísto nebo vedle KI. Podle něj se provede překlad na KI pro vnitřní práci v agendě a AIS, i na AIFO v agendě pro komunikaci v rámci PPDF. AIS poté ví, jak AIFO, tak KI, v systémech se tento identifikátor (SI) neeviduje a neukládá.
Klientský identifikátor (KI) Klientské číslo používané v dané agendě nebo skupině agend jednoho OVS, jako úředníkům i klientům známý bezvýznamový identifikátor DIČ, Číslo pojištěnce, klientské číslo Úřední identifikátor, na rozdíl od AIFO je prezentován klientovi i úředníkovi. Využívá se při vnitřním i vnějším úředním styku v dané agendě nebo skupině příbuzných agend, zpravidla se neposkytuje mimo, ale využívá se jen v rámci této agendy. Klient si své číslo může, ale nemusí pamatovat, užívat či dokládat, k tomu slouží stykový klientský identifikátor (SI).

Evidence jiných fyzických osob

Při výkonu veřejné správy nastává situace, kdy se poskytované služby netýkají subjektu, který je vedený v základním registru obyvatel. Příkladem může být koupě nemovitosti cizincem, který nemá k ČR žádný další vztah. Taková osoba je vedena jen u správce systému spravující právní vztahy k nemovitostem (katastr nemovitostí). Závažným problémem se tato situace stane v okamžiku, kdy osoba, která je vedená v jenom systému požaduje další služby v jiných systémech, typicky může jít o zaplacení daní. V různých systémech se tedy vedou údaje k jedné a té samé osobě a není možné si je sdílet pomocí referenčního rozhraní, protože neexistuje v základním registru. Pro tento účel vznikla tzv. Evidence jiných fyzických osob, která má shromažďovat údaje o subjektech, kteří mají interakci s českou veřejnou správou a následně tyto údaje editovat do základního registru obyvatel prostřednictvím cizineckého informačního systému. Každý správce AIS, který eviduje subjekt, který není v základním registru má povinnost:

  1. Zjistit o subjektu maximum dostupných informací. Minimálně však jméno, příjmení, datum narození, číslo a typ identifikačního dokladu.
  2. Editovat tyto údaje do systému Evidence jiných fyzických osob
  3. Zajisti aktualizaci údajů, pokud o nich bude správce AIS informován

Identifikátory právnických osob

U právnických osob, které vznikají a jsou evidované v rámci české veřejné správy, je situace nepoměrně jednodušší. Naprostá většina právnických osob je vedena v Registru osob, na který nejsou kladena taková opatření týkající se ochrany osobních údajů, neboť na rozdíl od osobních údajů konkrétních fyzických osob je většina údajů o právnických osobách ze své podstaty veřejná.

Přesto je nutné při využívání a výměně údajů o právnických osobách dodržovat správné principy a využívat správné identifikátory:

  • Základním identifikátorem právnické osoby je identifikační číslo (IČO), to je také primární identifikátor vedený v rámci Registru osob, kde je vytvářen
  • Má-li právnická osoba více provozoven, základním identifikátorem provozovny je identifikační číslo provozovny (IČP), který je také veden v rámci Registru osob

Při kontaktu právnické osoby s veřejnou správou fakticky nejedná právnická osoba, ale jejím jménem jedná konkrétní fyzická osoba. I při případném zřetězení několika právnických osob ve výsledku jedná fyzická osoba. Ta přitom musí být k takovému jednání oprávněna.

Základní oprávnění jednání konkrétních fyzických osob jsou také vedena v rámci Registru osob jako referenční údaj. V příslušných editorských informačních systémech, jako jsou systémy veřejných rejstříků, mohou být vedeny specifická oprávnění pro zastupování právnické osoby. V rámci propojeného datového fondu jsou vždy dostupné vazby zapsané v Registru osob. Jiné vazby mohou být publikovány konkrétním AIS, za jejich výklad je však vždy zodpovědný čtenář.

Vzhledem k tomu, že se při komunikaci s právnickou osobou se tedy fakticky jedná o komunikaci s konkrétní fyzickou osobou jednající jejím jménem, je nutné, aby příslušný orgán veřejné moci ve všech svých souvisejících činnostech dodržoval principy Evidence subjektů.

Identifikátory subjektů jsou využívány při úřední komunikaci a interakci s klientem, při evidenci údajů v příslušných informačních systémech, při výměně údajů s dalšími informačními systémy.

Evidence jiných právnických osob

Podobně jako v případě evidence jiných fyzických osob, nastává při výkonu veřejné správy situace, kdy se poskytované služby netýkají subjektu, který je vedený v základním registru osob. V rámci rozvoje základních registrů a tím i celého PPDF se počítá s rozšířením o evidenci jiných právnických osob.

Každý správce AIS, který eviduje subjekt, který není v základním registru má povinnost:

  1. Zjistit o subjektu maximum dostupných informací. Minimálně však název, typ zřízení a další údaje o registraci právnické osoby včetně daňových a dalších identifikátorů
  2. Zajisti aktualizaci údajů ve svém datovém fondu, pokud o nich bude správce AIS informován a následně propagaci této změny do evidence jiných právnických osob.

Pohled na identifikátory ve VS

Prostorová data a služby nad prostorovými daty

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Prudký rozvoj ICT umožnil a vyvolává i mnohem větší rozsah prací s informacemi o území a jejich využívání v životě celé společnosti. Tento vývoj klade zásadně nové požadavky na úpravu podmínek pro nakládání s prostorovými daty (data, jejichž nutnou součástí jsou údaje o poloze v prostoru vyjádřená zpravidla ve formě souřadnic a topologie) a prostorovými informacemi (informace získané interpretací prostorových dat a vztahů mezi nimi). Vzhledem k mimořádnému významu prostorových informací především pro ochranu obyvatelstva, předcházení živelním pohromám a zajištění ochrany životního prostředí, navrhla Evropská komise na počátku 21. století zřídit ve spolupráci s jednotlivými členskými státy Infrastrukturu pro prostorové informace (soustava zásad, znalostí, institucionálních opatření, technologií, dat a lidských zdrojů, která umožní sdílení a efektivní využívání prostorových informací a služeb) v Evropském společenství nazvanou INSPIRE. Obecná pravidla pro její zřízení (propojením infrastruktur pro prostorové informace budovanými a rozvíjenými jednotlivými členskými státy) byla stanovena Směrnicí Evropského parlamentu a Rady 2007/2/ES, o zřízení Infrastruktury pro prostorové informace v Evropském společenství (INSPIRE), která byla do českého právního řádu transponována zákonem č. 380/2009 Sb., kterým se mění zákon č. 123/1998 Sb., o právu na informace o životním prostředí, ve znění pozdějších předpisů, a zákon č. 200/1994 Sb., o zeměměřictví a o změně a doplnění některých zákonů souvisejících s jeho zavedením, ve znění pozdějších předpisů. V průběhu implementace principů směrnice INSPIRE do národního prostředí se potvrdilo, že je účelné rozšířit principy INSPIRE nad rámec 34 témat prostorových dat směrnicí INSPIRE řešených a na jejich základě koordinovaně rozvíjet národní infrastrukturu pro prostorové informace (dále jen „NIPI“).

Na budování a využívání NIPI se různým způsobem a různou měrou podílejí veřejná správa (ústřední orgány státní správy, orgány územní samosprávy, bezpečnostní složky státu, složky IZS, …), profesní samospráva, výzkumné a vzdělávací instituce, komerční sféra, neziskové nevládní organizace i občané, přičemž dotčené subjekty vystupují v jedné i více rolích (vlastník, správce, provozovatel, pořizovatel, uživatel apod.). Významnou roli při budování NIPI hraje veřejná správa, neboť velké množství prostorových dat vzniká v procesech agend a informačních systémů veřejné správy. Rozvoj prostorových dat a služeb nad prostorovými daty a jejich využívání v rámci propojeného datového fondu je podmíněn standardizací datových modelů prostorových dat vytvářených jednotlivými agendami a standardizací služeb nad prostorovými daty. Standardizace služeb NIPI musí maximálně vycházet ze stávajících mezinárodních a evropských norem pro oblast prostorových dat a služeb nad prostorovými daty.

Pořízení a aktualizace prostorových dat používaných subjekty veřejné správy představuje soubor dlouhodobých, odborně, technicky, organizačně a finančně náročných úkolů. Do tohoto dlouhodobého procesu vstupují skutečné a nepřetržité změny v území, měnící se požadavky uživatelů, potřeba harmonizace datových sad na různých úrovních rozlišení podrobností, možnosti technologií a další vlivy.

V oblasti poskytování služeb pro zpřístupnění prostorových informací hraje zásadní roli směrnice evropského parlamentu INSPIRE, která v rámci prováděcích předpisů specifikuje požadavky na interoperabilní síťové služby. Specifikace využívá webové služby založené na standardech OGC – Web Map Service (WMS), Web Map Tile Service, Web Feature Service (WFS), Web Coverage Service apod. Interoperabilitu služeb pro zpřístupnění prostorových informací na národní úrovni je proto možné zajistit relativně snadno oproti časově, kapacitně a finančně náročnější harmonizaci datových sad. Ve výsledku jsou síťové služby požadované INSPIRE používány v rámci národní i evropské infrastruktury pro prostorové informace, zatímco harmonizované datové sady jsou poskytovány paralelně s neharmonizovanými. Existující vyhledávací (katalogové) služby, prohlížecí služby, služby stahování dat a služby transformační odpovídající požadavkům INSPIRE lze považovat za klíčové prvky NIPI, které již plní základní cíle, tj. zpřístupnění a sdílení prostorových informací mezi jinak heterogenními IS. Tyto služby jsou podobně jako soubory prostorových informací opatřeny metadaty (data, která popisují struktury a obsahy sad prostorových dat, prostorové služby a jiné složky IS; umožňují a usnadňují jejich vyhledávání, třídění a používání). Metadata jsou poskytovateli služeb zpřístupněna prostřednictvím katalogové služby podle standardu OGC CSW (Catalogue Service for Web), která umožňuje aplikacím, které ji umí konzumovat, vyhledávání v metadatech, například podle tzv. klíčových slov.

Služby založené na prostorových datech

Národní infrastruktura pro prostorové informace (NIPI): Běžně dostupné služby v rámci NIPI jsou služby, které umožňují vyhledání a zpřístupnění metadat (katalogové služby), zpřístupnění prostorových dat nejčastěji k náhledu (obvykle nazývány zjednodušeně jako služby mapové); v poslední době jsou běžné také služby stahování dat (online nebo formou předpřipravených datových sad). Méně časté, ale stále se rozvíjející, jsou služby analytické. Tvorba, správa a aktualizace prostorových dat a jejich zpřístupnění k náhledu nebo dalšímu užití má v České republice dlouhou tradici, která je podporována trvalým zájmem uživatelů. Tyto služby zpřístupňuje veřejná správa, méně pak soukromé firmy. Stejně jako u prostorových dat stanovení minimálních požadavků na tyto služby případně jejich zakotvení v české legislativě bude koordinováno v rámci plnění Akčního plánu GeoInfoStrategie.

Schéma NIPI

Systémy a služby prostorových dat

Úplné elektronické podání

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Ú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é.
  • 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).

Integrace informačních systémů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Z ostatních částí NAP lze vyvodit určité povinnosti pro integraci mezi jednotlivými informačními systémy. Je nutno rozlišovat, zda se jedná o vnitřní či vnější integraci a také, jaké údaje a za jakým účelem se v integraci vyměňují. Integraci informačních systémů můžeme rozdělit následovně:

  1. Integrace uvnitř jednoho ISVS mezi více komponentami
  2. Integrace uvnitř systémů jednoho správce (vnitřní integrace)
    • mezi dvěma informačními systémy veřejné správy
    • mezi informačním systémem a systémem spisové služby a mezi informačním systémem a jmenným rejstříkem
    • mezi ISVS a provozním informačním systémem
    • na portál za účelem zveřejnění
  3. Integrace na systémy jiného správce (externí integrace)

Integrace na systémy jiného správce s pomocí eGSB / ISSS

Portály veřejné správy a soukromoprávních uživatelů údajů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Portál je vnímán jako celý funkční celek obsahující Front-end (logika zobrazující chování směrem ke klientovi) i Back-end (logika realizující chování systému a vnitřní i vnější integraci) realizující všechny typy služeb dle Informační koncepce ČR - Informační, Interaktivní a Transakční. Z tohoto mimo jiné vyplývá, že portál je informačním systémem veřejné správy.

  • V oblasti informačních služeb poskytuje uživatelům přehled a veřejně dostupné informace z oblasti, kterou portál obsahuje včetně popisu životních situací.
    • V informační části není potřeba řešit identifikaci, autentizaci a autorizaci uživatele.
  • V oblasti interakčních služeb poskytuje uživatelům personifikované údaje s využitím vícero informačních kanálů, zpětnou vazbu mezi jeho konáním, a to včetně historie.
    • Interakční služby vyžadují identifikaci, autentizaci a autorizaci uživatele.
  • V oblasti transakčních služeb poskytuje uživatelům podání všech typů, včetně provedení platby nebo rezervace termínu pro prezenční jednání, získání potvrzení a doručení rozhodnutí úřadu.
    • Transakční služby vyžadují identifikaci, autentizaci a autorizaci uživatele.

Portály tedy nemohou být samostatné a nepropojené aplikace, ale naopak musí se jednat o prostředek, který je integrován s informačními systémy v úřadu. Především s elektronickou spisovou službou, s agendovými informačními systémy, ale třeba i s ekonomickými systémy tam, kde se jejich prostřednictvím shromažďují údaje o výplatách či o poplatcích podle jednotlivých klientů. V případě poskytování všech 3 typů služeb se jedná o tzv. integrované on-line služby veřejné správy dle Informační koncepce ČR.

Portál má sloužit klientovi k získání informací, jako prostředek pro publikování otevřených dat, statistik a veřejných výstupů, pro elektronická podání a komunikaci klienta s úřadem. Portál musí též sloužit i držitelům zaručené elektronické identifikace jako prostředek pro získání jejich údajů, pro různé notifikace, ale třeba i pro interaktivní podání žádostí, či podání žádostí o výpisy. Klientovi musí poskytnout též tzv. profil neboli personifikovanou část, kde si portál drží základní údaje o klientovi, které zná úřad nebo které klient sdělit sám ze své vůle.

Celkové chování a interakce Portálu vůči občanům i úředníkům se nazývá User Experience (UX). Do UX patří nejen grafická podoba, ale také jazyk (forma, odbornost, …), způsob interakce, komunikační kanály, obdobné způsoby identifikace uživatelů atd. Pro snadné používání občanem je nutné, aby každý portál používal jednotné, centrálně defikované UX. Zjednodušeně řečeno jde o obdobu chování a interakce, jakou má popsaný Portál občana.

PO a PVS - Portál občana a Portál veřejné správy

Portálem občana je myšlena transakční část Portálu veřejné správy, kde klient/občan může skrze samoobslužné služby pod svou zaručenou elektronickou identitou činit podání vůči veřejné správě a využívat její služby. Více je v samostatném funkčním celku

Agendový portál

Agendovým portálem je myšlen portál poskytující služby logicky centralizovaného systému pro jiné orgány veřejné moci. Typicky jde tedy o portál agendy v přenesené působnosti poskytovaný správcem (ohlašovatelem) agendy. Klientem je může být jak občan, tak jiný orgán veřejné správy. Platí, že služby pro klienta - občana musí být publikovány dle jedné z forem federace do Portálu občana.

Portál území

Portálem území je myšlen portál poskytující služby, které spadají pod určité území ČR, typicky kraj, obec, město, městská část - souhrnně možno označit za samosprávy. Portál území může obsahovat kromě samosprávních služeb jako např. správa místních poplatků, i služby přenesené, avšak neměla by nastat situace, kdy je služba přenesené působnosti vytvořena jen pro portál území. Je zodpovědnost věcného správce, aby vytvořil centrální prostředí pro vyřizování služeb přenesené působnosti, které portál území využije, ale nevytváří. V případě portálů území se předpokládají dva trendy:

  • Jednak budou lokální portály samospráv obsahovat obrácený směr navigace do Portálu občana, kde bude moci klient vyřídit vše ostatní ze státní správy, co případně nenašel v místním portálu a
  • lokální portály budou moci být v dlouhodobé perspektivě nahrazovány místně přizpůsobenými službami centrálního Portálu občana.

Portál soukromoprávního uživatele údajů

V případě portálu soukromoprávního uživatele údajů (také jako SPUÚ) se jedná o situaci, kdy vlastník portálu není orgán veřejné moci, ale dle své povahy je podřízen zákonu 111/2009 Sb. Může se jednat o portály poskytovatelů zdravotních služeb, soukromých pojišťoven, bank, státních podniků, apod. Takovéto portály poskytují služby, které mohou být federovány do Portálu občana, avšak pouze za předpokladu, že SPUÚ je ohlášen v rejstříku a má povinnost elektronicky ověřovat totožnost klienta.

Pohledy na portály veřejné správy

Přístupnost informací

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Přístupnost informací a služeb ve smyslu “accessibility” je způsob publikování a provozování tak, aby s informacemi a službami mohly na rovnoprávném základě pracovat všichni, včetně uživatelů se specifickými potřebami, zejména osoby se zdravotním postižením (dále také “OZP”). Tyto osoby využívají moderní technologie založené na klasických zařízeních typu počítač, notebook, tablet či mobilní telefon, mají na nich však tzv. “Asistivní software”, který jim umožňuje plnohodnotně pracovat s internetem, pokud jsou příslušné služby, aplikace a informace přístupné.

Přístupnost je v souladu s principy tzv. “Governance accessibility” řešena na třech úrovních:

  1. Přístupnost služeb veřejné správy
  2. Přístupnost internetových stránek, mobilních aplikací, informačních systémů a informací se kterými pracuje veřejnost včetně OZP
  3. Přístupnost informačních systémů využívaných úředníky a zaměstnanci včetně OZP

Obecně o přístupnosti

Přístupnost realizujeme proto, aby také OZP mohly na rovnoprávném základě využívat služby a informace, jako osoby bez jakéhokoliv postižení či specifických potřeb. Přístupnost ve veřejné správě je jednou ze základních společenských povinností, realizuje se jí soubor základních práv a nutnosti zabránit diskriminaci určitých osob.

Přístupnost informací je pak ryze technická disciplína, která říká, jakým způsobem mají být budovány informační systémy a jejich uživatelská rozhraní a jejich funkce tak, aby výstupem byly informace v přístupné podobě (z technického hlediska). Sama přístupnost informací nikterak nezasahuje do samotného vytváření informací, ale do způsobu jejich prezentace a publikace navenek. Jedná se o soubor technik, doporučení, norem a pravidel a postup, jejichž dodržení se zajistí, aby s informacemi a službami v elektronické podobě mohla pracovat co nejširší skupina lidí.

Elektronická fakturace

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Elektronická fakturace (také jako „e-fakturace“ či „efakturace“) je moderní prostředek, jehož primárním cílem je usnadnit a zefektivnit ekonomickým subjektům odesílání, příjem e-faktur a jejich následnou archivaci k dalšímu zpracování v rámci Evropské unie. E-faktura je dokumentem v digitální podobě (elektronickým dokumentem) podle ustanovení § 2 zákona č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů a nařízení eIDAS. Může být doručena ve strukturovaném nebo nestrukturovaném datovém formátu. Může být účetním záznamem podle zákona č. 563/1991 Sb., o účetnictví, daňovým dokladem podle zákona č. 235/2004 Sb., o dani z přidané hodnoty, může sloužit i pro jiné účely (např. jako dodací list, záruční list, důkazní prostředek apod.)

E-fakturace v kombinaci s řádně vedenou spisovou službou dle zákona č.499/2004 Sb., o archivnictví a spisové službě a s ekonomickým informačním systémem uzpůsobeným pro zpracování elektronických faktur nabízí ekonomickým útvarům orgánů veřejné správy:

  • Snížení administrativní a transakční zátěže následováno s výrazným zvýšení produktivity při zacházení s daňovými doklady
  • Rychlá a snadná dohledatelnost daňového dokladu
  • Bezpečný a spolehlivý prostředek v kombinaci s kvalifikovanými prostředky pro vytváření důvěryhodného podpisu dle nařízení eIDAS č.910/2014
  • Zajištění přeshraniční interoperability e-fakturace v rámci Evropské unie

Ekonomické aspekty

Evropská komise předpokládá, že „Masové přijetí elektronické fakturace v EU by vedlo k významným hospodářským přínosům a odhaduje se, že přechodem od papírových faktur k fakturám elektronickým se za období šesti let ušetří přibližně 240 miliard EUR.“1. Na základě tohoto zjištění „Komise chce, aby se elektronická fakturace stala převládající metodou fakturace v Evropě do roku 2020.

Jako prostředek k dosažení tohoto cíle má směrnice 2014/55/EU o elektronické fakturaci při zadávání veřejných zakázek za cíl usnadnit používání elektronických faktur hospodářskými subjekty, které dodávají zboží, práce a služby pro orgány veřejné správy (B2G), jakož i podporovat obchodování mezi samotnými hospodářskými subjekty (B2B). Vymezuje především právní rámec pro zavedení a přijetí evropské normy (EN) pro sémantický datový model vytvořený ze základních prvků elektronické faktury (EN 169311:2017).

Norma EN 169311:2017 a její pomocné normalizační výstupy umožní sémantickou interoperabilitu elektronických faktur a pomohou odstranit bariéry na trhu a překážky v obchodu vyplývající z existence rozdílných vnitrostátních právních předpisů a norem – a přispějí tak k dosažení cílů stanovených Evropskou komisí.

Práce s elektronickými fakturami, ale zejména elektronizace celého nákupního řetězce od sběru požadavků, veřejné výběrové řízení, přes objednávku/smlouvu, potvrzení dodávek, fakturu, po platbu a rozúčtování výdajů/nákladů přinese významné úspory transakční i úspory spojené s lepším rozhodování a mnohem snáze a lépe provedenými řídícími kontrolami (1., 2., 3. a 4.) podle zákona č. 320/2001 Sb. o finanční kontrole a vyhlášky č. 416/2004 Sb., kterou se provádí zákon o finanční kontrole.

Portál občana a portál veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Portálem občana je myšlena transakční část Portálu veřejné správy, kde klient/občan může skrze samoobslužné služby pod svou zaručenou elektronickou identitou činit podání vůči veřejné správě a využívat její služby. Služby portálu občana přejímají veškeré služby CzechPOINT@home, který byl určen pro občany, kteří nechtějí pro výpis z rejstříku chodit na kontaktní místo Czech POINT a mají zřízenu vlastní datovou schránku fyzické osoby. Datová schránka žadatele slouží pro odeslání žádosti a pro doručení vystaveného výpisu z rejstříku nebo jiné odpovědi.

V případě Portálu občana, jakožto součásti Portálu veřejné správy, stojí občan jako samoobslužný uživatel „vně" veřejné správy a portál mu poskytuje jedno univerzální vstupní místo dovnitř. Z toho důvodu jsou všechny věcné (agendové) a do budoucna i místní portály se svými službami federalizovány „pod" tímto ústředním portálem. Federace je na různých úrovních, které Portál občana podporuje:

  • Federace Single sing-on
    • Zajištění propojení pomocí jednotné elektronické identity, která je realizována systémem Národní idenitní autority. Na Portálu občana je zveřejněna jen informace (link), na které adrese na nachází federovaný portál.
  • Federace s poskytováním údajů
    • Zajištění propojení pomocí jednotné elektronické identity, která je realizována systémem Národní identitní autority. Na Portálu občana je zveřejněna interaktivní část, která aktivně poskytuje údaje ze své působnosti.
  • Federace s obsloužením služeb
    • Zajištění propojení pomocí jednotné elektronické identity, která je realizována systémem Národní identitní autority. Na Portálu občana je zveřejněna celá služba, včetně potřebných formulářů a logiky nutné k vyřízení.

Portál občana pro svou funkcionalitu využívá služby propojeného datového fondu, stejně tak služby národní identitní autority. Z pohledu propojeného datového fondu je Portál občana jedním ze čtenářských AIS, který má zmocnění dle agendy A344 zobrazovat subjektu práva jeho informace, které o něm vede veřejná správa. Portál občana v tomto musí zajistit, aby agenda, dle které se řídí byla neustále aktualizovaná dle toho, jak se budou postupně rozšiřovat služby a portály poskytující údaje. Technicky je Portál občana připojený jako čtenářský AIS na systém eGON Service Bus, skrze který čerpá údaje publikované agendami pomocí tzv. kontextů. V tomto musí Portál občana pouze pravidelně aktualizovat čerpaný seznam kontextů jiných agend. Z pohledu národní identitní autority je Portál občana poskytovatelem služeb čerpající zaručené služby identifikace a autentizace.

Národní identitní autorita

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

NIA zajišťuje orgánům veřejné správy státem garantované služby identifikace a autentizace včetně federace údajů o subjektu práva ze základních registrů a možnost předávání přihlašovací identity dle principy Single Sign-On. Pro osoby uvedené v ROB nebo přihlašující se identitou v rámci eIDAS z členských států EU nemusí OVS řešit přihlašovací identity pro své klienty samo. V současném stavu ROB (stav As-Is) tedy pouze pro občany ČR a cizince s trvalým pobytem. V budoucím stavu (stav To-Be) pro občany ČR, cizince s trvalým pobytem a jiné fyzické osoby (EjFO), které mají k ČR právní či majetkový vztah (zahraniční vlastník nemovitosti, zahraniční lékař, zahraniční student, apod.).

Národní identitní autorita vytváří federativní systém, který se skládá z následujících komponent:

  • Národní bod jako centrální bod federativního systému, který zajišťuje komunikaci a registraci účastníků federace. Tato komponenta zajišťuje současně vždy jednoznačné ztotožnění osoby, která prokazuje svoji totožnost předložením autentizačních prostředků
  • Kvalifikovaný správce, který vydává jednoznačně identifikovaným fyzickým osobám prostředky pro vzdálenou autentizaci (prokázání totožnosti) a provádí veškeré činnosti spojené se správou těchto prostředků a prokazováním totožnosti fyzické osoby
  • Základní registry, které poskytují jednoznačnou identifikaci osoby a zajištění vazeb této osoby vůči referenčním údajům o osobě
  • Národní uzel eIDAS, který zajišťuje přijímání vzdáleného prokázání totožnosti z ohlášených systémů dle nařízení eIDAS a předávání vzdálené identifikace a autentizace z České republiky ostatním státům EU. Ostatní státy EU budou muset akceptovat české identity od 13.9.2020, kdy vyprší lhůta ohlášeného prostředku Elektronického občanského průkazu.

Ačkoliv nyní poskytuje NIA své služby pouze jako "Front-end" řešení za pomoci SAML tokenů, je plánováno i poskytování služeb jako "Back-end" pro využití překladů identity a identifikátorů za pomoci eGON služeb.

Atributy vydávané Service Providerům

Následující atributy jsou NIA vydávány tzv. kvalifikovaným poskytovatelům služby. Problematika je popsána také v části Portály veřejné správy a soukromoprávních uživatelů údajů. Tučně označené atributy odpovídají standardu eIDAS, ostatní atributy sice standardu neodpovídají, kvalifikovaný poskytovatel služby má ale možnost při komunikaci v rámci ČR o jejich vydání zažádat.

Atribut/Element Název atributu Popis
Příjmení CurrentFamilyName Referenční údaj – Příjmení fyzické osoby. Viz eIDAS reference.
Jméno CurrentGivenName Referenční údaj – Jméno, případně jména fyzické osoby. Viz eIDAS reference.
Datum narození DateOfBirth Referenční údaj – Datum narození fyzické osoby. Viz eIDAS reference.
Místo narození PlaceOfBirth Referenční údaj – Místo narození fyzické osoby. Viz eIDAS reference.
Země narození CountryCodeOfBirth Referenční údaj – Země narození fyzické osoby, předávána v kódu podle standardu ISO 3166-3.
Adresa pobytu CurrentAddress Referenční údaj – Adresa pobytu fyzické osoby, je předávána zakódovaná pomocí BASE64. Obsahuje (pokud je uvedeno v ROB) název ulice (Thoroughfare), název pošty (PostName), PSČ (PostCode), název obce, případně doplněnou o část obce (CvaddressArea) a číslo domovní/číslo orientační (LocatorDesignator). Atribut vychází z ISA Core Vocabulary a tam je také uveden podrobnější popis atributu.
Email Email Emailová adresa uvedená na eidentita.cz v sekci „Vaše údaje“.
Je starší než X IsAgeOver Výpočet je starší než X podle referenčního údaje Datum narození.
Věk Age Výpočet věku podle referenčního údaje Datum narození.
Telefon PhoneNumber Telefonní číslo uvedeno na eidentita.cz v sekci „Vaše údaje“.
Adresa pobytu (předávaná v podobě RÚIAN kódů) TRadresaID Referenční údaj – Adresa pobytu fyzické osoby je předávána v kódech podle RUIAN. Obsahuje (pokud je uvedeno v ROB) kódy pro okres, obec, část obce, ulici, PSČ, stavební objekt, adresní místo, číslo domovní a orientační.
Level of Assurance (LoA) LoA Stupeň (úroveň) jistoty nebo zajištění. Viz eIDAS reference.
Pseudonym PersonIdentifier Identifikátor fyzické osoby.
Typ dokladu IdType Druh elektronicky čitelného dokladu.
Číslo dokladu IdNumber Číslo elektronicky čitelného dokladu.

Pseudonym - bezvýznamový směrový identifikátor

Pseudonym, neboli identifikátor fyzické osoby, který se od NIA předává je pro každého kvalifikovaného poskytovatele služby jedinečný a neměnný. Neslouží jako veřejný identifikátor, ale jako identifikátor technický. Pokud by došlo na situaci, kdy se pseudonym pro fyzickou osobu změní, bude úřad o této skutečnosti informován prostřednictvím informačního systému základních registrů, protože se mu změní i agendový identifikátor fyzické osoby. Soukromoprávní uživatel údajů o této změně nebude notifikován, protože nemůže být napojen na základní registry nepřímo, avšak tuto službu mu může zprostředkovat jeho nadřízený úřad.

Pokud však chce mít kvalifikovaný poskytovatel služby jistotu o aktuálnosti pseudonymu, musí postupovat dle pravidel propojeného datového fondu, tzn. mít ztotožněn svůj datový kmen a odebírat notifikace z informačního systému základních registrů.

Referenční rozhraní

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Referenčním rozhraním se v souladu s jeho definicí zakotvenou zejména v zákoně č. 365/2000 Sb., o informačních systémech veřejné správy a zákoně č. 111/2009 Sb., o základních registrech fakticky rozumí rozhraní pro uskutečňování vazeb mezi informačními systémy veřejné správy, a to především při realizaci propojeného datového fondu sdílením údajů mezi jednotlivými agendovými informačními systémy formou sdílených služeb. Referenční rozhraní je tedy komunikačním rozhraním pro poskytování a využívání sdílených služeb jednotlivých správců informačních systémů veřejné správy.

Referenční rozhraní se skládá ze tří hlavních komponent:

Komponenta Zkratka Popis funkčnosti
Informační systém základních registrů ISZR Poskytuje veškeré služby týkající se využívání údajů ze základních registrů, realizuje i služby pro editory do ZR a pro sdílení údajů editorů ZR
Informační systém sdílené služby eGSB/ISSS Rozhraní pro sdílení a výměnu údajů mezi ISVS a uskutečňování vazeb mezi nimi
Informační systém pro hromadný výdej údajů v multiagendových dotazech (Formulářový agendový informační systém) FAIS Slouží k zpracování dotazů a výdeji údajů ve formě formulářů, včetně hromadných, a to i z více ZR či dalších ISVS. Dotazy a výdeje jsou přenášeny prostřednictvím Datových schránek.

Využívání údajů prostřednictvím referenčního rozhraní je vždy realizováno výhradně na základě příslušných oprávnění evidovaných v RPP, to však neznamená, že RPP řídí samotné vydávání údajů. Za konečné rozhodnutí, zda údaje poskytnout nebo neposkytnout, je vždy zodpovědný zdrojový AIS (ten, o jehož údaje se žádá). Toto rozhodnutí činní na základě referenčních údajů o oprávněních evidovaných v RPP. V rámci budoucího rozvoje PPDF se počítá s tím, že oprávnění na údaje či konkrétní služby bude kontrolovat ISZR a eGSB/ISSS pomocí referenčních údajů z RPP. Koncový stav by tedy měl vypadat tak, že žádající systém volající službu obdrží požadované údaje nebo informaci, že nemá potřebná oprávnění pro příslušný požadavek. Oprávnění, a tedy i přístup k údajům a službám, by tedy nemusel dělat systém, respektive jeho správce, ale vše by se řídilo pomocí referenčních údajů RPP.

Prostřednictvím referenčního rozhraní se:

  • Realizuje zápis a editace údajů do základních registrů
  • Realizuje využívání údajů ze základních registrů
    • S ohledem na oprávnění k přístupu k údajů v základních registrech, podle ohlášení jednotlivých agend v RPP, s využitím služeb vnějšího rozhraní ISZR
    • Realizují se také služby notifikací a aktualizací údajů základních registrů s využitím služeb vnějšího rozhraní ISZR
  • Realizuje výměna údajů formou sdílených služeb mezi jednotlivými AIS
    • Provádí OVM mezi sebou s využitím služeb eGSB/ISSS a výměny údajů. V případě výměny údajů o fyzických osobách provádí eGSB/ISSS překlad AIFO prostřednictvím ISZR
  • Realizují služby hromadného výdeje údajů a skladby dotazů a odpovědí na více údajů
    • Realizuje komponenta FAIS a využívají OVM či SPUÚ s patřičným oprávněním
    • FAIS na základě žádosti přijaté přes datovou schránku provádí volání služeb ISZR a ISSS a sestavenou odpověď vrací žadateli opět prostřednictvím datové schránky
  • Realizují služby notifikací a aktualizací údajů v jednotlivých agendách pomocí centrální komponenty

Základní pravidla pro využívání referenčního rozhraní

  • Dodržovat vyhlášky k zákonu 365/2000 Sb., především o technických a funkčních parametrech připojení k referenčnímu rozhraní
  • K referenčnímu rozhraní přistupují OVM prostřednictvím svých AIS a SPUÚ pomocí soukromoprávního systému pro využívání údajů nebo prostřednictvím AIS jiného OVM
  • Každý systém přistupující k referenčnímu rozhraní musí prokazovat svoji "identitu" prostřednictvím systémového certifikátu vydaného Certifikační autoritou ve správě SZR
  • Při výměně údajů o subjektech práva či objektech územní identifikace se ověřuje, zda tyto subjekty (ROB, ROS) či objekty (RÚIAN, RPP) jsou uvedeny v základních registrech (ověření referenční vazby)
  • OVM, které požaduje údaje o konkrétním subjektu, je zodpovědné za jeho řádné ztotožnění ve své agendě, tj. uvedení AIFO, pokud jde o fyzickou osobu nebo IČO, pokud jde o právnickou osobu. Pokud subjekt není řádně ztotožněn, pak získané údaje mohou být pouze informativní
  • Záznamy (logy) o identifikaci žádajícího systému, času odpovědi, struktuře a obsahu poskytnutých údajů vede poskytující systém. Identifikaci poskytujícího systému, času přijetí odpovědi, struktuře a obsahu údajů vede přijímající systém. Referenční rozhraní zaznamenává identifikaci obou systémů, čas a strukturu předávaných údajů.
  • Procesní provázání s eSSL v případě, kdy je referenční rozhraní využíváno k předávání dokumentů dle pravidel spisové služby. Toto se týká jen těch situací, kdy je obsahem skutečně dokument a nejedná se tedy jen o předávání dat.

Informační systém správy čerpání a publikace údajů referenčního rozhraní veřejné správy ČR

Informační systém správy čerpání a publikace údajů referenčního rozhraní veřejné správy ČR (také jako „systém správy napojení“) je Informační systém veřejné správy, který kterémukoliv subjektu, který je napojen na referenční rozhraní veřejné správy (dle zákona 365/2000 Sb.), umožní spravovat údaje o informačních systémech, které poskytují nebo čerpají údaje skrze referenční rozhraní. Systém správy napojení vznikne jako rozšíření současného systému RAZR (registrační autorita základních registrů) nebo jako nový systém a musí podporovat funkcionality:

  • Přihlášení pomocí systému JIP/KAAS
  • Přihlášení pomocí systému NIA
  • Evidence všech připojených IS (agendové informační systémy a soukromoprávní systémy pro využívání údajů) dle rejstříku informačních systémů veřejné správy
  • Evidence všech věcných správců připojených IS a jejich administrátorů (editorů)
  • Evidence všech kontextů dle agend definovaných v RPP
  • Kontrola oprávnění na údaje dle RPP
  • Historie čerpání a publikace údajů připojeného IS dle logů referenčního rozhraní
  • Individualizace informací pro přihlášeného a oprávněného uživatele
  • Umožnění nahlášení neoprávněného čerpání / poskytnutí údajů, včetně sledování průběhu vyřízení
  • Umožnění nahlášení zneužití certifikátu, včetně sledování průběhu
  • Umožnění objednávky nového certifikátu, včetně sledování průběhu
  • Umožnění správy kontextu (založení, změna, smazání)

Informační systém základních registrů

Informační systém základních registrů legislativně zakotvuje zákon č. 111/2009 Sb., o základních registrech. ISZR je informačním systémem veřejné správy, jehož prostřednictvím je zajišťováno sdílení dat mezi jednotlivými základními registry navzájem, základními registry a agendovými informačními systémy a agendovými informačními systémy navzájem, správa oprávnění přístupu k datům a další činnosti.

ISZR se skládá ze dvou základních rozhraní:

Rozhraní Hlavní uživatelé Popis funkčnosti
Služby vnitřního rozhraní Pouze ISZR vůči základním registrům Vnitřní služby, které může využívat pouze ISZR pro získávání a dereferenci údajů z jednotlivých základních registrů
Služby vnějšího rozhraní Agendové informační systémy Služby umožňující využívání údajů ze základních registrů a editorů základních registrů

Prostřednictvím ISZR se zejména realizuje:

  • Přístup k údajům vedeným v základních registrech
  • Služby reklamace, zpochybnění, notifikace, aktualizace údajů ze základních registrů
  • Zápis a změny údajů do základních registrů
  • Překlad agendových identifikátorů fyzických osob
  • Zabezpečení dodržování oprávnění zapsaných v Registru práv a povinností

Aby se mohli uživatelé připojit k základním registrům, postupují podle níže uvedené tabulky:

Uživatel Cesta Zajišťuje
Subjekt práva nemůže přímo přistoupit, zprostředkovaně skrze portál občana nebo univerzální kontaktní místa a výpisy z něj Portál občana, kontaktní místa veřejné správy či FAIS (zaslání žádosti přes datovou schránku) prostřednictvím publikovaných formulářů. Je zajištěn výpis údajů a reklamace údajů. Získané údaje mohou být využity ve formulářích jiného správce formulářů OVM.
Orgán veřejné moci svým Agendovým informačním systémem zajistí Správa základních registrů po splnění podmínek
Orgán veřejné moci Agendovým informačním systémem jiného správce zajistí správce daného AISu
Orgán veřejné moci přes rozhraní CzechPOINT@office zajistí MV ČR, správce CzechPOINT@office v součinnosti s lokálním administrátorem
Soukromoprávní uživatel údajů Agendovým informačním systémem vybudovaným OVM zajistí OVM, které spravuje příslušný AIS
Soukromoprávní uživatel údajů Soukromoprávní systém pro využívání údajů Zajistí SPUÚ, které je oprávněné takový systém provozovat

Pro připojení agendových informačních systémů k základním registrům musejí být splněny některé základní podmínky, které stanovuje Správa základních registrů svou provozní dokumentací ISZR. A to zejména:

  1. Správce AIS musí mít svůj IS ohlášen v rejstříku ISVS v Registru práv a povinností
  2. Musí mít v RPP ohlášenu působnost v agendě, kterou (které) tímto AISem bude vykonávat pro příslušné OVM
  3. Správce AIS musí v RPP uvést, která OVM/SPUÚ mohou přes jeho AIS přistupovat k ZR nebo jiným AIS.
  4. AIS musí být připojen na příslušný přístupový bod (KIVS nebo internet). Způsob a proces připojení AIS na KIVS je mimo oblast systému ZR
  5. AIS musí být certifikován pro přístup k eGON rozhraní. Certifikace je proces v kompetenci SZR. V rámci tohoto procesu je vymezena působnost AIS – agenda., agendové role a OVM Tento proces je popsán v samostatném dokumentu dostupném na webu SZR.
  6. AIS musí mít vydán elektronický klientský certifikát. Vydání klientského certifikátu je poslední krok v procesu certifikace AIS, který provádí SZR
  7. AIS musí mít v rámci RAZR (Registrační autorita ZR) dle bezpečnostního profilu povolen přístup ke konkrétním eGON službám. Oprávnění k jednotlivým údajům je definováno na základě kombinace OVM / agenda / agendová role, a vyplývá z informací v RPP
  8. Musí mít ve svém AIS implementována volání služeb ISZR, respektive, musí být schopen řádně volat, konzumovat a využívat webové služby vnějšího rozhraní ISZR dle provozní dokumentace ISZR

Základní registry

Základní registry jsou základním (referenčním) datovým zdrojem údajů o subjektech a objektech práva a o výkonu veřejné správy.

Jedná se o referenční údaje o

  • fyzických osobách,
  • právnických osobách,
  • adresách a územních prvcích a nemovitostech
  • orgánech veřejné moci a soukromoprávních uživatelích údajů,
  • agendách a působnosti výkonu veřejné správy,
  • některých rozhodnutí měnících referenční údaje.

Více o referenčních údajích je uvedeno v Referenční údaje.

Základní registry tak tvoří páteř propojeného datového fondu veřejné správy včetně mechanismu pseudonymizace a propojování identifikací z jednotlivých agend. Mimo to poskytují zejména fyzickým osobám přehled o využívání jejich údajů jednotlivými čtenáři (OVM, SPUÚ, atd.) a poskytování jiným osobám.

Registr obyvatel (ROB)

Registr obyvatel je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje referenční údaje o fyzických osobách. Správcem Registru obyvatel je Ministerstvo vnitra. Primárními editory jsou jednotlivé OVM prostřednictvím Informačního systému evidence obyvatel a Agendového informačního systému cizinců.

Subjekty údajů vedených v registru obyvatel jsou

  • státní občané České republiky,
  • cizinci, kteří pobývají na území České republiky v rámci trvalého pobytu anebo na základě dlouhodobého víza nebo povolení k dlouhodobému pobytu,
  • občané jiných členských států Evropské unie, občané států, které jsou vázány mezinárodní smlouvou sjednanou s Evropským společenstvím, občané států, které jsou vázány smlouvou o Evropském hospodářském prostoru, a jejich rodinní příslušníci, kteří pobývají na území České republiky v rámci trvalého pobytu nebo kterým byl vydán doklad o přechodném pobytu na území České republiky delším než 3 měsíce,
  • cizinci, kterým byla na území České republiky udělena mezinárodní ochrana formou azylu nebo doplňkové ochrany,
  • jiné fyzické osoby, u nichž jiný právní předpis vyžaduje agendový identifikátor fyzické osoby a stanoví, že tyto fyzické osoby budou vedeny v registru obyvatel.

Referenčními údaji o fyzických osobách jsou:

  • příjmení, rodné příjmení
  • jméno, popřípadě jména,
  • pohlaví,
  • adresa místa pobytu, případně též adresa, na kterou mají být doručovány písemnosti podle jiného právního předpisu; uvedené adresy jsou vedeny ve formě referenční vazby (kódu adresního místa) na referenční údaj o adrese v registru územní identifikace; v případě adresy, na kterou mají být doručovány písemnosti podle jiného právního předpisu, se vede i údaj o identifikaci poštovní přihrádky nebo dodávací schránky nebo adresa, která je mimo území České republiky a které nebyl přidělen kód adresního místa v registru územní identifikace; v případě adresy místa pobytu je tento údaj označen jako adresa úřadu, pokud je stejným způsobem označen v informačním systému evidence obyvatel nebo informačním systému cizinců,
  • datum, místo a okres narození, u subjektu práva, který se narodil v cizině, datum, místo a stát, kde se narodil; údaj o místě a okrese narození na území České republiky se vede ve formě referenční vazby (kódu územního prvku) na referenční údaj v registru územní identifikace,
  • datum, místo a okres úmrtí, jde-li o úmrtí subjektu práva mimo území České republiky, vede se datum úmrtí, místo a stát, na jehož území k úmrtí došlo; je-li vydáno rozhodnutí soudu o prohlášení za mrtvého, vede se den, který je v rozhodnutí uveden jako den smrti, popřípadě jako den, který nepřežil, a datum nabytí právní moci tohoto rozhodnutí; údaj o místě a okrese úmrtí na území České republiky se vede ve formě referenční vazby (kódu územního prvku) na referenční údaj v registru územní identifikace,
  • státní občanství, popřípadě více státních občanství,
  • omezení svéprávnosti,
  • rodinný stav nebo registrované partnerství,
  • čísla a druhy identifikačních dokladů a datum skončení jejich platnosti1),
  • typ datové schránky a identifikátor datové schránky, je-li tato datová schránka zpřístupněna.

O fyzických osobách se v registru obyvatel vedou také údaje, které nejsou referenční:

  • telefonní číslo pro veřejnou mobilní telefonní síť nebo adresa elektronické pošty pro zasílání zvoleného okruhu informací,
  • sériové číslo, vydavatel a platnost kvalifikovaného certifikátu pro elektronický podpis.
  • Bezpečnostní osobní kód, který je pro účely registru obyvatel autentizačním údajem. Vede se v zašifrované podobě a je neveřejný
  • Agendový identifikátor fyzické osoby, který je identifikátorem pro agendu registru obyvatel

V registru obyvatel se dále vedou provozní údaje

  • záznam o využívání údajů z registru obyvatel pro potřeby agendových informačních systémů,
  • záznam o poskytnutí údajů subjektu práva nebo jiné osobě, který obsahuje datum a čas výdeje, identifikátor souhlasu subjektu práva s poskytnutím údajů jiné fyzické nebo právnické osobě a identifikaci toho, kdo údaje poskytl,
  • datum poslední změny každého údaje vedeného v registru obyvatel,
  • záznam o udělení nebo odvolání souhlasu subjektu práva s poskytnutím údajů jiné fyzické nebo právnické osobě.

Editory údajů jsou:

  • U občanů České republiky je editorem Ministerstvo vnitra, které zapisuje údaje prostřednictvím agendového informačního systému evidence obyvatel a agendového informačního systému občanských průkazů a agendového informačního systému cestovních dokladů.
  • U cizinců je editorem Policie České republiky nebo Ministerstvo vnitra, které zapisují údaje prostřednictvím agendového informačního systému cizinců.
  • U datových schránek je editorem Ministerstvo vnitra jako správce Informačního systému datových schránek.
  • Editorem provozních údajů je Správa základních registrů prostřednictvím informačního systému základních registrů
Registr osob (ROS)

Registr osob je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje referenční údaje. Správcem registru osob je Český statistický úřad. Primárními editory jsou orgány a instituce, které již v současnosti mají zákonnou povinnost osoby registrovat. Jedná se o obchodní rejstřík, rejstřík živnostenského podnikání, evidence nebo informační systémy vybraných ministerstev a ústředních orgánů státní správy, profesních komor, obcí, krajů apod. Sekundárním editorem je Ministerstvo vnitra se systém Datových schránek (ISDS).

Subjekty údajů vedených v registru osob jsou:

  • právnická osoba,
  • organizační složka a organizační jednotka právnické osoby,
  • organizační složka státu,
  • vnitřní organizační jednotka organizační složky státu, pokud je této vnitřní organizační jednotce zákonem svěřena vlastní působnost,
  • podnikající fyzická osoba,
  • zahraniční osoba a organizační složka zahraniční osoby,
  • svěřenský fond, pokud jsou zapsány do evidence podle tohoto zákona nebo jiného právního předpisu.

Referenčními údaji o právnických osobách jsou:

  • obchodní firma nebo název nebo označení nebo jméno, popřípadě jména, a příjmení, pokud není podnikající fyzická osoba zapsána do obchodního rejstříku,
  • jméno, popřípadě jména, a příjmení podnikající fyzické osoby nebo zahraniční osobu a organizační složku zahraniční osoby; jde-li o osobu vedenou v registru obyvatel, vede se tento údaj ve formě referenční vazby (agendového identifikátoru fyzické osoby) na referenční údaj v registru obyvatel,
  • agendový identifikátor fyzické osoby pro agendu registru osob,
  • identifikační číslo osoby,
  • datum vzniku nebo datum zápisu do evidence podle jiných právních předpisů,
  • datum zániku nebo datum výmazu z evidence podle jiných právních předpisů,
  • právní forma,
  • typ datové schránky a identifikátor datové schránky, je-li tato datová schránka zpřístupněna,
  • statutární orgán vyjádřený referenční vazbou na registr obyvatel anebo na registr osob nebo údajem o jménu, popřípadě jménech, příjmení a bydlišti u fyzické osoby nebo údajem o názvu a sídle právnické osoby, nevedou-li se tyto osoby v registru obyvatel nebo registru osob,
  • likvidátor vyjádřený referenční vazbou na registr obyvatel nebo na registr osob anebo údajem o jménu, popřípadě jménech, příjmení a bydlišti u fyzické osoby nebo údajem o názvu a sídle právnické osoby, nevedou-li se tyto osoby v registru obyvatel nebo registru osob,
  • opatrovník právnické osoby vyjádřený referenční vazbou na registr obyvatel nebo na registr osob anebo údajem o jménu, popřípadě jménech, příjmení a bydlišti u fyzické osoby nebo údajem o názvu a sídle právnické osoby, nevedou-li se tyto osoby v registru obyvatel nebo registru osob,
  • insolvenční správce vyjádřený referenční vazbou na registr obyvatel nebo na registr osob anebo údajem o jménu, popřípadě jménech, příjmení a bydlišti u fyzické osoby nebo údajem o názvu a sídle právnické osoby, nevedou-li se tyto osoby v registru obyvatel nebo registru osob,
  • nucený správce vyjádřený referenční vazbou na registr obyvatel anebo údajem o jménu, popřípadě jménech, příjmení a bydlišti, nevede-li se tato osoba v registru obyvatel,
  • právní stav,
  • adresa sídla osoby; jde-li o stavební objekt vedený v registru územní identifikace, vede se tento údaj ve formě referenční vazby (kódu adresního místa) na referenční údaj o adrese v registru územní identifikace,
  • datum zahájení provozování činnosti v provozovně,
  • identifikační číslo provozovny,
  • datum ukončení provozování činnosti v provozovně,
  • adresa místa provozovny; jde-li o stavební objekt vedený v registru územní identifikace, vede se tento údaj ve formě referenční vazby (kódu adresního místa) na referenční údaj o adrese v registru územní identifikace,
  • adresa místa pobytu v České republice ve formě referenční vazby (kódu adresního místa) na referenční údaj o adrese v registru územní identifikace, popřípadě bydliště v zahraničí podnikající fyzická osoba, zahraniční osoba a organizační složka zahraniční osoby; jde-li o osoby vedené v registru obyvatel, vede se adresa místa pobytu ve formě referenční vazby (kódu agendového identifikátoru fyzické osoby) na referenční údaj o fyzické osobě v registru obyvatel,
  • přerušení nebo pozastavení činnosti podle jiného právního předpisu; v případě činností, jimž odpovídá jedna agenda, přerušení všech takových činností.

O právnických osobách se v registru osob vedou také údaje, které nejsou referenční:

  • telefonní číslo pro veřejnou mobilní telefonní síť nebo adresa elektronické pošty pro zasílání zvoleného okruhu informací.

V registru osob se dále vedou provozní údaje:

  • kód agendy,
  • identifikační číslo osoby editora,
  • datum prvotního zápisu do registru osob,
  • datum poslední změny údaje vedeného v registru osob,
  • záznam o využívání údajů z registru osob.

Editory údajů jsou:

Název osoby Typ osobyAgendaEditor ROS
Advokáti FO A8 Česká advokátní komora
Agentury práce FO A531 Ministersvo práce a sociálních věcí
Akreditovaná osoba podle zákona o spotřebitelském úvěru FO A11 Česká národní banka
Auditoři FO A6 Komora auditorů České republiky
Auditoři bezpečnosti pozemních komunikací FO A1381 Ministerstvo dopravy
Autorizovaní architekti FO A54 Česká komora architektů
Autorizovaní inženýři a technici FO A54 Česká komora autorizovaných inženýrů a techniků činných ve výstavbě
Církve a náboženské společnosti PO A5 Ministerstvo kultury
Česká národní banka, Česká televize, Český rozhlas, Regionální rada regionu soudržnosti, Všeobecná zdravotní pojišťovna PO A325 Ministerstvo vnitra
Daňoví poradci FO A7 Komora daňových poradců ČR
Dobrovolné svazky obcí PO A343 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Držitelé licencí pro podnikání v energetických odvětvích FO A684 Energetický regulační úřad
Evropská seskupení pro územní spolupráci PO A561 Ministerstvo pro místní rozvoj
Fyzické osoby - provozovatelé poštovních služeb FO A926 Český telekomunikační úřad
Fyzické osoby provozující živnost (živnostníci) FO A121 Místně příslušný živnostenský úřad
Honební polečenstva PO A943 Místně příslušná obec s rozšířenou působností, Ministerstvo zemědělství
Insolvenční správci FO A1901 Ministerstvo spravedlnosti
Investiční zprostředkovatelé FO A11 Česká národní banka
Komunální příspěvkové organizace PO A388 Kraje, obce
Mediátoři FO A1461 Ministerstvo spravedlnosti
Mezinárodní vojenské organizace vzniklé na základě mezinárodní smlouvy PO A5517 Ministerstvo obrany
Nadace a nadační fondy PO A120 Místně příslušný rejstříkový soud
Notáři FO A484 Notářská komora České republiky
Obecně prospěšné společnosti PO A120 Místně příslušný rejstříkový soud
Obchodní společnosti;družstva, org.složky podniku, ostatní osoby zapsané v obchodním rejstříku PO A120 Místně příslušný rejstříkový soud
Odborové organizace a organizace zaměstnavatelů, pobočná odborová organizace a organizace zaměstnavatelů, mezinárodní odborová organizace, mezinárodní organizace zaměstnavatelů, pobočná mezinárodní odborová organizace, pobočná mezinárodní organizace zaměstnavatelů PO A120 Místně příslušný rejstříkový soud
Organizační složky státu PO A325 Ministerstvo vnitra
Osoby nakládající s vysoce rizikovými biologickými agens a toxiny FO A914 Státní úřad pro jadernou bezpečnost
Osoby provádějící hornickou činnost a činnost prováděnou hornickým způsobem FO A4293 Český báňský úřad
Osoby provozující výrobu a distribuci léčiv FO A1243 Státní ústav pro kontrolu léčiv
Osoby s povolením ke směnárenské a devizové činnosti FO A11 Česká národní banka
Osoby využívající jadernou energii a ionizující záření FO A3905 Státní úřad pro jadernou bezpečnost
Patentoví zástupci FO A31 Komora patentových zástupců České republiky
Podnikatelé v elektronických komunikacích FO A304 Český telekomunikační úřad
Pojišťovací zprostředkovatelé FO A11 Česká národní banka
Politické strany a politická hnutí PO A3 Ministerstvo vnitra
Poskytovatelé audiovizuálních mediálních služeb FO A1138 Rada pro rozhlasové a televizní vysílání
Poskytovatelé platebních služeb malého rozsahu FO A11 Česká národní banka
Poskytovatelé služeb zdravotní péče FO A1086 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Poskytovatelé sociálních služeb FO A530 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Provozovatelé leteckých prací a provozovatelé letišť FO A575 Úřad pro civilní letectví
Provozovatelé odborných veterinárních činností FO A1044 Státní veterinární správa
Provozovatelé rozhlasového a televizního vysílání FO A453 Rada pro rozhlasové a televizní vysílání
Provozovatelé stanic měření emisí FO A998 Místně příslušná obec s rozšířenou působností
Provozovatelé stanic technické kontroly FO A998 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Provozovatelé zoologické zahrady FO A696 Ministerstvo životního prostředí
Restaurátoři FO A434 Ministerstvo kultury
Samostatní likvidátoři pojistných událostí FO A11 Česká národní banka
Samostatný zprostředkovatel spotřebitelského úvěru FO A11 Česká národní banka
Soudní exekutoři FO A479 Exekutorská komora České republiky
Soudní znalci a tlumočníci FO A481 krajské soudy, městský soud Praha
Společenství vlastníků jednotek PO A120 Místně příslušný rejstříkový soud
Spolky (býv. občanská sdružení), pobočné spolky (býv. organizační jednotka občanského sdružení) PO A120 Místně příslušný rejstříkový soud
Státní fondy PO A325 Ministerstvo vnitra
Státní příspěvkové organizace PO A24 Ministerstva a další ústřední správní úřady
Svěřenské fondy PO A4047 Místně příslušný rejstříkový soud
Školské právnické osoby PO A676 Ministerstvo školství, mládeže a tělovýchovy
Ústav PO A120 Místně příslušný rejstříkový soud
Vázaný zástupce dle zákona o spotřebitelském úvěru FO A11 Česká národní banka
Veřejné a státní vysoké školy PO A325 Ministerstvo vnitra
Veřejné výzkumné instituce PO A4 Ministerstvo školství, mládeže a tělovýchovy
Veřejnoprávní korporace – kraj, obec, hlavní město Praha PO A325 Ministerstvo vnitra
Veterinární lékaři oprávnění k výkonu veterinární léčebné a preventivní činnosti FO A636 Komora veterinárních lékařů České republiky
Zahraniční právnická osoba, odštěpný závod zahraniční právnické osoby, odštěpný závod zahraniční fyzické osoby PO A120 Místně příslušný rejstříkový soud
Zahraniční spolek, zahraniční poboční spolek PO A120 Místně příslušný rejstříkový soud
Zájmové sdružení právnických osob PO A120 Místně příslušný rejstříkový soud
Zastoupení zahraniční banky PO A11 Česká národní banka
Zemědělský podnikatelé FO A944 Ministerstvo zemědělství
Zprostředkovatel vázaného spotřebitelského úvěru FO A11 Česká národní banka
Zvláštní organizace pro zastoupení zájmů ČR v mezinárodních nevládních organizacích, organizační jednotka zvláštní organizace pro zastoupení českých zájmů v mezinárodních nevládních organizacích, mezinárodní nevládní organizace, organizační jednotka mezinárodní nevládní organizacePO A120 Místně příslušný rejstříkový soud

U nereferenčních údajů je editorem Český statistický úřad.

Registr územní identifikace adres a nemovitostí (RÚIAN)

Registr územní identifikace adres a nemovitostí je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje základní územní prvky a adresy. Správcem registru územní identifikace je Český úřad zeměměřický a katastrální. Primárními editory jsou katastrální úřady, prostřednictvím informačního systému katastru nemovitostí, stavební úřady prostřednictvím informačního systému územní identifikace, obce a Český statistický úřad.

Registr územní identifikace obsahuje údaje o těchto základních územních prvcích:

  • území státu,
  • území regionu soudržnosti podle jiného právního předpisu,
  • území vyššího územního samosprávného celku,
  • území kraje,
  • území okresu,
  • správní obvod obce s rozšířenou působností,
  • správní obvod obce s pověřeným obecním úřadem,
  • území obce,
  • území vojenského újezdu,
  • správní obvod v hlavním městě Praze,
  • území městského obvodu v hlavním městě Praze,
  • území městské části v hlavním městě Praze,
  • území městského obvodu a městské části územně členěného statutárního města,
  • katastrální území,
  • území základní sídelní jednotky,
  • stavební objekt,
  • adresní místo,
  • pozemek v podobě parcely

Registr územní identifikace obsahuje též údaje o účelových územních prvcích, pomocí kterých je vyjádřeno území jiným právním předpisem, pokud jiný právní předpis stanoví, že se tyto údaje do registru územní identifikace zapisují, a pokud tyto účelové územní prvky jsou bezezbytku skladebné alespoň z některých základních územních prvků.

Registr územní identifikace dále obsahuje údaje o těchto územně evidenčních jednotkách

  • část obce
  • ulice nebo jiné veřejné prostranství

Referenčními údaji v registru územní identifikace jsou:

  • identifikační údaje,
  • údaje o vazbách na ostatní územní prvky, případně na územně evidenční jednotky,
  • údaje o druhu a způsobu využití pozemku a jeho technickoekonomické atributy,
  • údaje o typu a způsobu využití stavebního objektu,
  • údaje o typu a způsobu ochrany nemovitosti,
  • adresy,
  • lokalizační údaje katastrálních území a nadřazených prvků,
  • lokalizační údaje územních prvků a územně evidenčních jednotek – pouze v těch katastrálních územích, ve kterých je katastrální mapa vedena v digitální formě.
Registr práv a povinností (RPP)

Registr práv a povinností spravuje Ministerstvo vnitra a obsahuje informace pro řízení přístupu k údajům ostatních základních registrů; zároveň v tomto registru vzniká základní přehled o agendách, které orgány veřejné moci provádějí; o občanech a právnických osobách jsou v tomto registru vedeny informace o rozhodnutích, která vedla ke změně údajů v základních registrech. Dále RPP slouží jako zdroj informací pro ISZR při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. To znamená, že kdykoliv se daný subjekt pokusí získat určitý údaj, nebo ho dokonce změnit (editovat), systém posuzuje, zda subjektu bude dovolené na základě zákonného zmocnění pracovat s údaji poskytované veřejnou správou a tím se stává RPP významnou komponentou ZR v rámci koncepce využití propojeného datového fondu a sdílení údajů napříč nejen státní správou pro řízení výkonu veřejné správy. RPP obsahuje zejména:

  • Agendy veřejné správy a jejich povinnosti
  • Seznam Orgánů veřejné moci a soukromoprávních uživatelů údajů ze základních registrů
  • Mapu působnosti orgánů veřejné moci v rámci agendového modelu
  • Údaje o údajích vedených v agendách a o jejich poskytování a využívání
  • Údaje o oprávněních orgánů veřejné moci a soukromoprávních uživatelů k přístupu k údajům ze základních registrů a agendových informačních systémů
  • Rozhodnutí, na základě kterých se mění referenční údaje v Registru obyvatel a Registru osob
  • Seznam informačních systémů veřejné správy a jejich vazba na agendy a údaje v nich vedené

Součástí RPP je i technická struktura údajů, jejichž popis je stanoven vyhláškou k zákonu 111/2009 Sb. Důležitým z pohledu rozvoje je přidání odkazu na číselník, tedy datovou sadu publikovanou ve veřejném datovém fondu v rámci Národního katalogu otevřených dat.

  • Číselník: Odkaz na datovou sadu reprezentující číselník zveřejněný v Národním katalogu otevřených dat dle pravidel Veřejného datového fondu. Pokud údaj v agendě vzniká, jedná se o odkaz, který říká, že údaj je zdrojem číselníku, pokud se jedná o přebíraný údaj, jedná se o odkaz na číselník publikovaný jiným subjektem.

Správcem Registru práv a povinností je Ministerstvo vnitra, primárními editory jsou ohlašovatelé agend veřejné správy.

V RPP jsou vedeny základní elementy pro agendový model veřejné správy. Dále je zde mapa sdílitelných údajů jednotlivých agend a technické údaje o údajích vedených v rámci jednotlivých agend a oprávnění k přístupu k údajům.

Další součástí RPP je evidence informačních systémů veřejné správy, jejich vazba na agendy, údaje o jejich správcích, apod.

Metodika pro evidenci služeb VS, jejich úkonů a plánu digitalizace je uvedena zde.

Klíčové role v souvislosti se základními registry

V souvislosti s využíváním základních registrů jsou definovány následující role a takto se o nich hovoří i v tomto dokumentu:

Role Popis a význam Příklady
Správce základního registru Orgán veřejné moci, který spravuje příslušný základní registr U ROB a RPP je to MV, u ROS je to ČSÚ, u RÚIAN je to ČÚZK
Editor referenčních údajů Orgán veřejné moci, který ze zákona provádí editaci a zápis referenčních údajů, a tedy zodpovídá za jejich správnost a je povinen řešit reklamace a aktualizace údajů U ROB je to Ministerstvo vnitra (třeba prostřednictvím ohlašoven a matrik), u ROS a RÚIAN jsou to jednotlivá agendová místa dle příslušných zákonů
Uživatel referenčních údajů (čtenář) Orgán veřejné moci, nebo soukromoprávní uživatel, který je na základě zmocnění povinen či oprávněn využívat referenční údaje a za tímto účelem přistupuje k ZR Jednotlivé OVM působící v agendách, správci AISů, samy subjekty údajů
Subjekt práva Konkrétní fyzická nebo právnická osoba, o níž jsou vedeny v registrech údaje každá fyzická nebo právnická osoba pro svoje údaje. Právnická osoba je vždy spjata s fyzickou osobou.
Ohlašovatel agendy Ohlašovatel agendy vedené v RPP (viz Agendový model veřejné správy) U agendy matrik Ministerstvo vnitra, u agendy zdravotních služeb Ministerstvo zdravotnictví, u agendy důchodů MPSV
Orgán působící v agendě Orgán veřejné moci, který ze zákona vykonává působnost v agendě (viz Agendový model veřejné správy) V agendě matrik jednotlivé obecní úřady, v agendách sociálních dávek třeba Úřad práce a ORP, v agendách stavebního zákona MMR a jednotlivé stavební úřady.

Referenční údaje

Referenční údaje jsou údaje vedené v základním registru, které jsou označené jako referenční. Platí obecná právní a procesní premisa, že referenční údaje jsou při výkonu veřejné správy považovány za platné, pokud se neprokáže opak, nebo pokud nejsou příslušným editorem označeny za zpochybněné.

Platí tedy, že veřejná správa musí jednat na základě těchto referenčních údajů a naopak, že jedná-li veřejná správa na základě těchto referenčních údajů, nemůže dojít k nesprávnému úřednímu postupu díky nesouladu se skutečností.

Zápis a editace referenčních údajů

Za editaci a zápis referenčních údajů zodpovídá vždy příslušný editor. Platí přitom, že rozlišení zodpovědnosti editora není po subjektu, ale i po jednotlivých údajích. Nastává i situace, kdy není u jednoho subjektu editor jen jeden, ale vícero. V takovém případě se editoři dělí na primární a sekundární. Primární editor je zodpovědný za samotnou existenci celého záznamu (včetně vytvoření, aktualizaci a smazání), kdežto sekundární pouze za jednotlivé údaje o subjektu (včetně jejich aktualizací). Typickým příkladem situace primárního a sekundárního editora jsou právnické osoby, kde za založení a evidenci příslušných základních údajů zodpovídá příslušný primární editor (rejstříkový soud, krajský úřad, živnostenský odbor obce apod.) a za doplňkové údaje např. o datové schránce zodpovídá sekundární editor (Ministerstvo vnitra jako správce ISDS). Sekundární editor tedy nemůže subjekt založit ani zrušit, pouze ho doplňuje o další údaje.

Základní povinnosti editora tedy jsou:

  • Zapisovat a editovat údaje na základě procesního výkonu agendy, který stanoví, zda k výkonu existuje dokumentů evidovaný ve spisové službě
  • Řešit proces reklamace, včetně zpochybnění správnosti údajů od správce základního registru, editora samotného nebo kteréhokoliv orgánu veřejné moci
  • Řešit správnost a aktuálnost údajů

Dokumenty, na základě kterých editor vykonával své povinnosti se musí řídit povinnostmi spisové služby.

Virtuální referenční údaje

Virtuální referenční údaje jsou takové údaje, které vznikají odvozením, sloučením či jinou úpravou již existujících referenčních údajů. Tyto údaje tedy nesplňují některé požadavky na klasické referenční údaje jako je zodpovědnost konkrétního editora. Virtuální referenční údaje mají své označení, svoji definici i popsaný postup jak vznikají v každé konkrétní službě, která je může poskytnout. Typickým příkladem může být virtuální referenční údaje „celé jméno“, které se složí z referenčních údajů „jméno, případně jména“ a „příjmení“. Další takové virtuální údaje mohou být:

  • Věk
  • Jméno bez diakritiky
  • Adresa pouze velkými písmeny – uppercase
  • Počet dní do expirace identifikačního dokladu
  • Telefonní číslo v mezinárodním formátu
  • Apod.

Virtuální referenční údaje nemusí být explicitně zmíněny v zákoně jako obsah konkrétního základního registru, protože vznikají a zanikají s voláním dané služby ISZR nebo ISSS. Jsou tedy pouze obsahem popisu služby.

V současné době nedisponuje žádná služba ISZR nebo ISSS možností poskytnutí virtuálního referenčního údaje. S touto funkcionalitou se počítá v rámci rozvoje PPDF.

Údaje typu indikátor

Indikátor je referenční údaj vedený v základním registru, který slouží k informaci, že o subjektu jsou vedeny potenciálně důležité údaje v jiných informačních systémech. Smyslem údajů typu indikátor je předejít zbytečným dotazům do informačních systémů v případech, kdy v nich taková informace vedena není.

Za povolenou množinu indikátorů, včetně jejich názvů, zodpovídá správce základního registru.

Editorem údaje typu indikátor je správce informačního systému, který vede indikované údaje a do základního registru jsou zapisovány stejně jako údaje referenční, tedy automatickými procesy. Indikátor může být i virtuálním údajem základního registru a k jednomu subjektu se může vztahovat více indikátorů.

Údaj typu indikátor má základní atributy:

  • název – jednoznačný název indikátoru, příklad: COVID-19,
  • identifikátor AIS + identifikátor agendy,
  • nepovinný identifikátor kontextu, v rámci něhož lze získat přes ISSS detailní data,
  • Nečíslovaný seznam nepovinný kód upřesnění,
  • nepovinné textové upřesnění.

Údaj typu indikátor obsahuje další standardní atributy:

  • datum a čas počátku platnosti,
  • datum a čas konce platnosti,
  • datum a čas prvotního zápisu,
  • datum a čas poslední změny,
  • stav (S, N, X, F).

V současné době nedisponuje žádná služba ISZR nebo ISSS možností poskytnutí indikátoru. S touto funkcionalitou se počítá v rámci rozvoje PPDF, kdy pro zavedení těchto údajů vyžadují následující úpravy:

  • Do AutorizaceInfo přidat textovou položku SeznamIndikatoru, typ řetězec, a struktury pro zápis a čtení. Do SeznamIndikatoru se zadávají jména příznaků, které se mají vrátit/zapsat. Je to ekvivalent SeznamUdaju a ISZR kontroluje, že dotazující se AIS má na konkrétní indikátor oprávnění jej číst nebo zapisovat.
  • Přístup k údajům typu indikátor je řízen standardním způsobem registrem práv a povinností. Uživatel (OVM, agenda, činnostní role) musí mít povolen přístup k indikátoru s daným názvem.
  • Přidání nového indikátoru nesmí vyžadovat úpravy XSD, nebo dokonce nové ohlášení agendy, aby bylo maximálně operativní.
Proces reklamace správnosti údaje

Proces reklamace správnosti údaje může spustit kdokoliv, kdo má pochybnosti o správnosti údaje. Samotný proces následně řeší vždy primární zdroj údaje – tedy jeho editor. Proces začíná přijetím zprávy, která obsahuje pochybnosti o správnosti údaje (od jiného OVM, subjektu práva, správce registru, apod.). Editor je v tomto povinen označit daný údaj jako zpochybněný. Následně editor údaje musí provést ověření jeho správnosti, což může vyústit v uzavření reklamace jako neoprávněné (a tedy zachování hodnoty údaje) nebo oprávněné (a tedy změnou na správnou hodnotu). Současně s uzavřením reklamace odstraní z údaje pochybnost. Samotný proces reklamace se řídí správním řádem.

Využívání referenčních údajů

Každý orgán veřejné moci je v rozsahu stanoveném mu působností v jednotlivých agendách povinen využívat referenční údaje ze základních registrů. Postupuje přitom tak, že buď využívá služeb ISZR a napojuje svoje agendové informační systémy, nebo využívá některý z jiných nástrojů Referenčního rozhraní.

Základními povinnostmi OVM a SPUÚ užívajících údaje tedy jsou:

  • Využívat v agendách referenční údaje
  • Využívat aktuální referenční údaje, což lze zajistit jedním ze dvou následujících, vždy však v souladu s provozní dokumentací ISZR:
    1. Využíváním mechanismu notifikací o změnách referenčních údajů a následné aktualizace , nebo
    2. dotazováním se při každé transakci do základních registrů.
  • Pokud zjistí nesoulad referenčních údajů se skutečností, realizovat reklamaci údajů vůči editorovi údajů
  • Nevyžadovat údaje vedené v registrech od subjektu práva

Editorské AIS

Systémy jejichž údaje jsou publikované kompozitními službami ISZR. Kompozitními službami se rozumí služby ISZR, které poskytují údaje vedené v editorských systémech ZR s vazbou na referenční údaje vedené v ZR:

  • Evidence obyvatel - AISEO (Správcem je Ministerstvo vnitra ČR)
  • Agendový informační systém cizinců - AISC(Správcem je Policie ČR)
  • Evidence cestovních dokladů - AIESCD (Správcem je Ministerstvo vnitra ČR)
  • Evidence občanských průkazů - AISEOP (Správcem je Ministerstvo vnitra ČR)
  • Informační systém katastru nemovitostí – ISKN (Správcem je Český úřad zeměměřický a katastrální)
  • Informační systém územní identifikace - ISÚI (Správcem je Český úřad zeměměřický a katastrální)
  • AIS Působnostní – AISP (Správcem je Ministerstvo vnitra ČR)
  • eIdentita – (správcem je Ministerstvo vnitra ČR)

Každý ZR má své editory, kteří editují údaje. Editoři zapisují údaje do jednotlivých ZR a společně s věcným správcem každého z editorů se tím udržují údaje v ZR správné a aktuální. Pro aktuálnost a správnost se využívá mechanizmu reklamace údajů. Editoři editují údaje v ZR pomocí svých editačních informačních systémů na základě procesního výkonu agendy, který stanoví, zda k výkonu existuje dokumentů evidovaný ve spisové službě nebo samostatných evidencí dokumentů v souladu s právními předpisy.

Čtenář může čerpat nereferenční údaje formou tzv. kompozitních služeb. Jelikož v ZR se nacházejí pouze údaje k aktuálnímu stavu, které jsou správné a garantované státem (kromě údajů nereferenčních vedených v základních registrech), v rámci kompozitních služeb je možné získat z editačních systémů editorů ostatní nereferenční údaje (např. historické údaje o subjektu práva nebo další užitečné údaje, které se v ZR nenachází).

Informace o kompozitních službách jsou k dispozici na stránkách SZR.

eGovernment Service Bus / Informační systém sdílené služby

eGovernment On-Line Service Bus (eGSB), dle legislativního znění také Informační systém sdílené služby (ISSS), je unifikované rozhraní pro sdílení údajů mezi jednotlivými informačními systémy veřejné správy. Je součást referenčního rozhraní umožňující jednotlivým AIS čerpat a publikovat údaje vedené o jednotlivých subjektech práva. Pokud agenda dle zákona vede svou evidenci údajů, má povinnost publikovat svoje údaje jiným agendám skrze eGSB / ISSS, jakožto bezpečným, standardním a dokumentovaným rozhraním pro oprávněné čtenáře. Spravuje a provozuje jej Správa základních registrů. Rozhraní eGSB / ISSS umožňuje:

  • Publikovat služby pro sdílení údajů týkajících se konkrétních subjektů a objektů práva
  • Využívat sdílení údajů na základě publikovaných služeb
  • Překlad agendových identifikátorů fyzických osob, u nichž jsou vyměňovány údaje mezi jednotlivými agendami (překlad AIFO)
  • Výměnu datových souborů s údaji o subjektech na základě pseudonymizovaných identifikátorů ve vazbě na přeložené AIFO identifikátory
  • Poskytování služeb reklamace, notifikace a aktualizace údajů poskytovaných službami AIS
  • Zajištění nezávislého auditu výměny údajů (ukládá informace identifikující dotaz a odpověď a technický kryptografický otisk zprávy – hash)

Cílem je, aby klienti veřejné správy nebyli nuceni dokládat skutečnosti, o kterých veřejná správa již ví, či které vznikly dokonce na základě rozhodnutí veřejné správy. Většina skutečností potřebných pro rozhodování veřejné správy je již někde evidována, a to formou údajů v informačních systémech veřejné správy. Dále existují skutečnosti, které sice jsou na základě rozhodování veřejné správy, nicméně nejsou dosud vedeny v AIS jako údaje (příkladem je potvrzení o studiu, dohoda o chráněné dílně apod.). Zmapováním údajů v jednotlivých agendách, které probíhá nyní v rámci nových povinností ohlašovatelů vůči RPP je postupně zjištěna základní mapa údajů evidovaných, vyžadovaných a poskytovaných v rámci jednotlivých agend a to, kde a jakým způsobem jsou evidovány a v jakém AIS. Tím, jak již bylo popsáno výše, vznikne základní datová mapa veřejné správy, a je tedy možné ji zanalyzovat a identifikovat ty údaje a skutečnosti, které jsou používány ve více agendách

Na referenčních údajích vedených v základních registrech je ověřena funkčnost principu, kdy tyto údaje a jejich změny klient nemusí dokládat, ale celá veřejná správa si tyto údaje získává prostřednictvím služeb ISZR a na základě nich pak rozhoduje. Princip sdílení údajů skrze eGSB / ISSS je pouze rozšířením tohoto funkčního celku i o další údaje.

Pro využívání eGSB / ISSS jsou definovány dvě hlavní role:

Role Popis Co zajišťuje
Publikátor (poskytovatel) Správce ISVS, ze kterého se poskytují údaje Služby publikující údaje prostřednictvím eGSB / ISSS, vychází se z agendy poskytující údaje z daného AIS
Čtenář (uživatel) OVM získávající údaje z jiné agendy na základě svého oprávnění v RPP Napojení na eGSB / ISSS a volání služeb publikátora (i více AIS dané agendy), využívá se překladu AIFO z agendy poskytovatele, čtenář volá podle AIFO své agendy v případě fyzické osoby. Pro právnickou osobu se žádný překlad nevyužívá.

V souvislosti se sdílením údajů prostřednictvím eGSB / ISSS platí následující aspekty:

  • Údaje jsou ohlášeny v registru práv a povinností jako údaje, které agenda zpracovává na základě zákonného zmocnění
  • Údaj musí být vedený v AIS
  • U údaje je jasné, jak vznikl, kdo je zodpovědný za jeho zápis, změny a správu, v jakém AIS je veden a jakým způsobem může být změněn či zrušen.
  • Poskytovatelem údaje je vždy správce AIS, v němž je údaj veden a evidován.
  • Údaj je vždy vázán na subjekt práva, či objekt práva v ZR.
  • Bude umožněno subjektu práva si pořídit výpis údajů jako výpis z informačního systému veřejné správy.

Protože cílem je efektivní a zároveň účelné propojování údajů především za účelem omezování nutnosti klienta dokládat skutečnosti, budou údaje moci být orgánem veřejné moci získávány:

  1. na základě souhlasu subjektu práva (jménem subjektu práva), nebo
  2. na základě zákonného zmocnění vedení údajů v agendě s označením čerpání v RPP (z moci úřední)

Informace k informačnímu systému sdílení údajů jsou k dispozici na stránkách MV.

Kontext eGSB / ISSS

Každá agenda je vymezena příslušnými právními předpisy. V rámci agendy se pak o subjektech a objektech vedou údaje potřebné a specifické pro její výkon. Tyto údaje je možné evidovat také jen na základě příslušných ustanovení právních předpisů. O subjektech a objektech se jedná v rámci určité agendy v určitých souvislostech (daných právními předpisy), tedy subjekty a objekty jsou v rámci výkonu této agendy chápany v určitém „kontextu“. Tyto kontexty se při výkonu různých agend liší, což se mimo jiné projevuje tím, že se v rámci různých agend jedná o jiných objektech ve vztahu k subjektům a o subjektech a objektech se evidují a případně vyměňují různé údaje. Můžeme tedy říci, že kontext:

  • určuje právní postavení entity (subjektu nebo objektu) v rámci agend a
  • jsou s ním spojené specifické údaje (atributy) entity definované v dané agendě.

Metodiky k tvorbě kontextů řeší detailnější postup

Metodika tvorby kontextů zavádí dvě roviny kontextu – technickou a konceptuální. Technická rovina kontextu je tvořena XSD schématem, které definuje syntaxi XML zpráv, ve kterých jsou vyjádřeny sdílené údaje. Pro využívání služeb eGSB/ISSS pro propojený datový fond je nutno znát zejména:

  • Agendu, ze které chce čtenář údaje využívat,
  • Agendu, kterou čtenář provádí a v níž údaje čte,
  • Kontext pro dotazování na údaje z publikujícího AIS.

Před využitím eGSB/ISSS si musí čtenář nejprve zjistit kontext a jeho XSD schéma, podle kterého bude dostávat odpovědi na dotazy ve službách eGSB/ISSS. Proto si nejdříve musí zavolat zvláštní službu eGSB/ISSS pro čtení Katalogu kontextů, ve kterém pak zjistí, jaký kontext musí volat, aby mohl získat údaje z poskytující agendy.

Konceptuální modely kontextů

Konceptuální rovina kontextu je tvořena konceptuálním modelem, který definuje sémantiku (význam) kontextu popisem jeho sémantických (významových) vazeb na ostatní kontexty vedené v rámci téže agendy, ale i v jiných agendách a popisem jeho sémantických vazeb na ontologii veřejné správy. Ontologie veřejné správy definuje základní pojmy veřejné správy, které existují napříč právním řádem ČR, a sémantické vazby mezi nimi. Příkladem takových pojmů jsou subjekt práva, objekt práva, fyzická osoba, právnická osoba, apod.

Ambicí konceptuálního modelu kontextu není modelovat reálný svět, ale jeho abstrakci popisující subjekty a objekty údajů, údaje o nich a vztahy mezi nimi tak, jak jsou definovány v legislativě a jak jsou chápány v dané agendě. Konceptuální model je odvozen z obecných významů definovaných v ontologii veřejné správy, ty přebírá, specializuje a rozšiřuje a v případě potřeby také redefinuje. Prvky konceptuálního modelu jsou propojeny na odpovídající legislativní ustanovení, ze kterých vyplývají. Protože je konceptuální model kontextu provázán na konceptuální modely souvisejících kontextů a na ontologii veřejné správy, je sám o sobě ontologií. Soubor konceptuálních modelů všech kontextů pak tvoří ontologii popisující

  • subjekty a objekty práva,
  • kontexty, ve kterých existují,
  • údaje, které jsou o nich v kontextech vedeny
  • vzájemné sémantické souvislosti

Tím tvoří konceptuální sémantickou mapu údajů vedených veřejnou správou.

Seznam kontextů

Aktuální seznam kontextů je dostupný na adrese https://egsbkatalog.cms2.cz/

KódNázev
A1046.1 Vlastník ŘP
A1046.RidicRozsirene Řidič - rozšířené údaje
A1046.RidicZakladni Řidič - základní údaje
A1046.RidicZakladni Řidič - základní údaje
A1061.1 NBU Avizace
A121.1 Přehled o údajích autentizované osoby
A121.2 Výpis údajů podnikatelského subjektu
A124.1 ISKN - Evidence práv pro osobu
A124.2 ISKN - List vlastnictví
A3726.1 Pacient
A4003.1 Poskytovatelé zdravotních služeb
A4003.2 Zdravotnická dokumentace pacienta
A418.1 Osoba v pátrání
A418.2 Vozidlo v pátrání
A418.3 NBU Lustrace
A483.1 Výpis údajů z Rejstříku trestů
Pohled na propojení integračních platforem

Rozhraní IS pro dávkovou výměnu údajů

Formulářový AIS (FAIS) je komponentou ISZR, který prostřednictvím speciálních formulářově orientovaných služeb umožňuje požádat o výdej více údajů ze základních registrů a následně zprostředkuje dávkové vydání těchto hromadných údajů prostřednictvím datové schránky. Využívá se pro případy, kdy je stanoveno zákonným zmocněním, že se využívají referenční údaje ve skupinách více subjektů. Takovým případem jsou například výdeje voličských seznamů.

FAIS dále slouží k vyřizování výdeje údajů ze základních registrů formou formulářových žádostí do datové schránky SZR a odpovědí do datové schránky žadatele. Takovým způsobem se kupříkladu vyřizují žádosti o výpisy údajů, přehledy o využití údajů apod. FAIS má rozhraní na spisovou službu dle Národního standardu pro elektronické systémy spisové služby

FAIS tedy poskytuje mimo jiné:

  • Voličské seznamy poskytované volebním orgánům obcí
  • Výdej hromadných dávek údajů podle oprávnění v příslušné agendě
  • Vyřízení žádosti subjektu práva o výpis údajů ze systémů připojených na referenční rozhraní, tedy celého PPDF
  • Sestavování přehledu výpisu využití údajů zasílaného do datové schránky subjektu práva

FAIS funguje podle následujících bodů:

  1. Žadatelem je sestavena žádost o výdej údajů, a ta je odeslána jako formulář do datové schránky SZR
  2. FAIS jako komponenta ISZR si vyzvedne datovou zprávu s formulářem žádosti a zpracuje žádost, přitom ověří oprávnění k údajům a výdej jednotlivých údajů
  3. FAIS po využití služeb ISZR sestaví odpověď, a tu v daném formátu zašle zpět do datové schránky žadatele.

FAIS není primárně určen k využití agendovými informačními systémy, ale ke zpracování formulářových žádostí ověřených identitou odesílatele žádosti prostřednictvím jeho datové schránky. Pro využití výdeje údajů ze základních registrů slouží agendovým informačním systémům Služby vnějšího rozhraní ISZR.

FAIS bude zajišťovat odpovídající proces výdeje údajů prostřednictvím datových schránek pro veškeré údaje publikované na PPDF.

Univerzální kontaktní místo veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Univerzální kontaktní místa představují obslužné kanály, tj. místa a prostředky, kterými klienti veřejné správy mohou realizovat služby veřejné správy, bez ohledu na věcnou a místní příslušnost služby a služebního úřadu, a to jak samoobslužné (Portál občana jako součást Portálu veřejné správy), tak asistované. Asistovaná kontaktní místa se dále dělí na specializovaná a univerzální, a to především z důvodu komplexity a náročnosti některých služeb, které vyžadují vysoce kvalifikovaný personál, který není možné zaručit pro univerzální kontaktní místa.

Při rostoucí elektronizaci služeb klientům bude nezbytným dalším univerzálním kontaktním místem také multikanálové (hlas, mail, chat, SMS, …) kontaktní centrum / Call-centrum, primárně určené na podporu uživatelů samoobslužných elektronických kanálů.

Kromě univerzální kontaktních míst existují i specializovaná kontaktní místa, opět v rozlišení na samoobslužná a asistovaná. Jejich úkolem je poskytnout služby VS přesahující rozsahem nebo složitostí možnosti univerzálních kontaktních míst.

Samoobslužná univerzální kontaktní místa

Samoobslužná kontaktní místa mají za svůj cíl omezit přímý kontakt klienta veřejné správy s úřady veřejné správy. Pro splnění tohoto cíle musí splnit podmínky uživatelské přívětivosti a zajistit, že samoobslužná alternativa služby je rovnocenná asistované verzi. Ministerstvo vnitra ČR vybudovalo a provozuje důležité systémy a služby, bez kterých by samoobslužná kontaktní místa nemohla fungovat či by jejich potenciál nemohl být naplněn jako např. Portál občana, Národní identitní autoritu nebo Centrální místo služeb. Samooblužné univerzální kontaktní místo může narozdíl od asistovaného univerzálního kontaktního místa obsahovat i služby, které jsou vysoce specializované, protože jde o vůli klienta využít službu a je si vědom všech na něj kladených požadavků. Samoobslužné univerzální kontaktní místo vždy klientovi poskytne dostatek informací a návodů, jak danou službu správně využít. V rámci všech poskytovaných služeb se plánuje rozvoj, který se zaměřuje na rozšíření dostupných služeb či zajištění bezodstávkového režimu 24x7.

Samoobslužná specializovaná kontaktní místa

Specializovaná samoobslužná kontaktní místa slouží pro případy, kdy je vyřešení služeb na univerzálním samooblužném místě nepřiměřeně náročné pro jeho správu a údržbu. Klienti však stále musí mít možnost využít služeb samoobslužných kontaktních míst. Jedná se ve většině případů o specializovaný agendový portál.

Asistovaná univerzální kontaktní místa

Ministerstvo vnitra ČR vybudovalo Czech POINT (zkratka pro Český Podací Ověřovací Informační Národní Terminál), jakožto součást Asistovaného univerzálního kontaktního místa s cílem vytvořit univerzální podatelnu, ověřovací místo a informační centrum, kde by bylo možné na jednom místě získat veškeré údaje, opisy a výpisy, které jsou vedeny v centrálních veřejných evidencích a registrech, jakož i v centrálních neveřejných evidencích a registrech ke své osobě, věcem a právům. Místo, kde je dále možné ověřit dokumenty, listiny, podpisy a také elektronickou podobu dokumentů a učinit podání ke kterémukoli úřadu veřejné správy. Hlavní služby tedy jsou:

  • Služba autorizovaného výpisu z informačního systému veřejné správy
  • Služba autorizovaného podání do informačního systému veřejné správy
  • Služba autorizované konverze dokumentů

Aktuálně lze na pracovištích Czech POINT získat například výpis z katastru nemovitostí, obchodního rejstříku či rejstříku trestů. Kompletní seznam služeb je zveřejněn zde https://www.czechpoint.cz/public/verejnost/sluzby/.

Asistovaná kontaktní místa Czech POINT budou rozvíjena v následujících letech do té míry, že jejich prostřednictvím bude možné učinit podobný rozsah podání, získat podobný rozsah údajů a informace o průběhu řízení ve všech věcech, které stát k jeho osobě vede, jaká budou nabízet samoobslužná kontaktní místa. Není však reálné, že by asistované univerzální kontaktní místo někdy obsáhlo veškeré služby a informace, které lze získat samoobslužně či na specializovaném kontaktním místě. Důvodem je vysoká míra specializace některých služeb (např. daňové přiznání), které zabraňují tomu, aby všechny služby dokázal asistovaně zprostředkovat člověk na univerzálním kontaktním místě.

V plánu je rovněž využití kontaktních míst Czech POINT pro podání žádosti o vydání různých typů dokladů, přičemž nepravděpodobněji půjde v první fázi o tzv. profesní průkaz.

Služby CzechPOINT
Kategorie služby Název služby Poskytovatel služby Obsah služby Cílová skupina služby Co je potřeba k využití služby Poplatky Legislativa
Výpisy z informačních systémů veřejné správy Vydání ověřeného výstupu ze Seznamu kvalifikovaných dodavatelů Ministerstvo pro místní rozvoj Seznam kvalifikovaných dodavatelů je veden Ministerstvem místního rozvoje jako součást Informačního systému o veřejných zakázkách. Ministerstvo místního rozvoje do seznamu zapisuje dodavatele, kteří splnili kvalifikaci podle zákona č. 134/2016 Sb., o zadávání veřejných zakázek, splnění kvalifikace doložili ministerstvu příslušnými doklady a zaplatili správní poplatek. Tato služba je především určena firmám a dodavatelům, kteří mají zájem se ucházet o veřejné zakázky. Výpisem ze Seznamu kvalifikovaných dodavatelů tak může dodavatel v zadávacím řízení nahradit doklady prokazující splnění základních a profesních kvalifikačních kritérií. Zadavatel je povinen výpis ze seznamu uznat, není-li starší více než 3 měsíce. Jde o veřejný rejstřík, požádat o výstup může kdokoliv.Pro získání výstupu ze Seznamu kvalifikovaných dodavatelů je nutné znát pouze identifikační číslo organizace. Vydání první strany výpisu je zpoplatněno částkou, jejíž maximální výše je zákonem omezena na 100,- Kč; každá další strana výpisu je zpoplatněna částkou, jejíž maximální výše je zákonem omezena na 50,- Kč. zákon č. 37/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z bodového hodnocení řidiče Ministerstvo dopravy Tato služba umožňuje občanům zjistit na kontaktním místě veřejné správy stav trestných bodů (bez bodů ve správním řízení). Výpis je poskytován z Centrálního registru řidičů vedeného Ministerstvem dopravy, jehož součástí je právě i evidence bodového hodnocení. Tento výpis má pouze informativní charakter pro občany, nenahrazuje výpis z karty řidiče pro styk s úřady. Vydávání výpisů o trestných bodech řidičů kontaktními místy veřejné správy je upraveno zákonem č. 480/2008 Sb. O výpis může zažádat pouze žadatel sám, nebo jím určený zmocněnec. Výpis lze vydat i cizincům, kteří mají například trvalé bydliště v České republice. Osoba, která na pracovišti Czech POINT o výpis žádá, musí mít platný doklad totožnosti (občanský průkaz, cestovní pas) a musí mít přiděleno rodné číslo. Pro dohledání řidiče v registru je možné nepovinně zadat i číslo řidičského průkazu. Správní poplatek, který žadatel zaplatí na samosprávních úřadech je za první stránku max. 100,-Kč a za každou další max. 50,-Kč. U ostatních provozovatelů kontaktních míst (Česká pošta, Hospodářská komora, notáři) se poplatek řídí vnitřními sazebníky jednotlivých organizací. zákon č. 480/2008 Sb., kterým se mění zákon č. 274/2008 Sb., kterým se mění některé zákony, v souvislosti s přijetím zákona o Policii České republiky,
zákon č. 361/2000 Sb., o provozu na pozemních komunikacích a o změnách některých zákonů (zákon o silničním provozu), ve znění pozdějších předpisů,
zákon č. 141/1961 Sb., o trestním řízení soudním (trestní řád), ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z insolvenčního rejstříku Ministerstvo spravedlnosti Insolvenční rejstřík je informační systém veřejné správy, který je spravován Ministerstvem spravedlnosti ČR. Jeho základní úlohou je zajistit maximální míru publicity o insolvenčních řízeních a umožnit sledování jejich průběhu. Prostřednictvím insolvenčního rejstříku jsou zveřejňovány veškeré relevantní informace týkající se insolvenčních správců, dokumenty z insolvenčních spisů i zákonem stanovené informace týkající se dlužníků. Pro veřejnost Jedná se o veřejně přístupný rejstřík, není tedy nutné ověřovat totožnost žadatele. V rejstříku je možné vyhledávat na základě dvou parametrů – identifikačního čísla organizace (hledání příslušné organizace) a podle osobních údajů (hledání konkrétní osoby). Poplatek za ověřený výpis se řídí zákonem o správních poplatcích, tzn. 100 Kč za první stranu a 50 Kč za každou následující stranu. zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z Katastru nemovitostí Český úřad zeměměřičský a katastrální O výpis z Katastru nemovitostí České republiky může požádat anonymní žadatel. Výpis lze požadovat na základě
• listu vlastnictví,
• seznamu nemovitostí,
• seznamu jednotek.
Na kontaktních místech lze žádat o
• úplný výpis z Katastru nemovitostí,
• částečný výpis z Katastru nemovitostí, kdy lze vydat výpis např. pouze s některými nemovitostmi, uvedenými na listu vlastnictví.
• výpis snímku z katastrální mapy.
Pro veřejnost. O výpis z Katastru nemovitostí České republiky může požádat anonymní žadatel. Výpis lze požadovat na základě listu vlastnictví nebo podle seznamu nemovitostí. • Pokud žadatel žádá výpis podle listu vlastnictví, musí znát katastrální území a číslo listu vlastnictví.
• Pokud žadatel žádá o výpis podle seznamu nemovitostí, měl by znát katastrální území a dále buď parcelní číslo požadované nemovitosti, jedná-li se o pozemek, nebo stavební parcelu případně číslo popisné, jedná-li se o stavbu.
• O výpis lze zažádat i podle seznamu jednotek, v případě, že budova je dělena na jednotky, což je typické u větších staveb, dělících se na jednotlivé byty, garáže atd. V tomto případě pochopitelně musí žadatel znát nejen popisné číslo domu, ale i přesné číslo bytu v domě.
• Pokud žadatel žádá o výpis snímku z katastrální mapy, musí žadatel znát v případě pozemku údaje o parcele (kmenové číslo a poddělení čísla), nebo v případě stavby typ a číslo stavby.
Pokud žadatel žádá výpis podle listu vlastnictví nebo podle seznamu nemovitostí: V obou případech, vydání první strany výpisu je zpoplatněno částkou, jejíž maximální výše je zákonem omezena na 100,- Kč; každá další strana výpisu je zpoplatněna částkou, jejíž maximální výše je zákonem omezena na 50,- Kč. zákon č. 256/2013 Sb., o katastru nemovitostí, ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z Rejstříku trestů Rejstřík trestů – Ministerstvo spravedlnosti Žadatel může požádat, aby do výpisu byly zahrnuty také údaje z Rejstříku trestů z jiného členského státu EU, v němž žadatel pobýval.
Na základě podepsané písemné žádosti odešle pracovník Czech POINT elektronickou žádost na Rejstřík trestů, který odpoví buď předáním výpisu, nebo informací o zařazení žádosti do tzv. manuálního zpracování.
V případě, že Rejstřík trestů odpoví předáním elektronického výpisu, se tento výpis vytiskne, doplní ověřovací doložkou a zkompletuje.
V případě tzv. manuálního zpracování je žadateli pouze vytištěn tzv. šatní lístek, který obsahuje lhůtu, do kdy by měl být výpis připraven. Žadatel v daném termínu dorazí libovolné kontaktní místo a na základě šatního lístku a dokladu totožnosti si nechá vydat výpis z Rejstříku trestů.
Pro veřejnost. Podle §11a odst. 1 zákona č. 269/1994 Sb., o Rejstříku trestů, v platném znění lze vydat výpis z evidence Rejstříku trestů osobě, které se výpis týká, pouze na základě písemné žádosti. Tuto žádost není třeba ručně vyplňovat, klient ji obdrží vyplněnou k podpisu předtím, než mu je výpis z Rejstříku trestů vydán. Tato žádost se archivuje dle zákona. Žadatel o výpis z Rejstříku trestů musí mít platný doklad totožnosti a musí mít přiděleno rodné číslo. To znamená, že výpis lze vydat i cizincům, kteří mají například trvalé bydliště v České republice. Na pracovištích Czech POINT lze vydávat výpisy i zplnomocněncům, kteří žádají o výpis z Rejstříku trestů na základě úředně ověřené plné moci. V dalším kroku se vytiskne žádost o vydání výpisu, kterou žadatel podepíše.
V případě elektronického výpisu žadatel převezme na místě výpis a zaplatí správní poplatek.
V případě tzv. manuálního zpracování žadatel v daném termínu dorazí libovolné kontaktní místo a na základě šatního lístku a dokladu totožnosti si nechá vydat výpis z Rejstříku trestů. A zaplatí správní poplatek.
1. V případě elektronického výpisu: Žadatel převezme výpis a zaplatí správní poplatek ve výši 100 Kč (bez ohledu na počet stran, v souladu se zákonem č. 634/2004 Sb., o správních poplatcích ve znění pozdějších předpisů). Správní poplatek je příjmem ověřující obce. Na poskytnutý výpis se nevylepuje žádný kolek.
2. V případě tzv. manuálního zpracování: Žadatel uhradí správní poplatek ve výši 100 Kč bez ohledu na počet stran.
zákon č. 269/1994 Sb., o Rejstříku trestů, ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z Rejstříku trestů právnické osoby Rejstřík trestů – Ministerstvo spravedlnosti V souvislosti s přijetím zákona č. 418/2011 Sb., o trestní odpovědnosti právnických osob a řízení proti nim, a zákona č. 420/2011 Sb., o změně některých zákonů v souvislosti s přijetím zákona o trestní odpovědnosti právnických osob a řízení proti nim, vznikla na Ministerstvu spravedlnosti evidence Rejstříku trestů právnické osoby.
Z této evidence je vydáván výpis z Rejstříku trestů právnické osoby. Údaje z evidence Rejstříku trestů právnických osob, které se uvádějí ve výpisu, jsou veřejně přístupné, žadatelem může být kterákoliv fyzická osoba. Z tohoto důvodu se při podání žádosti o výpis týkající se právnické osoby neověřuje totožnost osoby, která žádost podává. Žádost se netiskne, ani nearchivuje.
Pro veřejnost, žadatelem může být fyzická osoba Identifikační číslo osoby. V případě, že subjekt nemá v České republice přiděleno identifikační číslo osoby, nelze vydat výpis na počkání. Žadatel se může obrátit přímo na Rejstřík trestů, Soudní 140 66, Praha 4. Vzor žádosti o výpis lze nalézt zde. Správní poplatek za vydání výpisu je ve výši max. 100 Kč za první stranu a za každou následující max. 50 Kč. zákon č. 418/2011 Sb., o trestní odpovědnosti právnických osob a řízení proti nim,
zákona č. 420/2011 Sb., o změně některých zákonů v souvislosti s přijetím zákona o trestní odpovědnosti právnických osob a řízení proti nim, ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z Veřejných rejstříků Ministerstvo spravedlnosti O výpis z Veřejných rejstříků (viz zákon č. 304/2013 Sb., o veřejných rejstřících právnických a fyzických osob) může požádat anonymní žadatel.
Veřejnými rejstříky právnických a fyzických osob se rozumí:
• spolkový rejstřík
• nadační rejstřík
• rejstřík ústavů
• rejstřík společenství vlastníků jednotek
• obchodní rejstřík
• rejstřík obecně prospěšných společností
Pracovník kontaktního místa Czech POINT může vydat:
• Úplný výpis – jsou v něm obsaženy všechny informace, které byly zapsány v obchodním rejstříku po dobu existence firmy.
• Výpis platných – obsahuje souhrn informací o firmě k aktuálnímu datu.
Pro veřejnost. Může požádat anonymní žadatel. IČO. Výpis lze požadovat na základě znalosti identifikačního čísla osoby (IČO) zapsané v jednom z veřejných rejstříků. Vydání první strany výpisu je zpoplatněno částkou, jejíž maximální výše je zákonem omezena na 100 Kč; každá další strana výpisu je zpoplatněna částkou, jejíž maximální výše je zákonem omezena na 50 Kč. zákon č. 304/2013 Sb., o veřejných rejstřících právnických a fyzických osob, ve znění pozdějších předpisů
Výpisy z informačních systémů veřejné správy Výpis z Živnostenského rejstříku Ministerstvo průmyslu a obchodu O výpis z Živnostenského rejstříku České republiky může požádat anonymní žadatel. Pro veřejnost. O výpis z Živnostenského rejstříku České republiky může požádat anonymní žadatel. IČO. Výpis lze požadovat na základě znalosti identifikačního čísla (IČO) organizace. Vydání první strany výpisu je zpoplatněno částkou, jejíž maximální výše je zákonem omezena na 100,- Kč; každá další strana výpisu je zpoplatněna částkou, jejíž maximální výše je zákonem omezena na 50,- Kč. zákon č. 455/1991 Sb., o živnostenském podnikání, ve znění pozdějších předpisů
Podání vůči veřejné správě Podání do registru účastníků provozu modulu autovraků ISOH Ministerstvo životního prostředí Vyhláška č. 352/2008 Sb., o podrobnostech nakládání s autovraky, definuje informační systém sledování toků vybraných autovraků pro evidenci přijatých autovraků.
Pro evidenci autovraků je nutné, aby se provozovatelé autovrakovišť zaregistrovali na MA ISOH, což je jim právě umožněno přes Czech POINT. Provozovatelé autovrakovišť potřebují získat přístupové údaje do systému evidence autovraků. Přístupové údaje obsahují přihlašovací jméno a heslo, které jednoznačně identifikují provozovatele a provozovnu zařízení ke sběru vybraných autovraků. Přístup do systému může získat pouze podnikatelský subjekt, který k provozování činnosti sběru vybraných autovraků získal povolení od příslušného krajského úřadu.
Podrobnější informace o problematice autovraků jsou k dispozici na //autovraky.cenia.cz/ v sekci Odpadové hospodářství.
Kontaktní místa Czech POINT mohou provést následující činnosti související s MA ISOH:
• registrace a vydání přístupových údajů,
• změna v přiřazení provozoven k uživatelským účtům,
• vygenerování jednorázového hesla k existujícím účtům.
Pracovník kontaktního místa provádí kontrolu totožnosti žadatele pouze za účelem ověření, zda je daný žadatel oprávněn jednat za příslušnou instituci.
Pro podnikatelský subjekt: provozovatelé autovrakovišť Pro vydání přístupových údajů do MA ISOH musí žadatel předložit:
• identifikaci provozovatele (identifikační číslo organizace),
• platný dokladu totožnosti,
• plnou moc k převzetí oprávnění k přístupu do MA ISOH v případě, že se nejedná o statutární orgán provozovatele.
Vydání první strany výpisu je zpoplatněno částkou, jejíž maximální výše je zákonem stanovena na 100 Kč; každá další strana výpisu je zpoplatněna částkou, jejíž maximální výše je zákonem stanovena na 50 Kč. vyhláška č. 352/2008 Sb., o podrobnostech nakládání s autovraky, ve znění pozdějších předpisů
Podání vůči veřejné správě Přijetí podání podle živnostenského zákona (§ 72): Ministerstvo průmyslu a obchodu Podle § 72 zákona č. 455/1991 Sb., o živnostenském podnikání (živnostenského zákona), lze veškerá podání obecním živnostenským úřadům předat prostřednictvím kontaktního místa veřejné správy. Jde o:
• ohlášení živnosti
• ohlášení údajů, vedených v živnostenském rejstříku, nebo jejich změn
• žádost o udělení koncese
• žádost o změnu rozhodnutí o udělení koncese.
Pro veřejnost Vyplnit formulář: Žadatel při podání předkládá vyplněný jednotný registrační formulář, který získá na Ministerstvu průmyslu a obchodu. Listinnou formu podání pracovník Czech POINTu převezme a odešle na zvolený živnostenský úřad. Správní poplatek vybíraný pracovištěm Czech POINT činí v případě samosprávních úřadů 50 Kč za přijetí podání, na ostatních kontaktních místech Czech POINT podle ceníku. Další poplatek se vybírá dle druhu podání. Tento druhý poplatek je určen pro Živnostenský úřad, na který je poté kontaktním místem Czech POINT zasílán. Změna v RŽP je aktivní do 5 pracovních dní. zákon č. 455/1991 Sb., o živnostenském podnikání, ve znění pozdějších předpisů
Zprostředkovaná identifikace osoby Vydání veřejné listiny o identifikaci osoby Finanční analytický úřad - Ministerstvo financíVydání veřejné listiny o identifikaci osoby podle § 10 zákona č. 253/2008 Sb., o některých opatřeních proti legalizaci výnosů z trestné činnosti a financování terorismu.
Zprostředkovaná identifikace spočívá v ověření totožnosti žadatele, zjištění potřebných informací a převzetí podkladů od žadatele a vystavení veřejné listiny o identifikaci. Přílohou veřejné listiny jsou kopie dokumentů, které byly použity pro identifikaci daného subjektu. O provedení identifikace se učiní záznam do interní evidence.
Pro veřejnost – FO, PO (zastoupená jednajícími osobami) nebo jejich zmocněnci Žadatel se musí v případě fyzické osoby prokázat průkazem totožnosti, v případě zmocněnce také úředně ověřenou plnou mocí. Žadatel žádající jako právnická osoba se musí prokázat průkazem totožnosti a předložit doklady o oprávnění jednat za právnickou osobu, v případě zmocněnce též úředně ověřenou plnou mocí. Správní poplatek za vydání veřejné listiny je stanoven na 200,- Kč. zákon č. 253/2008 Sb., o některých opatřeních proti legalizaci výnosů z trestné činnosti a financování, ve znění pozdějších předpisů
Základní registry Výpis údajů z registru obyvatel (ROB) – neveřejný Ministerstvo vnitra Odbor správních činností Žadatel může v této agendě požádat o výpis referenčních údajů, které jsou o jeho osobě vedeny v registru obyvatel (ROB). Pro veřejnost Provádí se ověření totožnosti žadatele nebo zmocnitele. Cena za výpis je standardně dle Sazebníku správních poplatků, tedy max. 100 Kč za první stranu za každou další max. 50 Kč zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Výpis údajů z registru osob (ROS) – neveřejný Český statistický úřad V této agendě lze požádat o výpis referenčních údajů podnikající fyzické osoby, evidované v registru osob (ROS). Pro veřejnost. Neprovádí se ověření totožnosti žadatele Cena za výpis je standardně dle Sazebníku správních poplatků, tedy max. 100 Kč za první stranu za každou další max. 50 Kč. zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Veřejný výpis údajů z registrů osob (ROS) Český statistický úřad Žadatel může požádat o výpis referenčních údajů libovolné podnikající fyzické osoby či organizace, evidované v registru osob (ROS). Pro veřejnost Neprovádí se ověření totožnosti žadatele Cena za výpis je standardně dle Sazebníku správních poplatků, tedy max. 100 Kč za první stranu za každou další max. 50 Kč zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Výpis o využití údajů z registru obyvatel (ROB) Ministerstvo vnitra Odbor správních činností Žadatel může požádat o výpis využívání referenčních údajů o jeho osobě v ROB orgány veřejné moci („kdo se na mě, kdy a za jakým účelem díval“). Volí se období, za které se výpis požaduje Pro veřejnost Průkaz totožnosti. Provádí se ověření totožnosti žadatele nebo zmocnitele Cena za výpis je standardně dle Sazebníku správních poplatků, tedy max. 100 Kč za první stranu za každou další max. 50 Kč. zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Výpis o využití údajů z registru osob (ROS) Český statistický úřad Žadatel může požádat o výpis využívání referenčních údajů podnikající fyzické osoby či organizace v ROS orgány veřejné moci („kdo se na mě, kdy a za jakým účelem díval“). Volí se období, za které se výpis požaduje. Pro veřejnost Průkaz totožnosti. Provádí se ověření totožnosti žadatele. Žadatel musí být osobou oprávněnou jednat za danou organizaci či přímo danou podnikající fyzickou osobou Cena za výpis je standardně dle Sazebníku správních poplatků, tedy max. 100 Kč za první stranu za každou další max. 50 Kč. zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Žádost o změnu údajů v registru obyvatel Ministerstvo vnitra Odbor správních činností Žadatel může požádat o změnu nesprávných referenčních údajů, které jsou o něm vedeny v registru obyvatel (ROB). Žadatel může žádat o změnu svých údajů osobně, nebo prostřednictvím zmocněnce či zákonného zástupce. Pro veřejnost Průkaz totožnosti. Provádí se ověření totožnosti žadatele Zdarma zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Žádost o změnu v registru osob Český statistický úřad Žadatel může požádat o změnu nesprávných referenčních údajů, které jsou o podnikající fyzické osobě či organizaci vedeny v registru osob (ROS). Osobě oprávněné jednat za danou organizaci či přímo daná podnikající fyzická osoba. Průkaz totožnosti. Provádí se ověření totožnosti žadatele. Žadatel musí být osobou oprávněnou jednat za danou organizaci či přímo danou podnikající fyzickou osobou Zdarma zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Základní registry Žádost o poskytování údajů jiné osobě Ministerstvo vnitra Odbor správních činností Žadatel může požádat (nebo odvolat) poskytování svých referenčních údajů z registru obyvatel (ROB) a jejich změn třetí osobě. Referenční údaje jsou následně zasílány do datové schránky třetí osoby v rozsahu, který si určí žadatel Pro veřejnost Žadatel může podat žádost osobně, nebo prostřednictvím zmocněnce či zákonného zástupce Zdarma zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Konverze na žádost a související služby Centrální úložiště ověřovacích doložek Ministerstvo vnitra, odbor eGovernmentu Na základě zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, vede systém Czech POINT centrální evidenci všech doložek o provedení konverze.
Prostřednictvím webového rozhraní je možné ověřit výstup konverze na adrese //www.czechpoint.cz/overovacidolozky/. Pro kontrolu je nutné zadat do pole Identifikační číslo ověřovací doložky – číslo provedené konverze, které je umístěno na dokumentu pod 2D kódem. Systém pak zobrazí původní doložku o provedení konverze z centrálního úložiště ověřovacích doložek tak, jak byla vytvořena při samotné konverzi.
V případě, že nedojde ke shodě čísla v centrálním úložišti ověřovacích doložek s číslem doložky zadaným ke kontrole, tak se jedná o dokument, který v žádném případě nevznikl provedením konverze dokumentů.
V takovém případě nelze považovat kontrolovaný dokument za výstup z konverze dokumentů.
Pro veřejnost Identifikační číslo ověřovací doložky – číslo provedené konverze, které je umístěno na dokumentu pod 2D kódem Zdarma Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů, ve znění pozdějších předpisů, zavádí termín (autorizovaná) konverze dokumentů. Technické parametry ke konverzi specifikuje vyhláška č. 193/2009, o stanovení podrobností provádění autorizované konverze dokumentů
Konverze na žádost a související služby Úschovna systému CzechPoint Ministerstvo vnitra, odbor eGovernmentu Úschovna dokumentů je podpůrný systém pro konverzi dokumentů. Využívá se pro dočasné uložení dokumentů v rámci konverze.
Při konverzi dokumentu v listinné podobě do dokumentu obsaženého v datové zprávě nebo datovém souboru na kontaktním místě Czech POINT lze zkonvertovaný dokument pro další použití uložit do úschovny. Zkonvertovaný dokument bude v úschovně uložen po dobu 3 dnů.
Při konverzi dokumentu obsaženého v datové zprávě nebo datovém souboru do dokumentu v listinné podobě může být vstupní dokument uložen do úschovny prostřednictvím tohoto portálu, nebo odesláním z datové schránky. Následně může být na kontaktním místě Czech POINT konvertován do listinné podoby. Dokument určený pro konverzi může být uložen v úschovně až 30 dnů.
Dokument uložený pro potřeby konverze musí být ve formátu PDF verze 1.3 a vyšší. Dále musí být dokument v případě provedení konverze na žádost opatřen uznávaným elektronickým podpisem, značkou či pečetí.
Nevyzvednuté či nezkonvertované dokumenty po uplynutí stanovené doby budou automaticky smazány.
//www.czechpoint.cz/uschovna/
Pro veřejnost / Zdarma Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů, ve znění pozdějších předpisů, zavádí termín (autorizovaná) konverze dokumentů. Technické parametry ke konverzi specifikuje vyhláška č. 193/2009, o stanovení podrobností provádění autorizované konverze dokumentů
Konverze na žádost a související služby Autorizovaná konverze na žádost Ministerstvo vnitra, odbor eGovernmentu Konverze dokumentu v listinné podobě do dokumentu obsaženého v datové zprávě nebo datovém souboru – zákazník přinese listinu, kterou chce konvertovat, a zvolí si formu výstupu – CD/DVD nebo možnost zaslání do tzv. Úschovny, tedy do úložiště konvertovaných dokumentů, kde si jej nejpozději do 7 dnů vyzvedne. Úhrada nosiče CD/DVD je provedena v rámci úhrady poplatku za konverzi. Výstupem konverze bude dokument ve formátu PDF verze 1.7 a vyšší.

Konverze dokumentu obsaženého v datové zprávě nebo datovém souboru do dokumentu v listinné podobě – dokument, který chce zákazník konvertovat, je možné přinést na CD/DVD nebo vložit do Úschovny (datového úložiště) ručně či posláním z datové schránky zákazníka. V tomto případě s sebou zákazník přinese potvrzení o vložení dokumentu do datového úložiště pro potřeby konverze, které obsahuje jeho jednoznačnou identifikaci. Vstupní dokument musí být ve formátu PDF verze 1.3 a vyšší.

Orgány veřejné moci mohou využívat konverzi z moci úřední pro výkon své působnosti.
Pro veřejnost Zákon č. 300/2008 Sb. o elektronických úkonech a autorizované konverzi dokumentů, zavádí termín konverze dokumentů. Technické parametry ke konverzi specifikuje vyhláška č. 193/2009, o stanovení podrobností provádění autorizované konverze dokumentů
Konverze je:
1. úplné převedení dokumentu v listinné podobě do dokumentu obsaženého v datové zprávě nebo datovém souboru způsobem zajišťujícím shodu obsahu těchto dokumentů a připojení doložky o provedení konverze, nebo
2. úplné převedení dokumentu obsaženého v datové zprávě či datovém souboru do dokumentu v listinné podobě způsobem zajišťujícím shodu obsahu těchto dokumentů a připojení doložky o provedení konverze.
3. dokument, který provedením konverze vznikne, má stejné právní účinky jako dokument, jehož převedením výstup vznikl. Konverzí se nepotvrzuje správnost a pravdivost údajů obsažených ve vstupu a jejich soulad s právními předpisy. Doložka o provedení konverze se ukládá do Centrálního úložiště ověřovacích doložek.
Pro veřejnost je určena tzv. konverze na žádost, která funguje následujícím způsobem.
Poplatek za nosič (CD/DVD) a konverzi Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů, ve znění pozdějších předpisů, zavádí termín (autorizovaná) konverze dokumentů. Technické parametry ke konverzi specifikuje vyhláška č. 193/2009, o stanovení podrobností provádění autorizované konverze dokumentů
Datové schránky Žádost o zřízení datové schránky Ministerstvo vnitra, odbor eGovernmentu Na kontaktních místech veřejné správy Czech POINT je možné podat žádost o zřízení datové schránky. Žadatel předloží doklad totožnosti. Žádost vyplní pracovník přepážky elektronicky, následně jí vytiskne a předloží zákazníkovi ke kontrole a k podpisu. Datová schránka bude zřízena do tří dnů. Poté obdrží zákazník přístupové údaje poštovní zásilkou do vlastních rukou Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Žádost o znepřístupnění datové schránky Ministerstvo vnitra, odbor eGovernmentu Použije se v případě, kdy žadatel potřebuje znepřístupnit datovou schránku podle § 11 odst. 4 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů. Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Žádost o opětovné zpřístupnění datové schránky Ministerstvo vnitra, odbor eGovernmentu Použije se k obnovení dříve znepřístupněné datové schránky Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Podání žádosti o zneplatnění přístupových údajů do datové schránky a vydání novýchMinisterstvo vnitra, odbor eGovernmentu V případě ztráty, nebo odcizení přístupových údajů do datové schránky může oprávněná osoba k datové schránce požádat o zneplatnění přístupových údajů a vystavení nových. Žadatel předloží doklad totožnosti. Žádost vyplní pracovník přepážky elektronicky, následně jí vytiskne a předloží zákazníkovi ke kontrole a k podpisu. Ke zneplatnění stávajících přístupových údajů dojde okamžitě, poté bude automaticky odeslán e-mail s odkazem na aktivační portál, kde si žadatel vyzvedne nové přístupové údaje Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Vyřízení reklamace obdržení přístupových údajů a vydání nových Ministerstvo vnitra, odbor eGovernmentu Tímto způsobem lze zjistit stav žádosti o zaslání nových přístupových údajů k datové schránce. Využít jej mohou žadatelé, kteří požadovali zaslání přístupových údajů prostřednictvím emailové adresy, a z nějakého důvodu jim přístupové údaje nebyly doručeny. Pracovník kontaktního místa nalezne pomocí formuláře chybu, vyřeší ji a dokončí doručení nových přístupových údajů k datové schránce. Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Přidání pověřené osoby k přístupu do datové schránky Ministerstvo vnitra, odbor eGovernmentu Dojde k přidání pověřené osoby k přístupu do datové schránky. V oznámení je nutné zvolit typ oprávnění (pověřená osoba, administrátor). Dále je potřeba nastavit práva pro přístup pověřené osoby. Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Zneplatnění přístupových údajů pověřené osoby (zrušení osoby) Ministerstvo vnitra, odbor eGovernmentu Dojde ke smazání pověřené osoby, která má přístup k datové schránce. Smazáním pověřené osoby dojde ke zneplatnění jejich přístupových údajů. Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Povolení PO/PFO/FO dodávání dokumentů od PO/PFO/FO Ministerstvo vnitra, odbor eGovernmentu Datová schránka se nastaví do speciálního režimu, kdy je možné doručovat komerční datové zprávy do dané datové schránky. Tato služba je na straně ISDS zpoplatněna. Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Datové schránky Zrušení PO/PFO/FO dodávání dokumentů od PO/PFO/FO Ministerstvo vnitra, odbor eGovernmentu Zruší se doručování komerčních zpráv do datové schránky. Je možné pouze komunikovat s orgány veřejné moci. Pro veřejnost 1. platný doklad totožnosti. Zastupuje-li žadatel jinou osobu, musí být touto osobou zplnomocněn na základě plné moci, která je sepsána za tímto účelem a je notářsky ověřená.
2. V případě, že je zřizována datová schránka pro právnickou osobu na žádost, je nutné navíc k žádosti doložit jmenovací dekret, usnesení valné hromady, či jakýkoliv jiný dokument, který určuje danou osobu jako jednatele či statutární orgán za danou právnickou osobu. I tento dokument musí být úředně ověřen. Všechny přiložené dokumenty k žádosti jsou konvertovány do elektronické podoby. Žádosti pak vždy spadají do správního řízení. Konverze je v těchto případech provedena zdarma.
Činnosti v rámci informačního systému datových schránek jsou prováděny zdarma. Zpoplatněna je pouze konverze na žádost (30 Kč za stránku) a opakované vydání přístupových údajů (200 Kč). Zákon č. 300/2008 Sb. o elektronických úkonech
a autorizované konverzi dokumentů zavádí termín (autorizovaná) konverze dokumentů, ve znění pozdějších přístupů.
Aktivace identifikačního prostředku na kontaktním místě Czech POINTAktivace identifikačního prostředku na kontaktním místě Czech POINT Ministerstvo vnitra, odbor eGovernmentu Pokud jste se rozhodli aktivovat svůj uživatelský účet (identifikační prostředek Jméno, heslo a SMS) poskytnutím referenčních údajů z registru obyvatel jiné osobě na pobočce Czech POINT, postupujte dle následujícího návodu, který jsme pro Vás připravili. Jako první krok je nutné podat Žádost o poskytnutí referenčních údajů z registru obyvatel jiné osobě, kterou je v tomto případě Správa základních registrů. Podání žádosti můžete provést bezplatně na jakémkoli kontaktním místě Czech POINT. V žádosti vyplňované na kontaktním místě je nutné vložit do zprávy pro příjemce Váš identifikační kód pro připojení souhlasu, který je zasílán po dokončení registrace uživatelského účtu na Vámi vyplněnou e-mailovou adresu. Stejný kód je zároveň zaslán i na vyplněné telefonní číslo. Pro veřejnost • Váš doklad totožnosti
• Váš identifikační kód
Následně si vyberte kteroukoliv z poboček Czech POINT. Kontaktní místa se nacházejí na pobočkách České pošty nebo na obecních či městských úřadech. Pokud si nejste jistí adresou kontaktního místa, můžete najít polohu nejbližšího kontaktního místa na stránkách Czech POINT.
1. U přepážky sdělte úředníkovi, že byste rádi poskytli „Žádost o poskytnutí referenčních údajů z registru obyvatel jiné osobě“.
2. Předložte svůj průkaz totožnosti.
3. Sdělte, že chcete poskytnout svá osobní data právnické osobě s IČO 72054506. Jedná se o IČO Správy základních registrů.
4. Při dotazu na rozsah poskytnutých údajů volte položky „Datum narození“ a „Čísla elektronicky čitelných dokladů“.
5. Následně do zprávy pro příjemce nahlaste Váš identifikační kód.
6. Nakonec zvolte variantu jednorázového poskytnutí.

Obsluha Vám vytiskne ke kontrole a podepsání vyplněný formulář žádosti. Na tomto formuláři zkontrolujte zejména Vaše osobní údaje, správné IČO identifikující Správu základních registrů, rozsah poskytnutých údajů (datum narození a čísla dokladů) a zkontrolujte si ve zprávě pro příjemce Váš identifikační kód. V případě, že jsou všechny údaje v pořádku, dokument podepište a vraťte zpět obsluze na přepážce. Ta provede odeslání Vaší žádosti a vytiskne Vám potvrzení.
Aktivace Vašeho účtu jako identifikačního prostředku pro přihlašování mimo portál národního bodu proběhne obvykle do několika minut a tento prostředek je možné plnohodnotně využívat pro přístup k online službám.
Zdarma
Pohled na univerzální kontaktní místo

Asistovaná specializovaná kontaktní místa

Specializovaná asistovaná kontaktní místa slouží pro klienty, kteří z jakéhokoliv důvodu nemohou využít služeb samoobslužných kontaktních míst, a zároveň není služba kvůli své specializaci dostupná v univerzálním asistovaném kontaktním místě. Jedná se ve většině případů o přepážky úřadů, na kterých služby vyřizuje personál proškolený pro danou specializaci. Příkladem může být Finanční úřad (daňové povinnosti), Katastrální úřad (vlastnictví nemovitostí) nebo Ministerstvo zemědělství (zemědělské dotace). Jakkoliv je však služba specializovaná, nemělo by to bránit v její zveřejnění jako samoobslužná varianta v univerzálním kontaktním místě.

Systém správy dokumentů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Obecně o spisové službě

Podle zákona č. 499/2004 Sb. vykonávají spisovou službu tzv. určení původci, přičemž zákon rovněž stanoví, pro které subjekty je povinnost vykonávaní spisové služby v elektronické podobě v systémech elektronické spisové služby. Výkonem spisové služby se rozumí „zajištění odborné správy dokumentů vzniklých z činnosti původce, popřípadě z činnosti jeho právních předchůdců, zahrnující jejich řádný příjem, evidenci, rozdělování, oběh, vyřizování, vyhotovování, podepisování, odesílání, ukládání a vyřazování ve skartačním řízení, a to včetně kontroly těchto činností“. Zákon o archivnictví a spisové službě definuje pojem „dokument“ jako každou písemnou, obrazovou, zvukovou nebo jinou zaznamenanou informaci, ať již v podobě analogové či digitální, která byla vytvořena původcem nebo byla původci doručena. Zákon o archivnictví a spisové službě definuje též pojem „metadata“ jako data popisující souvislosti, obsah a strukturu dokumentů a jejich správu v průběhu času.

Nařízení (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES (dále jen „eIDAS“) definuje pojem „elektronický dokument" jako jakýkoli obsah uchovávaný v elektronické podobě, zejména jako text nebo zvukovou, vizuální nebo audiovizuální nahrávku.

Legislativní rámec pro výkon spisové služby určuje zákon č. 499/2004 Sb., o archivnictví a spisové službě a prováděcí Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby. Národní standard pro eSSL vydaný ministerstvem vnitra pak stanovuje podrobné technické požadavky na aplikační a byznysové funkce eSSL a dalších systém spravujících dokumenty (ISSD).

Z hlediska „nosiče“ můžeme pak dokumenty rozdělit na skupinu analogových (typicky dokument vyhotovený na papíru) a na skupinu elektronických dokumentů (viz nařízení eIDAS).

Zákon o archivnictví a spisové službě zavádí pojem „výstupní datové formáty dokumentů“, tj. formáty, které musí veřejnoprávní původci přijímat. Definice těchto formátů je uvedena v § 23 vyhlášky č. 259/2012 Sb.

Zákon o archivnictví a spisové službě v § 3, odst. 5) stanoví podmínky pro dokumenty v digitální podobě, kde se jejich uchováváním rozumí rovněž zajištění věrohodnosti původu dokumentů, neporušitelnosti jejich obsahu a čitelnosti, tvorba a správa metadat náležejících k těmto dokumentům v souladu s tímto zákonem a připojení údajů prokazujících existenci dokumentu v čase. Tyto vlastnosti musí být zachovány do doby provedení výběru archiválií.

Zákon o archivnictví a spisové službě též stanoví specifické podmínky pro práci s dokumenty v digitální podobě jako je například převod mezi analogovou a digitální podobou nebo změna datového formátu.

Zákon též pamatuje na situace, kdy mohou veřejnoprávní původci plnit své povinnosti evidencí dokumentů i mimo systémy spisových služeb v tzv. samostatných evidencích dokumentů, kdy tyto evidence obdobně jako systémy elektronické spisové služby musí splňovat požadavky Národního standardu.

Shrneme-li základní požadavky, pak povinné subjekty musí:

  1. Vykonávat spisovou službu tak, že eviduje dokumenty v elektronickém systému spisové služby, nebo v samostatné evidenci dokumentů.
  2. Zajistit soulad eSSL a všech samostatných evidencí dokumentů vedených v elektronické podobě s požadavky NSESSS.
  3. Mít jeden elektronický systém spisové služby.
  4. Zajistit integraci ostatních informačních systémů na eSSL či samostatnou evidenci dokumentů dle požadavků Národního standardu.
  5. Vést jmenný rejstřík, přiřazovat subjektům bezvýznamové identifikátory a vytvářet a spravovat vazby všech dokumentů obsahujících osobní údaje na osoby ve jmenném rejstříku.
  6. Řádně uchovávat a spravovat digitální dokumenty a jejich komponenty v eSSL nebo samostatné evidenci dokumentů.
  7. Provádět evidenci metadat o spisech, dokumentech a dalších entitách a zajistit evidenci všech transakcí a definovaných operací v eSSL či v samostatné evidenci v souladu s požadavky Národního standardu
  8. Zajistit příjem, evidenci, rozdělování, oběh, vyřizování, vyhotovování, podepisování, odesílání, ukládání a vyřazování dokumentů ve skartačním řízení v souladu s archivním zákonem, spisovou vyhláškou a Národním standardem
  9. Zajistit řádné ověření autenticity a integrity doručených dokumentů v digitální podobě v souladu s nařízením eIDAS a zákonem č. 297/2016 Sb. a zajistit v souladu s uvedenými předpisy řádné připojení autentizačních a autorizačních prvků na dokumenty v digitální podobě vyhotovené původcem
  10. Uchovávat dokumenty a umožnit výběr archiválií, vybrané archiválie v analogové podobě předávat příslušnému státnímu archivu a archiválie v digitální podobě příslušnému digitálnímu archivu.

Digitální kontinuita

Digitální kontinuita je soubor procesů, opatření a prostředků nutných k tomu, aby byl původce schopen zajistit dlouhodobou důvěryhodnost informací a dokumentů. S ohledem na odlišný charakter činnosti soukromoprávních původců dokumentů a veřejnoprávních původců je u veřejnoprávních původců situace jednodušší. Pro obě skupiny původců lze však vycházet ze základních principů obsažených v ISO normách, zejména pak v ČSN ISO 30300 Systémy správy dokumentů, ČSN ISO 15489 Správa dokumentů, ČSN ISO 16363 Audit a certifikace důvěryhodných digitálních úložišť. Výše uvedené normy upravují vazby podnikových procesů a dokumentů, zajištění vypovídací hodnoty, koncepty a principy správy dokumentů od zrodu až k uložení a zajištění dlouhodobé důvěryhodnosti.

Autenticitou dokumentů se rozumí otázka, zda jde o původní dokument: dokument je autentický, pokud nedošlo k žádné jeho změně. V případě elektronických dokumentů dokáží jejich neměnnost (označovanou též jako integritu) zajistit všechny druhy kryptografických elektronických podpisů, pečetí a časových razítek. Tedy zaručený elektronický podpis, stejně jako všechny vyšší druhy elektronických podpisů (zaručený elektronický podpis, založený na kvalifikovaném certifikátu, i kvalifikovaný elektronický podpis), zaručená elektronická pečeť, stejně jako všechny vyšší druhy elektronických pečetí, a také elektronické časové razítko.

Pravostí dokumentu se rozumí otázka, zda dokument pochází od toho, koho považujeme za jeho původce, a obecně se dovozuje z autentizačních prvků, kterými je dokument opatřen. V případě elektronických dokumentů jde o elektronické podpisy, elektronické pečeti a elektronická časová razítka. U nich se nejprve zkoumá (ověřuje) jejich platnost, která je technickým pojmem a je závislá na splnění určitých technických podmínek (podrobněji popsaných v článku 32, resp. 40 nařízení eIDAS). Teprve v případě prokázání jejich platnosti je možné, v závislosti na druhu elektronického podpisu či pečeti, z technické platnosti dovozovat i právní pravost příslušných autentizačních prvků (podpisů a pečetí) , a z ní následně i pravost elektronického dokumentu jako takového.

V souvislosti s tím je nutné zdůraznit, že možnost ověřit (technickou) platnost elektronických podpisů a pečetí, stejně jako časových razítek, se s postupem času ztrácí. Jde o základní vlastnost, jakousi časovou pojistku, charakteristickou pro všechny zaručené (a vyšší) druhy elektronických podpisů, pečetí a razítek. Jejím účelem je chránit již vytvořené elektronické dokumenty před zastaráváním a oslabováním kryptografických postupů a algoritmů, použitých u jejich podpisů (ale i pečetí a časových razítek). Bez této časovém pojistky by po uplynutí určité doby již nebylo možné z technické platnosti dovozovat právní pravost podpisů, a tím ani celých dokumentů: vzhledem k oslabení kryptografických algoritmů, použitých u původně podepsaného dokumentu, by již bylo možné reálně najít (vypočítat) jiný dokument, který je tzv. kolizní vůči původně podepsanému dokumentu. Tedy takový dokument, který má jiný obsah, ale stejný elektronický podpis. Pak by bylo možné přenést elektronický podpis z původně podepsaného dokumentu na onen později vytvořený kolizní dokument, a v obou případech by byl takovýto podpis ověřen jako (technicky) platný – a nebylo by tak již možné spolehlivě prokázat, který dokument je pravý (který byl původně podepsán).

Problematika digitální kontinuity elektronických dokumentů naopak nezahrnuje otázku jejich pravdivosti, neboli správnosti obsahu těchto elektronických dokumentů. Požadavek na dlouhodobě zajištění, resp. dlouhodobé udržování digitální kontinuity elektronických dokumentů se v praxi týká jen těch elektronických dokumentů, u kterých je nějaký důvod pro zachování možnosti prokázat jejich autenticitu a pravost.

Řídící dokumenty

V rámci výkonu spisové služby jsou řídícími dokumenty zejména:

  • Legislativa
    1. Zákon č. 499/2004 Sb., o archivnictví a spisové službě
    2. Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby
  • Technické a architektonické požadavky
    1. Národní standard pro elektronické systémy spisové služby
    2. Národní architektonický plán
  • Vnitřní řídící dokumenty úřadu
    1. Spisový řád
    2. Spisový plán
    3. Informační koncepce úřadu
  • Dokumentace k elektronickému systému spisové služby
    1. Dokumentace k ESSL
    2. Dokumentace k integracím ESSL
    3. Dokumentace související s výkonem spisové služby

Další zdroje

V souvislosti s výkonem spisové služby existuje celá řada dalších zdrojů informací a metodických dokumentů publikovaných zejména Odborem archivnictví a spisové služby (OAS) Ministerstva vnitra a Národním archivem ČR.

Pohled na systém správy dokumentů

Systémy a služby spojené s právním řádem a legislativou

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Veřejná správa se řídí primárně legislativou. Proto je nesmírně důležité jednak právnímu řádu dobře rozumět a jednak zahrnout legislativu jako motivační a kontraktační rámec do architektur.

Základní komponenty právních systémů státu

Základní informační systémy a služby státu týkající se práva a legislativy

Systém Správce Popis Příklady užití
eSbírka Ministerstvo vnitraElektronická sbírka právních předpisů s jejich konsolidovaným časovým zněním Pomocí služeb rozhraní ESEL bude možné automatizovaně přebírat dekomponované právní předpisy a mít je tak jako vazbové zdroje pro motivační a procesní a byznysovou architekturu. eSbírka bude představovat výchozí referenční zdroj znění a změn právních předpisů
eLegislativaMinisterstvo vnitraInformační systém pro podporu tvorby a projednávání návrhů legislativních změn a pro elektronizaci procesu přijímání legislativy V rámci služeb ESEL bude k dispozici sledování stavu přípravy a projednávání změn a návrhů, ale také prostředí a nástroje pro tvorbu návrhů na legislativní úpravy (může pocházet z výsledků návrhů optimalizace dle architektury)
ODOK Úřad vlády IS pro oběh dokumentů určených pro vládní agendu a pro jednání vlády a jejich orgánů V tomto informačním systému jsou dokumenty a informace v rámci vládní agendy, podklady pro jednání vlády, ale jeho prostřednictvím se sledují i vládní a legislativní úkoly
EKLEP Úřad vlády Elektronická knihovna legislativního procesu slouží jako IS pro podporu celého procesu projednáván´, připomínkování a schvalování legislativních návrhů
VEKLEP Úřad vlády Veřejná část knihovny EKLEP Je publikováno i schematicky podle XML schémat metadat a jako opendata, takže se dá využít v řadě případů jako informační zdroj
RPP Ministerstvo vnitraV Registru práv a povinností jsou také referenční a závazné údaje o jednotlivých agendách, vazbách na legislativu, působnostech OVM a úkonech a činnostech v těchto agendáchSlouží jako autoritativní a referenční zdroj o výkonu veřejné správy

Každý z těchto IS může a má být využíván jednak jako zdroj informací pro úřady a jednak jako jeden z komponent při optimalizaci činností úřadu. Kupříkladu, chceme-li v úřadu optimalizovat agendu, měli bychom mít její architekturu. Jedním ze vstupů pro tuto architekturu je legislativa (zdroj ESEL) a agendový model dané agendy (zdroj RPP). Po návrhu procesní optimalizace bude pravděpodobně nutné novelizovat i legislativu, k čemuž zase poslouží i výše zmíněné informační systémy.

Elektronické úkony a doručování

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Pro zajištění důvěryhodné, bezpečné a průkazné elektronické komunikace mezi orgány veřejné moci na straně jedné a fyzickými či právnickými na straně druhé, jakož i mezi orgány veřejné moci navzájem, provozuje Ministerstvo vnitra ČR informační systém datových schránek (také jako "ISDS"). Ministerstvo vnitra ČR a spolupracující subjekty se při provozování ISDS řídí provozním řádem, který je pro ně závazný.

Orgány veřejné moci jsou povinni mezi sebou komunikovat prostřednictvím ISDS, stejně tak s klientem veřejné správy, pokud datovou schránku vlastní.

Typy datové schránky

Způsob, resp. proces zřízení datové schránky se liší podle typu subjektu, pro který má být datová schránka zřízena. Typ subjektu určuje, zda se jedná o datovou schránku zřizovanou ze zákona, tedy automaticky, nebo o datovou schránku zřizovanou na žádost dle následující tabulky

Typ subjektu Typ datové schránky v ISDS Zřízena
Orgán veřejné moci OVM (10) Ze zákona
Fyzická osoba, která je v roli OVM OVM_FO (14) Ze zákona
Podnikající fyzická osoba, která je v roli OVM OVM_PFO (15) Ze zákona
Právnická osoba v roli OVM OVM_PO (16) Ze zákona
Právnická osoba zapsaná v obchodním rejstříku PO (20) Ze zákona
Podnikající fyzická osoba - advokát PFO_ADVOK (31) Ze zákona
Podnikající fyzická osoba - daňový poradce PFO_DANPOR (32) Ze zákona
Podnikající fyzická osoba - insolvenční správce PFO_INSSPR (33) Ze zákona
Podnikající fyzická osoba - statutární auditor (OSVČ nebo zaměstnanec) PFO_AUDITOR (34) Ze zákona
Fyzická osoba FO (40) Na žádost
Podnikající fyzická osoba PFO (30) Na žádost
Právnická osoba - na žádost PO_REQ (22) Na žádost
Schránka OVM zřízená na žádost OVM_REQ (13 Na žádost

Zápis rozhodnutí do Registru práv a povinností

Zákon o základních registrech vyžaduje, aby při každé změně referenčního údaje v základních registrech došlo také k zápisu o příslušném rozhodnutí, na jehož základě byl údaj změněn, do Registru práv a povinností. Ministerstvo vnitra je v agendě datových schránek editorem jediného referenčního údaje – identifikátoru datové schránky. Při každém zápisu i výmazu tohoto údaje do Registru obyvatel nebo Registru osob proto ISDS provádí zároveň zápis do Registru práv a povinností.

Využití údajů základních registrů (ZR)

Ministerstvo vnitra rozsáhle využívá referenční údaje základních registrů pro účely správy datových schránek. Základní registry tak představují nejdůležitější zdroj dat, na základě kterých jsou datové schránky zřizovány i znepřístupňovány a také aktualizovány identifikační údaje datových schránek a jejich uživatelů.

Zřizování datových schránek ze zákona

Na základě informací z Registru osob jsou zřizovány datové schránky subjektům, kterým se datová schránka zřizuje ze zákona. Výjimku představuje malá množina subjektů, které v Registru osob nejsou vedeny, protože nemají přiděleno své unikátní IČO (orgány veřejné moci bez právní subjektivity).

Znepřístupňování datových schránek

Na základě informací z Registru osob jsou znepřístupňovány datové schránky subjektů, u kterých bylo v Registru osob vyplněno datum zániku. Obdobně, jakmile je u fyzické osoby v Registru obyvatel vyplněno datum úmrtí, datová schránka je k tomuto datu znepřístupněna.

Aktualizace údajů datových schránek

Pro datové schránky všech typů platí, že pokud je subjekt veden v základních registrech, identifikační údaje datové schránky jsou automatizovaně přebírány ze Základních registrů. Tzn. změny názvu subjektu nebo adresy sídla není nutné Ministerstvu hlásit – změny jsou promítnuty automaticky.

Přidání / odebrání Oprávněné osoby

Oprávněné osoby u datových schránek těch subjektů, které jsou zapsány v Registru osob, jsou aktualizovány podle změn ve výčtu statutárních zástupců vedených u daného subjektu v Registru osob. Tzn. je-li do registru zapsán nový statutární zástupce, automatizovaně mu je zřízen účet Oprávněné osoby u datové schránky subjektu a naopak, je-li statutární zástupce z registru odebrán, jeho účet Oprávněné osoby u datové schránky je zrušen.

Aktualizace osobních údajů uživatelů datových schránek

U všech uživatelů datových schránek se Ministerstvo vnitra pokouší o jejich automatizované ztotožnění vůči příslušnému záznamu v Registru obyvatel. U těch uživatelů, kde se ztotožnění zdařilo, jsou automatizovaně přebírány aktuální referenční údaje z Registru obyvatel. Tzn. např. v případě změny příjmení nebo adresy pobytu nemusí držitel datové schránky Ministerstvu vnitra nic hlásit – změna je promítnuta automaticky.

Jednotný identitní prostor veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Jednotný identitní prostor (JIP) informačních systémů veřejné správy a Katalog autentizačních a autorizačních služeb (KAAS) je autentizační informační systém podle § 56a zákona o základních registrech a jeho správcem je Ministerstvo vnitra. Na základě znění zákona zavedení jakékoli osoby do tohoto autentizačního informačního systému vyžaduje její jednoznačné ztotožnění oproti základnímu registru obyvatel. Ministerstvo dále spravuje prostředky pro autentizaci, které vydává.

V rámci současného stavu (As-Is 2018) předpokládá co nejširší používání autentizačního informačního systému JIP/KAAS pro splnění zásadních podmínek pro identifikaci a autentizaci interních uživatelů informačních systémů veřejné správy. Pro ty informační systémy, kde interní uživatelé informačního systému jsou zaváděni úřady, které nejsou správci tohoto informačního systému, je použití autentizačního informačního systému JIP/KAAS povinností.

V rámci budoucího stavu (To-Be 2020) bude využití systému JIP/KAAS možné i s pomocí prostředků národního identitního prostoru, a to tím, že se stane jedním z kvalifikovaných poskytovatelů (tzv. service provider). Aby přihlašování do JIP/KAAS bylo umožněno i jinými prostředky národního identitního prostoru, než je např. občanský průkaz nebo jméno+heslo+sms, je potřeba zajistit úředníkům jiný prostředek jedním z následujících způsobů:

  • Sekce pro státní službu na MV zajistí jednotný prostředek identity úředníka v rámci národního identitního prostoru.
  • Jiný orgán veřejné moci zajistí vydávání profesních identit v rámci národního identitního prostoru z nichž požadavky na úřední identitu (včetně zajištění finančních prostředků) sdělí Sekce pro státní službu na MV.

Unikátní a jednotná identita zaměstnance v rámci veřejné správy jako celku je nutná ve dvou rovinách, jako:

  • Aktivní identita a identifikace - opravňuje zaměstnance k přístupu k informacím a informačním systémům, (+ k prostorám a zařízením) - zaměstnanec jako subjekt
  • Pasivní identita a identifikace - jednoznačně označuje předmětného (většinou zodpovědného) zaměstnance v rámci centrálních nástrojů řízení a koordinace veřejné správy - zaměstnanec jako objekt evidence (totéž pro pozici - služební místo a vzájemný vztah k zaměstnanci).

Stávající řešení JIP/KAAS nebylo určeno pro takto široké účely a koncepčně ani fyzicky nevyhovuje změněným nároků. Jeho budoucí rozvoj musí vycházet z diskuse o reálných potřebách všech zainteresovaných. Předpokladem budoucího efektivního využívání jednotného identitního prostoru veřejné správy a naplnění některých konceptů architektonické vize eGovernmentu, jako je například transakční Portál úředníka, poskytující kromě jiného i společné personální, vzdělávací, nákupní a další funkce, musí dojít ke sjednocení identit a identifikací pracovníků veřejné správy bez ohledu na typ zaměstnaneckého/ služebního poměru, tj. společně pro:

  • státní službu, dle zák. č. 234/2014 Sb., o státní službě,
  • služební poměr, dle zák. č. 361/2003 Sb. o služebním poměru příslušníků bezpečnostních sborů,
  • poměr dle zák. č. 312/2002 Sb. Zákon o úřednících územních samosprávných celků,
  • zaměstnanecký poměr, dle zák. č. 262/2006 Sb. Zákoník práce.

Důležité je, že vznik a zejména zánik identifikace a oprávnění k roli musí v JIP vznikat na základě jeho integrace s lokálními personálními systémy, resp. s centrálními služebními a zaměstnaneckými registry na jedné straně a v integraci na lokální IDM/IAM systémy na druhé straně. Tyto základní požadavky a potřeby budou formovat budoucí architekturu JIP a nezbytných spolupracujících systémů.

Pohledy na jednotný identitní prostor

Jednotné obslužné kanály a uživatelská rozhraní úředníků

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Ve shodě s cílem a s principy poskytnout úředníkům efektivní navigační a uživatelské prostředí pro elektronické úřadování, pro elektronickou správu zdrojů úřadu a pro zaměstnaneckou samoobsluhu je potřeba výrazně posílit a rozvinou, případně nahradit dosavadní možnosti sdílených služeb Portál úředníka a CzechPOINT@Office.

Portál úředníka

Aktuálně částečně plní tuto roli pouze portál IS o Státní službě (ISoSS), který má dvě části - veřejnou část a část pro služební úřady, s přístupem přes JIP/KAAS.

Veřejná část poskytuje 3 funkce:

  • Přihlašování na úřednickou zkoušku
  • Evidence obsazovaných služebních míst
  • Evidence provedených úřednických zkoušek

Portál ISoSS v sekci pro služební úřady umožňuje:

  • Vkládání návrhů na systemizaci pracovních míst (a dále také Vlastní kontrola návrhů, Úprava návrhů, Odesílání návrhů do schvalovacího procesu, Možnost vkládání odůvodnění k návrhu, Prohlížení postupu schvalovacího procesu návrhu)

Podle architektonické vize eGovernmentu pro každého úředníka bude v jeho „kmenovém“ úřadě poskytnuto jednotné univerzální vnitřní navigační prostředí a webové uživatelské pracovní prostředí, umožňující mu přístup do všech místních a do všech centrálních informačních systémů, k nimž je z titulu svých rolí v OVS oprávněn.

Portál úředníka (PÚ) bude federativní (federalizovaný) obráceným způsobem než PVS. Tj. budou existovat jednotlivé centrální portálové služby (HR, vzdělávání, NEN, IISSP, …), které budou připojovány do lokálního transakčního PÚ, do něhož by se měl postupně transformovat každý tzv. Intranet úřadu. Vedlo toho se jeden z centrálních portálů VS, IKČR navrhuje, aby to byl buď personální portál ISoSS, případně portál odvozený od Portálu občana, rozšíří tak, aby pro úřední osoby a zaměstnance úřadů, pro něž je nehospodárné spravovat svůj vlastní PÚ, poskytl službu zprostředkování všech centrálních interních portálů na jednom místě.

Vedlo toho se jeden z centrálních portálů VS, IKČR navrhuje, aby to byl personální portál ISoSS, rozšíří tak, aby pro úřední osoby a zaměstnance úřadů, pro něž je nehospodárné spravovat svůj vlastní PÚ, poskytl službu zprostředkování všech centrálních interních portálů na jednom místě.

Všechny funkce portálu úředníka, přesahující hranice „domovského“ OVS budou dostupné výhradně s využitím JIP/KAAS. Proto musí být i lokální IS dostupné se stejnou identitou nebo musí mít úřad pro Portál úředníka a do něj zařazené IS vybudovaný lokální Single-Sign-On řešení, integrované s JIP/KAAS.

CzechPOINT@Office

Jde o neveřejné pracoviště úřadu, kde úředník samostatně čerpá informace, ověřuje a předkládá podání v rámci k eGovernmentu. Je určeno pro úředníky orgánů veřejné moci, kteří ze zákona přistupují k rejstříkům nebo provádějí autorizovanou konverzi dokumentů z moci úřední. (Např. místo toho, aby občan nebo podnikatel dokládal Výpis z rejstříku trestů, úředník si pořídí nutný doklad pomocí Czech POINT@Office).

Jedná se o pracoviště na libovolném úřadě, s technickým vybavením stejným jako v případě veřejnosti přístupných pracovišť Czech POINT, tzn. standardní počítač s přístupem na internet, webový, formulářový a dokumentový prohlížeč, účet pro používání Czech POINT@Office (přístup pomocí dvojice certifikátů pro autentizaci a podpis žádostí).

Systém Czech POINT poskytuje rozhraní CzechPOINT@office, které je určeno pro orgány veřejné moci. Pomocí formulářů, dostupných v rozhraní CzechPOINT@office, mohou úředníci využívat pro výkon své působnosti. Jedná se zejména o:

  • výpis a opis z Rejstříku trestů
  • výpisy ze základních registrů
  • autorizovanou konverzi z moci úřední
  • agendy matrik
  • agendy ohlašoven
  • agendy soudů

Do oblasti nástrojů pro úředníky patří také podpora provádění autorizované konverze z moci úřední (také jako KzMU). K dispozici jsou dvě API rozhraní systému CzechPOINT pro tuto úlohu.

Služby CzechPOINT@Office budou představovat jedny z prvních centrálních sdílených služeb pro Portály úředníka, CzechPOINT@Office bude postupně konvergovat k Portálu úředníka, splyne s ním nebo bude nahrazen a společně vytvoří jedno efektivní interní obslužné rozhraní.

Pohled na jednotné obslužné kanály úředníků

Sdílené služby INSPIRE

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Evropská směrnice INSPIRE ukládá členským státům povinnost zajistit zpřístupnění prostorových dat a souvisejících síťových služeb, které náleží k 34 tématům 3 příloh Směrnice INSPIRE. V České republice se tak děje prostřednictvím Národního geoportálu INSPIRE (gesce Ministerstva životního prostředí), jehož součástí je centrální metadatový katalog, který obsahuje metadata prostorových dat, síťových služeb a z nich vytvořených mapových kompozic. Národní geoportál INSPIRE zpřístupňuje prostorová data a služby nad prostorovými daty i pro národní účely, pro potřeby veřejné správy a ostatních subjektů (veřejnost, soukromé firmy) České republiky.

Směrnice INSPIRE zavádí jednotné závazné standardy formou nařízení a doporučujících i technických prováděcích pokynů, které jednotlivá nařízení doplňují. Východiskem pro nařízení a pokyny jsou celosvětově platné ISO normy řady 19 1XX nebo dokumenty známé jako standardy OGC (Open Geospatial Consorcium), INSPIRE však zavádí některé další specifikace. Technické prováděcí pokyny týkající se služeb nad prostorovými daty jsou publikovány na http://inspire.ec.europa.eu/index.cfm/pageid/761. Infrastruktura INSPIRE disponuje obdobným výčtem typů služeb jako infrastruktura národní, v rámci INSPIRE jsou však služby nad prostorovými daty přesně pojmenovány a specifikovány. Jedná se o služby vyhledávácí (služby, které umožňují vyhledání a zpřístupnění metadat), prohlížecí, stahovací (online nebo formou předpřipravených datových sad), transformační služby a služby umožňující spuštění služeb nad prostorovými daty. Tyto služby jsou pak v rámci infrastruktury INSPIRE rozděleny na harmonizované (nad INSPIRE datovými sadami), interoperabilní (zpřístupňující data v geodetickém referenčním systému ETRS89) a vyhledatelné (popsané metadaty). Uvedené služby nemusí zajišťovat každý poskytovatel sám, pro zajištění povinnosti vůči Směrnici INSPIRE lze využít i nástrojů Národního geoportálu INSPIRE. Vzhledem k rozdílným termínům pro soulad služeb a interoperabilitu prostorových dat zobrazují, s výjimkou ČÚZK, všechny přístupné prohlížecí služby data neharmonizovaná (nekonformní). ČÚZK, jako ústřední správní úřad zeměměřictví a katastru nemovitostí České republiky odpovídající za geodetické systémy závazné na území státu, provozuje i službu transformační umožňující transformaci souřadnic ze systému S-JTSK do ETRS89 s využitím zpřesněných transformačních klíčů.

Zákon 123/1998 Sb. povinuje poskytovatele zpřístupňováním prostorových dat na základě licenčních smluv. Související nařízení Komise (EUS) č. 268/2010 pak určuje termín pro doručení dat a služeb vyžádaných orgány a institucemi EU (20 dní od podání žádosti). Prováděcí pokyny k tomuto nařízení doporučují pro zrychlení komunikace využít pro INSPIRE data a služby dva typy licenčních smluv a to smlouvu základní (pro data bezplatná s účelem užití, ke kterému byl primárně vytvořen i INSPIRE) a specifickou (kde již může být požadována úhrada, účely užití mohou být rozšířeny atd.)

Sdílené agendové IS v přenesené působnosti

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Sdílené agendové informační systémy pro agendy v přenesené působnosti, jako jsou např. Živnostenský rejstřík, Evidence obyvatel, Evidence řidičů a Registr motorových vozidel, budou rozšířeny i na další agendy jejich ohlašovatele tak, že pokud je někdo ohlašovatelem agendy s výkonem v přenesené působnosti, musí zajistit i centrální agendový informační systém (jeho Middle-Office a agendový portál) s možností integrace na lokální systémy úřadů v území.

Pohled na sdílené agendové IS v přenesené působnosti

Sdílené agendové IS pro samostatnou působnost územních samospráv

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Specifická role samosprávy, kdy každý samosprávný celek je autonomní v oblasti samosprávných činností má rozhodující vliv na jakékoliv sdílení v IT. Rozmanitost velikosti municipalit (od krajů po nejmenší obce) má vliv na velikost jejich útvarů, které se zabývají ICT. Nejmenší municipality, které disponují ICT útvary, jsou obce s rozšířenou působností (ORP). Ve správním obvodě ORP je počet subjektů, kterým jsou poskytovány sdílené služby nebo data dostatečně velký, aby sdílení bylo efektivní, a současně počet umožňuje efektivní řízení. Existence útvaru ICT je rozhodující pro poskytování jakéhokoliv sdílení (služby, data). V současné době již řada ORP ve svém správním obvodě tyto služby poskytuje.

Sdílené provozní informační systémy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Další provozní systémy (existující i plánované) budou zahrnuty po zpracování podkladů od věcných správců.

Centrální finanční plánovací a rozpočetnické IS (ERP)

Integrovaný informační systém Státní pokladny (také jako "IISSP") je účinný, transparentní, efektivní a centralizovaný nástroj pro řízení veřejných financí, centralizaci účetních informací státu, konsolidaci vybraných ekonomických ukazatelů za veřejnou správu a komplexní přesné a včasné výkaznictví za celý veřejný sektor v souladu s mezinárodními standardy.

Implementovaný informační systém integruje základní funkční bloky Státní pokladny zaměřené na řízení specifických procesů řízení a kontroly veřejných financí, kterými jsou:

Státní pokladna má před sebou několik možných směrů rozvoje, například integraci na nákupní řešení, na Registr smluv nebo podporu controllingu (nákladové, manažerské účetnictví) veřejné správy.

Monitor Státní pokladny je specializovaný informační portál Ministerstva financí, který umožňuje veřejnosti volný přístup k rozpočtovým a účetním informacím ze všech úrovní státní správy a samosprávy. Prezentované informace pocházejí ze systému Státní pokladny a Centrálního systému účetních informací státu a jsou čtvrtletně aktualizovány. Monitor zahrnuje grafickou webovou část, analytickou část a strojově čitelná zdrojová data.

Centrální registr administrativních budov (CRAB) má vyřešit dosavadní absenci aktuálního celostátního přehledu o administrativních objektech v majetku státu, o jejich obsazenosti a dislokaci státních zaměstnanců. Registr na základě získaných informací umožní maximální využití státních objektů. Ve své činnosti se opírá o Usnesení vlády České republiky ze dne 20. prosince 2012 č. 954 o Centrálním registru administrativních budov.

Informační systém CEDR jako celek je nástrojem zejména pro poskytování, evidenci a kontrolu dotací a pro výkon řady s tím souvisejících agend. Systém se skládá z řady vzájemně provázaných subsystémů, které jsou provozovány na MF- GFŘ, resortech, agenturách a územních orgánech finanční správy.

V informačním systému CEDR jsou shromažďovány údaje o všech dotacích a návratných finančních výpomocích ze státního rozpočtu, státních fondů, státních finančních aktiv a Národního fondu a jejich příjemcích na základě Usnesení vlády č. 584/1997Sb. (subsystém CEDRIII).

  • CEDR - resorty: Údaje jsou do IS CEDR zaznamenávány buď pomocí subsystému CEDR - resorty, který mohou využívat všichni poskytovatelé dotací, nebo prostřednictvím jiných informačních systémů, ve kterých jsou všechny požadované údaje také shromažďovány (např. EDS/SMVS, MSC2007). Předávání údajů do IS CEDR ukládá zákon č. 218/2000 Sb., o rozpočtových pravidlech, §75. Lhůty pro předávání dat a povinné položky stanoví vyhláška č. 296/2005 Sb., o centrální evidenci dotací.
  • CEDR II - Kontrolní útvary FÚ - Všechny údaje, shromážděné v IS CEDR III, jsou předávány do subsystému CEDR II, který využívají kontrolní útvary finančních úřadů. CEDR II proto obsahuje i moduly pro podporu evidence kontrol a vymáhání nedoplatků nebo částek, které mají být vráceny v případě zjištění porušení rozpočtové kázně. Informace o výsledcích provedených kontrol jsou na vyžádání zpřístupněny příslušným poskytovatelům dotací.
  • CEDR III - Veřejnost: Veřejné údaje z databáze CEDR jsou zpřístupněny prostřednictvím subsystému CEDR – web na Internetu MF, který umožňuje i tvorby sestav a výběrů.

ISPROFIN-EDS/SMVS - Informační Systém PROgramového FINancování (ISPROFIN) je manažerský systém pro řízení a kontrolu čerpání položek státního rozpočtu. Dělí se na:

  • EDS - Evidenční Dotační Systém eviduje a řídí poskytování návratných finančních výpomocí a dotací ze státního rozpočtu na pořízení nebo technické zhodnocení dlouhodobého hmotného a nehmotného majetku
  • SMVS - Správa Majetku ve Vlastnictví Státu řídí poskytování prostředků ze státního rozpočtu na pořízení nebo technické zhodnocení hmotného a nehmotného dlouhodobého majetku státu.

MS2014+ - Informační systém MS2014+, oficiální monitorovací systém evropských strukturálních a investičních fondů (ESIF) pro programové období 2014 -2020. Je určen k procesnímu i datovému zabezpečení kompletního řízení a administrativních procesů nad projekty dotačních programů ze strukturálních fondů EU v České republice v programovém období 2014 - 2020.

Funkcionalita systému Monit2014+ pokrývá veškeré základní procesy životního cyklu dotačních programů i v rámci nich realizovaných konkrétních projektů.

Monit2014+ je napojen řadou rozhraní na desítky informačních systémů státní správy České republiky i Evropské unie podílejících se na implementaci dotačních programů EU.

Centrální systém nákupu a veřejných zakázek

Národní elektronický nástroj (NEN), jako klíčový prvek soustavy Národní infrastruktury pro elektronické zadávání veřejných zakázek (NIPEZ), je komplexní elektronický nástroj pro administraci a zadávání veřejných zakázek a koncesí pro všechny kategorie veřejných zakázek a všechny kategorie zadavatelů, vč. sektorových. NEN podporuje všechny rozsahy elektronizace od evidence zadávacích řízení po plně elektronické postupy.

NEN umožní provázání (elektronickou procesní integraci) na interní systémy zadavatelů i dodavatelů či systémy eGovernmentu v ČR. Plně podpoří plánovací aktivity, neboť často bude využíván pro veřejné zakázky realizované v rámci dlouhodobých investičních projektů.

Pro operace relevantní pro Státní rozpočet musí být NEN integrován jak na lokální rozpočetnictví úřadů, tak zejména na RIS-PR a RIS-RE z IISSP.

Uživatelské rozhraní NEN musí být zařazeno do centrálního Portálu úředníka (PÚ), dostupného pro ty OVS, pro něž by bylo nehospodárné budovat svůj lokání PÚ. Dále musí být uzpůsobeno tak, aby jej ostatní OVS jako jednu z mnoha centrálních služeb mohly řady zařadit do svých lokálních Portálů úředníka (Intranet).

Uživatelé NEN se k němu musí přihlašovat pomocí JIP. To znamená klienti VS (dodavatelé) pomocí NIA a úředníci pomocí JIP/KAAS.

Sdílené statistické, analytické a výkaznické systémy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Statistické, analytické a výkaznické systémy systémy (existující i plánované) budou zahrnuty po zpracování podkladů od věcných správců.

eGovernment Cloud

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

eGovernment Cloud (také jako eGC), jehož základním cílem je 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. Z celkového a dlouhodobého pohledu je souvisejícím cílem eGC také konsolidace datových center a ICT platforem veřejné správy.

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 dále upřesňovat standardy eGC a pravidla jeho provozu i využívání.

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 rozdělen do dvou částí - komerční část (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).

Jedním ze dvou hlavních kritérií pro využití služeb SeGC nebo KeGC je úroveň bezpečnostních dopadů daného IS. SeGC zajistí maximální úroveň bezpečnosti a je určen pro provoz služeb eGC bezpečnostní úrovně 4 (Kritická). KeGC je určen pro provoz služeb eGC bezpečnostních úrovní 1-3 (Nízká, Střední, Vysoká) a v maximální míře umožňuje využití tržních mechanismů pro zajištění optimálních cen. 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. K oboum způsobům stanovení bezpečnosti a ekonomické náročnosti vznikly metodické pomůcky dostupné na:

Ří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. ŘOeGC vybuduje a bude spravovat Portál eGC, na kterém bude zveřejňovat Katalogy služeb eGC a poskytovat správcům IS informační a metodickou podporu pro využívání eGC.

Správce eGC zveřejní dynamický nákupní systém (také jako DNS) pro nákup eGC služeb vedených v jeho katalogu. Portál pro objednávání a správu služeb nebude spuštěn spolu s DNS, ale jeho spuštění se dá očekávat v první polovině roku 2020.

V následující fázi budování eGC, dlouhé zhruba dva roky (2021), bude umísťování IS do eGC (využívání služeb eGC) dobrovolné. Dlouhodobě bude uplatněn princip cloud-first – povinné umístění IS do eGC, pokud kalkulace TCO neprokáže nákladově efektivnější provoz onpremise.

Služby eGC budou definovány a popsány v centrálně řízeném Katalogu služeb eGC. Provozovatelé služeb eGC musí splňovat centrálně stanovované bezpečnostní a provozní podmínky. Splnění podmínek bude ověřováno atestačními středisky.

Národní datová centra

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Cílově jsou i NDC nadále nedílnou součástí IKČR, budou se rozvíjet vedle eGC a často dokonce ve stejných prostorách a se stejnými kvalitativními parametry, například bezpečnosti. Jejich role je pro řadu centrálních systémů eGovernmentu nezastupitelná.

Lze předpokládat, že bude společně s požadavky na parametry eGC definován povinný minimální standard pro NDC a že ještě několik resortních DC bude „povýšeno“ na NDC. Současně lze předpokládat, že části některých NDC se zapojí jako významné součásti státní části eGC a budou své služby nabízet vedle přímé dodávky „kmenovým klientům“ - organizacím svého zřizovatele, také volně, komukoli za podmínek eGovernment Cloudu. Národní Datové Centrum jako sdílená služba IT poskytuje:

  • Služby bezpečného prostředí výpočetního centra
  • Služby virtuální výpočetní kapacity
  • Služby databázových serverů
  • Služby datového zálohování
  • Služby vystavení publikovaných služeb v DMZ1 a DMZ2 v CMS KIVS

Komunikační infrastruktura veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

KIVS/CMS je centrální funkční celek, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů státní správy a samosprávy ke službám (aplikacím), které poskytují informační systémy jiných subjektů státní správy a samosprávy s definovanou bezpečností a SLA parametry, tj. přístup ke službám eGovernmentu. KIVS/CMS tak můžeme nazvat privátní sítí pro výkon veřejné správy na území státu. KIVS/CMS jako privátní síť veřejné správy využívá dedikovaných resp. pronajatých síťových prostředků pro bezpečné propojení úředníků orgánů veřejné správy (OVS) pracujících v agendách veřejné správy s jejich vzdálenými agendovými informačními systémy, pro bezpečné síťové propojení agendových systémů navzájem a pro bezpečný přístup jednotlivých OVS do Internetu.

Připojení k CMS je možné realizovat prostřednictvím:

  • Neveřejného KIVS operátora (Krajské sítě, Metropolitní sítě, ITS Ministerstva vnitra a další)
  • Veřejného KIVS operátora (Soutěž KIVS operátora přes centrálního zadavatele MVČR)
  • IPsec VPN
  • SSL VPN

Pro OVS jsou přípustné pouze první 2 varianty - Neveřejný a veřejný KIVS operátor, komunikace mezi jednotlivými OVS je tak vedena výhradně prostřednictvím KIVS/CMS, tzn. jednotlivé OVS mají povinnost přistupovat k informačním systémům veřejné správy (ISVS) pouze prostřednictvím KIVS/CMS.

Pohled na CMS/KIVS

Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady

Tato kapitola popisuje způsoby využívání sdílených služeb, funkčních celků a tematických oblastí v celé šíři (v celé architektuře) včetně pravidel, návodů a dobrých praktik k jejich zanesení do informační koncepce a architektury úřadu. Jde o jiný přístup k popisu požadavků na využívání systémů a služeb eGovernmentu než v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury, kde se požadavky popisují skrze jednotlivé vrstvy architektury úřadu.

Funkční celek je logická struktura obsahující všechny vrstvy architektury (primárně Byznys, Aplikace, Platformy, Komunikace), a který se nejčastěji tvoří kolem informačního systému veřejné správy. Typickým příkladem funkčního celku může být "správa dokumentů". Tento celek kromě samotného informačního systému typu elektronická spisová služba a důvěryhodné úložiště obsahuje i procesy a postupy v úřadu (skartační plán, příjem dokumentů atd.), potřebný HW a SW, komunikační propojení, bezpečnostní požadavky, standardy, pravidla a další. To, že se funkční celek popisuje skrze všechny vrstvy architektury ale neznamená, že jsou jeho nedílnou součástí. Například u vrstvy HW a SW vybavení se počítá s tím, že jde o sdílenou platformu, která není přímo součástí funkčního celku, ale využívá její služby.

Pravidla pro Agendový model veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci agendového modelu veřejné správy je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k agendovému modelu VS popíše úřad do své informační koncepce.

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.

Pravidla pro identifikaci klientů veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci identifikace klientů veřejné správy je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k elektronické identifikaci klientů VS popíše úřad do své informační koncepce.

Fyzická identifikace

Fyzickou identifikací je myšlena situace, kdy klient veřejné správy je osobně přítomen v místě, kde je mu služba poskytována nebo je po něm vyžadována součinnost. K fyzickému prokázání totožnosti se používají identifikační doklady, které musí obsahovat:

  • Aktuální a platné údaje o jeho držiteli
  • Fotografii držitele

Jako identifikační doklad se používá občanský průkaz a cestovní pas. Identifikačním dokladem není řidičský průkaz, protože nesplňuje potřebné parametry při jeho vydávání, ačkoliv obsahuje například fotografii držitele.

Samotný občanský průkaz, který může sloužit i k elektronické identifikaci, lze použít k fyzické identifikaci na různé úrovni:

Fyzická identifikace právnických osob

Pokud jde o právnické osoby v pojetí českého právního řádu, tyto nemohou z jejich povahy nikdy právně jednat samy, musí za ně vždy jednat zástupce, kterým je (byť i nepřímo, např. je-li právnická osoba statutárním orgánem jiné právnické osoby) finálně vždy fyzická osoba (příp. fyzické osoby). Pro použití ve fyzickém prostředí se identifikační prostředky právnických osob v České republice nevydávají. Je tomu tak proto, že právnická osoba není ve fyzickém prostoru přítomna a vždy za ni jedná fyzická osoba, která prokazuje svou vlastní totožnost.

Elektronická identifikace

Elektronickou identifikací je myšlena situace, kdy klient veřejné správy není přítomen v místě poskytování služby. Identifikace tedy probíhá vzdáleně, bez fyzického kontaktu.

Pro jednoznačnou elektronickou identifikaci a autentizaci klientů veřejné správy byl vytvořen technický a právní rámec, který umožňuje všem správcům informačních systémů veřejné správy tuto činnost vykonávat v souladu s Informační koncepcí ČR a bez nutnosti vytváření vlastních nákladných řešení a zvyšování administrativní zátěže.

Zákon č. 250/2017 Sb., o elektronické identifikaci, zavádí v §2 povinnost provádět prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace. Tento paragraf nabývá účinnosti 1. července 2020. Po tomto datu nebude možné pokračovat v praxi vydávání přístupových údajů klientů veřejné správy mimo systémy kvalifikovaného systému elektronické identifikace, pokud jiný zákon tuto cestu neumožňuje.

Podporu celého procesu elektronické identifikace prostřednictvím kvalifikovaného systému elektronické identifikace je vytvořena platforma Národní identitní autority (také jako NIA), která vykonává činnosti Národního bodu dle § 20 a následujících a národního uzlu eIDAS pro spolupráci s oznámenými systémy elektronické identifikace dle nařízení Evropské parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES.

Elektronická identifikace právnických osob

Pokud jde o právnické osoby v pojetí českého právního řádu, tyto nemohou z jejich povahy nikdy právně jednat samy, musí za ně vždy jednat zástupce, kterým je (byť i nepřímo, např. je-li právnická osoba statutárním orgánem jiné právnické osoby) finálně vždy fyzická osoba (příp. fyzické osoby). Z toho plyne, že ustanovení § 2 zákona o elektronické identifikaci, které dopadá na případy fyzických osob, se tak vztahuje i na jednání právnických osob, neboť jsou to vždy fyzické osoby, které fakticky jednají, ať již za sebe, či za jinou fyzickou osobu nebo právnickou osobu.

V elektronickém prostředí, zejména jde-li o automatizovanou komunikaci, jsou nicméně používány mechanismy, které mají charakter identifikačního prostředku právnické osoby. Jde např. o certifikát pro evidenci tržeb podle zákona č. 112/2016 Sb., o evidenci tržeb, nebo certifikáty vydané Českou národní bankou pro automatizovanou komunikaci mezi ČNB a subjekty podléhající jejímu dozoru, typicky bankami. Platí nicméně, že identifikační prostředky právnických osob s použitím bez ohledu na agendy, ekvivalentní např. občanským průkazům, se v České republice nevydávají.

Zatímco samotná autentizace fyzické osoby není problematická, problematická se jeví otázka určení, zda fyzická osoba jedná v dané situaci za sebe (popř. v jaké roli za sebe) anebo zda jedná za jinou fyzickou osobu nebo za právnickou osobu. Problematika mandátů a oprávnění je řešena níže.

Skutečnost, že daná fyzická osoba, má právo se identifikovat a autentizovat za určitou právnickou osobu (tj. „přihlásit se ke službě jménem právnické osoby“), ještě nezakládá bez dalšího právo na to, že tato fyzická osoba má právo za danou právnickou osobu činit úkony prostřednictvím digitální služby. Autorizaci dané fyzické osoby k poskytnutí digitální služby musí posoudit ten, ke komu se fyzická osoba hlásí na základě jím dostupných údajů (informace z obchodního rejstříku, plná moc opravňující konkrétní osobu jednat jménem právnické osoby,…) ve spojení s příslušnými právními předpisy.

Jako příklad takového přístupu můžeme uvést datové schránky, do nichž se fyzická osoba přihlásí například novým občanským průkazem s aktivovaným čipem. Po úspěšné autentizaci s pomocí prostředku pro elektronickou identifikaci (tj. např. s pomocí „eObčanky)“ a souhlasu s předáním osobních údajů na portálu Národního bodu pro identifikaci a autentizaci, je fyzická osoba pro účely informačního systému datových schránek (ISDS) ztotožněna. Po ztotožnění tak nabídne ISDS fyzické osobě seznam datových schránek, ve vztahu k nimž je přihlášená fyzická osoba oprávněná jednat.

Autentizovaná fyzická osoba si tedy vybírá, za koho a v jaké roli bude prostřednictvím datových schránek jednat. Informaci o tomto oprávnění si ISDS obstarává např. z ROS, z jiných zdrojů (např. údaj o tom, že určitá osoba je advokátem nebo insolvenčním správcem) anebo jej vede na základě sdělení samotného držitele datové schránky (např. údaj o tzv. pověřené osobě). Bez ohledu na zdroj informace o oprávnění k zastupování jiné osoby, resp. na zdroj informace o roli je však na samotném ISDS jakožto poskytovateli služeb, aby oprávnění k zastupování jiné osoby ve svém prostředí řádně implementoval tak, aby osoby mohly toto oprávnění realizovat. Nabídka jednotlivých oprávnění, resp. rolí, tedy spadá do kompetence daného poskytovatele služeb a odvíjí se od údajů a oprávnění, které vede v rámci svého informačního systému nebo od údajů, ke kterým má přístup.

Mandáty, role a práva v elektronické komunikaci

Zajištění správné obsazení do role neboli autorizace, klienta využívajícího elektronické služby je jedním ze základních předpokladů jejího správného fungování. Různé role mají v rámci služby různá oprávnění a povinnosti a poskytovatel služby je povinen nabídnout klientovi veškeré role, do kterých se v rámci služby může pasovat, včetně rolí jako zástupce právnické osoby, zástupce nezletilého, registrující lékař pacienta a další. Tyto role s oprávněními vůči jiným klientům veřejné správy jsou mandáty. Aby proběhlo správné obsazení do role a zjištění mandátu, je pro poskytování elektronických služeb klientům veřejné správy nutné mít zajištěno několik základních náležitostí:

  1. Znalost typů mandátů při jednání s veřejnou správou
  2. Jednoznačnou identifikaci a autentizaci klienta veřejné správy
  3. Systém veřejné správy schopný komunikovat a získávat údaje z propojeného datového fondu
  4. Vlastní zajištění autorizace klienta veřejné správy
Mandáty pro jednání s veřejnou správou

Při výkonu veřejné správy a to zejména při jakékoliv interakci a komunikaci s klientem veřejné správy je nutné, aby veřejná správa respektovala mandáty k zastupování jedné osoby druhou na základě různých titulů. Zjednodušeně se dá rozdělit forma mandátu zastupování dle následující tabulky.

Typ subjektu Mandát
Fyzická osoba Jednající sama svým jménem
Jednající jménem jiné fyzické osoby ze zákona:
- rodič dítěte,
- manžel/manželka,
- registrovaný partner/partnerka,
- opatrovník
Jednající jménem jiné fyzické osoby ze zmocnění:
- plná moc,
- advokát,
- zastupující FO,
- jiný druh zmocnění,
- na žádost bez zmocnění
Plná moc opravňující konkrétní osobu jednat jménem právnické osoby
Fyzická osoba jednající za právnickou osobu Jednatel právnické osoby
statutární zástupce právnické osoby (jedna FO)
Statutární orgán právnické osoby (více FO)
Insolvenční správce
Likvidátor
Jednající jménem zřizovatele právnické osoby
Pověřen k jednání za právnickou osobu:
- Veřejnoprávním titulem,
- Soukromoprávním titulem (smlouva, plná moc, společenská smlouva, apod.)
Pokud agendový předpis povoluje využívání přístupových údajů k systému datových schránek jako identifikačních prostředků je to dále:
a) Pro fyzické osoby – statutární zástupce oprávněné k přístupu do datové schránky právnické osoby ověřením oprávnění k datové schránce právnické osoby prostřednictvím Informačního systému datových schránek (ověření přístupových údajů a oprávnění).
b) Pro fyzické osoby - oprávněné statutárním zástupcem k přístupu do datové schránky právnické osoby ověřením oprávnění k datové schránce právnické osoby prostřednictvím Informačního systému datových schránek (ověření přístupových údajů a oprávnění).
c) Ověřením speciálního agendového oprávnění podle agendového předpisu, na jehož základě jsou poskytovány agendové digitální služby.

Jak je zdůrazněno níže, při výkonu veřejné správy je nutné, aby příslušný orgán konající nějakou činnost v rámci dané agendy věděl, pro jakou formu zastupování je mandát umožněný nebo dokonce nutný. Zcela jiným způsobem se orgán veřejné moci bude chovat k mandátu plynoucímu z veřejnoprávního titulu rodičovství a jinak k mandátu plynoucímu ze soukromoprávního titulu plné moci.

Je také vhodné rozlišovat účel mandátu, tedy typ úkonů, které prostřednictvím zastupované osoby klient veřejné správy dělá. Ty je možno rozdělit do následujících skupin:

  • Nahlížení na údaje subjektů práva bez jakéhokoliv interaktivního využívání či zapisování údajů (informační účel).
  • Přístup k údajům subjektů a jejich reklamace, nebo pokud je přímo umožněna editace klientům veřejné správy (transakční účel).
  • Zmocnění k přístupu či využívání údajů subjektu práva pro třetí strany, nebo poskytnutí údajů z ISVS třetím stranám (zmocňovací účel).
  • Činění podání a úkonů vůči orgánům veřejné správy (účel úkonu).
  • Využívání elektronických klientských služeb jako je objednání se k úředníkovi.
  • Zápis, úprava a zrušení mandátu.
Jednoznačná identifikace a autentizace klienta veřejné správy

Všechny subjekty povinné dle zákona č. 250/2017 Sb., o elektronické identifikaci mají povinnost dle §2 využívat k prokázání totožnosti při elektronickém kontaktu pouze kvalifikovaný systém, konkrétně:

„Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace.“

Kvalifikovaný systém spravuje kvalifikovaný správce (státní orgán nebo akreditovaná osoba) a splňuje technické normy i specifikace Evropské unie a především je propojen s národním bodem pro identifikaci a autentizaci – tzv. Národní identitní autorita (NIA).

Identifikace a autentizace prostřednictvím NIA zajistí jen a pouze službu ověřené identity fyzické osoby, neboli každý systém čerpající služby NIA, se může spolehnout na to, že přihlášená fyzická osoba je skutečna ta, za kterou se vzdáleně a elektronicky vydává. Již se dále nezajišťují další služby typu autorizace.

Systém veřejné správy schopný komunikovat a získávat údaje z propojeného datového fondu

Systém poskytující elektronické služby veřejné správy musí být schopen komunikovat a získávat údaje z propojeného datového fondu. K tomu musí systém odpovídat předpisům:

  • Zákon 365/2000 Sb., o informačních systémech veřejné správy. Systém klasifikovaný jako Informační systém veřejné správy (ISVS) využívající referenční rozhraní veřejné správy.
  • Zákon 111/2009 Sb., o základních registrech. Systém klasifikovaný jako agendový informační systém (AIS) využívající údaje základních registrů a editorů základních registrů dle svého agendového zákona.
  • Zákon 250/2014 Sb., o elektronické identifikaci. Systém, který vyžaduje ověření totožnosti
  • Nařízení eIDAS

Více o využívání údajů propojeného datového fondu a infrastruktuře referenčního rozhraní je napsáno v kapitolách:

Centrální sdílené služby eGovernmentu dokáží zajistit následující mandáty pro fyzické osoby, které se prokázaly u poskytovatele služeb svou zaručenou elektronickou identitou:

  • eGON služba rosCtiPodleUdaju, rosCtiIco, rosCtiAifo (základní registr osob)
    • pro zajištění ověření, zda je fyzická osoba statutárním zástupcem
  • eGON služba aiseoCtiPodleUdaju, aiseoCtiAifo (agendový informační systém evidence obyvatel)
    • pro zajištění ověření, zda je fyzická osoba rodič nezletilého, který není svéprávný
    • pro zajištění ověření, zda je fyzická osoba zákonným zástupcem jiné fyzické osoby
    • pro zajištění ověření, zda je fyzická osoba opatrovníkem jiné fyzické osoby
    • pro zajištění ověření, zda je fyzická osoba manžel/manželka
  • eGON služba isknCtiVlastniky (informační systém katastru nemovitostí)
    • pro zajištění ověření, zda je fyzická osoba vlastníkem nemovitosti
  • Služba ISDS
    • Pro zajištění, zda je fyzická osoba pověřená k činění úkonů v ISDS vlastníkem datové schránky

Žádné další centrální služby ověření oprávnění/mandátů se v současné, ani dohledné době, neplánují. Proto je důležité, aby si každý poskytovatel elektronických služeb zajistit jiné typy mandátů sám.

Vlastní zajištění autorizace klienta veřejné správy

Každá vykonávaná agenda (výkon veřejné správy) může pro svoji potřebu vyžadovat jiné mandáty. Například mandát podání daňového přiznání za jinou fyzickou osobu, mandát nahlížení na zdravotnickou dokumentaci jiné fyzické osoby, nakládání s majetkem právnické osoby, u které nejsem statutární zástupce, či například mandát k zastupování při dědickém řízení.

Všechny tyto mandáty se musí řešit v rámci dané agendy a jako ideální řešení navrhujeme:

  • Zřídit buď v jednotlivých agendových informačních systémech, nebo v rámci centralizované správy subjektů mandátní registr.
  • V rámci mandátního registru určit předem definované typy mandátů přípustné v dané agendě a způsob zápisu mandátů pro nahlížení a pro transakce ze strany klienta
  • Povolit zapisovat všem klientům mandáty dle definovaných typů pod svou zaručenou elektronickou identitou.
  • Umožnit klientům přidat mandát i offline, například na přepážce úřadu.
  • Při každém přihlášení klienta kontrolovat kromě mandátů z centrálních sdílených služeb eGovernmentu i vlastní mandátní registr a dát vždy při přihlášení vybrat klientovi, v jaké roli a s jakým mandátem chce pracovat.

Je důležité zdůraznit, že veřejná správa nemá rozlišovat formu komunikace a jednání s klientem. Tedy mandát obecně platící pro osobní jednání s úředníkem, nebo pro fyzické prováděné úkony na přepážce, musí mít klient umožněn využívat i při elektronické komunikaci a naopak. Také proto je nutné vést mandáty standardizovanou formou na jednom místě a využívat jich i při elektronické komunikaci klienta.

Mandát plynoucí z veřejnoprávního nebo soukromoprávního titulu a to včetně plných mocí a dohod o zastupování při správním jednání s úřady patří mezi společné rozhodné skutečnosti, tak jak jsou zakotveny v souvisejících ustanoveních Správního řádu (zejména § 6 a § 50 a související). Proto je nanejvýš vhodné, aby příslušný orgán veřejné moci, pokud

  • využívá a buduje centrální evidenci subjektů,
  • centrální evidenci rozhodných skutečností,
  • skutečnosti o zapsaném anebo z něčeho plynoucím mandátu k zastupování,
  • je zahrnul do rozhodných skutečností.

Klient se totiž může odvolat na příslušná ustanovení správního řádu a neposkytovat zejména plné moci a další dokumenty, z nichž mandát plyne, úřadu opakovaně.

Pravidla pro Propojený datový fond

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci propojeného datového fondu je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k propojenému datovému fondu popíše úřad do své informační koncepce.

Údaje, dokumenty, výstupy a výpisy

Těžištěm pro správné využívání a pochopení smyslu propojeného datového fondu je porozumění rozdílu mezi Poskytováním/Využíváním údajů, Poskytováním/Využíváním dokumentů, Výstupům z informačního systému a Výpisem z informačního systému.

Poskytování / Využívání údajů

Na business vrstvě orgán veřejné moci, který provádí výkon veřejné správy, působí v agendě, kterou má řádně ohlášenou v RPP, má povinnost využívat pro tyto účely aktuální státem garantovaná data ze ZR a dále publikovat a čerpat agendové údaje přes eGon Service Bus / Informační systém sdílené služby. Soukromoprávní subjekt práva (také jako SPUU) může také za dodržení zákonného zmocnění pro výkon veřejné správy a působení v určité agendě ohlášené OVM, čerpat údaje ze základních registrů, ovšem výhradně přes AIS OVM nebo formuláře Czech POINT. V zákoně č. 111/2009 Sb. - Zákon o základních registrech, bude nově zakotveno globální zmocnění na čerpání údajů OVM ze ZR, přičemž RPP slouží jako zdroj informací pro informační systém ZR při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. To znamená, že kdykoliv se daný subjekt pokusí získat určitý údaj, nebo ho dokonce změnit (editovat), systém posuzuje, zda subjektu bude dovolené na základě zákonného zmocnění pracovat s údaji poskytované veřejnou správou. V RPP jakožto metainformačním systému výkonu veřejné správy jsou uvedeny oprávnění v rámci agend pro čerpání údajů ze ZR, ale také veškeré údaje, které stání správa a samospráva publikuje za pomocí eGon Service Bus / Informační systém sdílené služby napříč veřejnou správou. Důležitým faktorem na business vrstvě v rámci čerpání údajů ze ZR a také publikování a čerpání údajů v rámci jednotlivých AIS OVM je mít řádně hlášenou agendu v RPP, což je nezbytnou podmínkou.

Seznam agend vedených v RPP je k dispozici na stránkách: https://rpp-ais.egon.gov.cz/gen/agendy-detail/

Na aplikační vrstvě, prostřednictvím webových služeb jednotlivých referenčních rozhraní, ke kterým patří informační systém správy základních registrů, eGon Service Bus / Informační systém sdílené služby, služby Czech POINT a formulářového agendového informačního systému FAIS, má povinnost instituce čerpat referenční údaje ze ZR svými AIS a dále poskytovat a využívat údaje přes IeGon Service Bus / Informační systém sdílené služby napříč veřejnou správou. Dále je možné čerpat referenční údaje ze ZR i přes datové schránky.

Jedním z pravidel získávání referenčních údajů webovými službami je nejdříve ztotožnit svůj datový kmen vůči ZR a následně se přihlásit pro příjem notifikací o změnách. Další možností, ovšem v krajních případech, pokud datový kmen instituce není příliš rozsáhlý, je možné provádět pravidelnou aktualizaci údajů celého datového kmene pro ztotožnění subjektu práva práva při výkonu veřejné správy.

Dalším pravidlem pro nakládání s osobními údaji je pseudonymizace údajů, což znamená uložení dat technikou oddělení agendových a identifikačních údajů a jejich propojení pomocí agendového identifikátoru fyzických osob (také jako AIFO), aby byly naplněny podmínky bezpečnosti a jednotlivých zákonů a nařízení, které z těchto okolností plynou. Získané AIFO nesmí za žádných okolností opustit AIS, které ho ze služeb ISZR získalo a při jeho předávání (za účelem předávání informací o fyzické osobě) se musí vždy použít služeb ISZR. Více informací o způsobu využití AIFO v rámci pseudonymizace je uvedeno zde.

Z pohledu technologické vrstvy, je čistě na jednotlivé instituci, jakou si zvolí platformu v rámci vnitřního fungování úřadu a připojení se pro využívání služeb propojeného datového fondu, přičemž přistupovat do ZR je možné přes ISZR přímo AISem nebo komunikační sběrnicí.

Na komunikační vrstvě je povinnost instituce při výkonu veřejné správy využívat CMS. CMS je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů veřejné správy ke službám (aplikacím), které poskytují informační systémy jiných subjektů veřejné správy s definovanou bezpečností a SLA parametry, tj. přístup ke službám eGovernmentu. CMS tak můžeme nazvat privátní sítí pro výkon veřejné správy na území státu. CMS jako privátní síť veřejné správy využívá dedikovaných resp. pronajatých síťových prostředků pro bezpečné propojení úředníků orgánů veřejné správy (také jako OVS) pracujících v agendách veřejné správy s jejich vzdálenými agendovými informačními systémy, pro bezpečné síťové propojení agendových systémů navzájem a pro bezpečný přístup jednotlivých OVS do Internetu.

Poskytování / Využívání dokumentů

Dokumenty se přenáší skrze referenční rozhraní ve vazbě na subjekt či objekt práva prostřednictvím eGON Service Bus / Informačního systému sdílené služby, nebo také prostřednictvím informačního systému datových schránek. Dokumenty se tvoří výstupem z informačního systému veřejné správy dle zákona č.365/2000 Sb.

Výpisy z informačního systému veřejné správy

Výpis z informačního systému veřejné správy je dokument, který se vytváří se z veřejných i neveřejných evidencí. Výpis může mít podobu částečného nebo plného výpisu ze všech údajů, které se v informačním systému veřejné správy vedou.

  • Výpis z veřejné evidence: Výpis není určen pro konkrétní osobu a všechny obsažené informace jsou veřejné.
  • Výpis z neveřejné evidence: Výpis je určen pro konkrétní osobu, která je subjektem práva nebo jinou oprávněnou osobu a obsahuje i neveřejné údaje.

Výpisy se tvoří dle zákona č. 365/2000 Sb.

Výstupy z informačního systému veřejné správy

Výstup z informačního systému veřejné správy je elektronický dokument, který je výpisem z informačního systému veřejné správy, ale je zároveň zabezpečen způsobem zajišťující integritu dat. Tedy je to takový výpis z informačního systému veřejné správy, který je vydávajícím informačním systémem veřejné správy elektronicky opečetěn/podepsán a oražen časovým razítkem.

Existuje i speciální varianta výstupu z informačního systému veřejné správy, tzv. ověřený výstup, který vznikne úplným převodem výstupu z informačního systému veřejné správy z elektronické do listinné podoby a obsahuje náležitosti dle zákona č.365/2000 Sb.. Ověřený výstup je tedy vždy v listinné podobě.

Veřejná listina

Veřejná listina je dle občanského zákoníku listina vydaná orgánem veřejné moci v mezích jeho pravomoci nebo listina, kterou za veřejnou listinu prohlásí zákon. Je-li nějaká skutečnost potvrzena ve veřejné listině, zakládá to vůči každému plný důkaz o původu listiny od orgánu nebo osoby, které ji zřídily, o době pořízení listiny, jakož i o skutečnosti, o níž původce veřejné listiny potvrdil, že se za jeho přítomnosti udála nebo byla provedena, dokud není prokázán opak. Zachycuje-li veřejná listina projev vůle osoby při právním jednání a je-li jednajícím podepsána, zakládá to vůči každému plný důkaz o takovém projevu vůle. To platí i v případě, že byl podpis jednajícího nahrazen způsobem, který stanoví zákon.

Veřejnou listinou jsou všechny:

  • listinné výpisy z informačního systému veřejné správy,
  • výstupy z informačního systému veřejné správy,
  • ověřené výstupy z informačního systému veřejné správy.

Pravidla pro Veřejný datový fond

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci veřejného datového fondu je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k veřejnému datovému fondu popíše úřad do své informační koncepce.

VDF je tvořen otevřenými daty poskytovanými jednotlivými OVS za účelem sdílení s dalšími OVS a je podmnožinou všech otevřených dat VS. Je tedy nutné zajistit, aby všechny funkční celky architektury jednotlivých úřadů VS respektovaly a dodržovaly pravidla platná pro:

  • otevřená data (legislativně podpořená zákonem č.106/1999 Sb.),
  • data VDF - pravidla pro otevřená data navíc doplněná o další specifika odvozená od charakteristik VDF.

Otevřená data

Otevřená data jsou:

  • Volně přístupná na webu jako datové soubory ke stažení ve strojově čitelném a otevřeném formátu - CSV, XML, JSON, RDF (JSON-LD, Turtle, …) a další formáty s otevřenou specifikací.
  • Opatřená podmínkami užití neomezujícími jejich užití.
  • Evidovaná v Národním katalogu otevřených dat (NKOD) jako datové sady opatřené přímými odkazy na datové soubory, které je tvoří.
  • Opatřená úplnou dokumentací.
  • Opatřená kontaktem na kurátora pro zpětnou vazbu (chyby, žádost o rozšíření, apod.).
  • Jsou publikovány dle otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím.

Využívání otevřených dat při výkonu veřejné správy

Nejsou stanovené žádné požadavky na způsoby použití publikovaných otevřených dat, data lze libovolně importovat do vhodných aplikací a informačních systémů. Publikovaná data jsou zpřístupněna prostřednictvím NKOD (POD) a lze je získat jako soubory s datovými sadami. K datům lze také přistupovat s využitím aplikací třetích stran, které příslušné data využívají.

Publikace otevřených dat

Příprava ISVS pro export otevřených dat

Zásadní je zajištění přístupu k datům IS. Provozovaný IS tedy musí:

  • umožňovat přístup k databázi nebo
  • mít možnost stahovat volitelně strukturovaná data (tabulky) z reportingového modulu systému, nebo
  • nabídnout API, ze kterého se dají pravidelně získávat kompletní data v podobě datových souborů.

Vhodné otevřené formáty:

  • tabulková data - CSV, XML, JSON, RDF (JSON-LD, Turtle, …),
  • hierarchická data - XML, JSON, RDF (JSON-LD, Turtle, …),
  • grafová data - RDF (JSON-LD, Turtle, …),
  • geodata(prostorová data) - GeoJSON, ESRI Shapefile, OGC GML, OGC GeoPackage.

Struktura dat musí být zdokumentována lidsky čitelným dokumentem, ale také strojově čitelným schématem. Doporučené jazyky pro definici schémat schémata:

  • CSV - schéma CSV on the Web,
  • XML - XML Schema,
  • JSON - JSON schema,
  • RDF - RDFS, OWL, SHACL

Při dodržení výše uvedených bodů jsou získaná kompletní data z IS připravena k publikaci formou otevřených dat.

Export dat nebo API v proprietárním formátu

Pokud se jedná o rozšíření existujícího IS, který neumožňuje export dat nebo nenabízí API ve strojově čitelném a otevřeném formátu a takovou úpravu nelze v IS provést, využije se stávající export či API, které již systém nabízí (např. do MS Excel), a tento výstup se dále zpracuje do otevřeného formátu pomocí dalších nástrojů tak, aby bylo dosaženo stavu jako v případě přímého exportu do otevřeného formátu.

Závěrečná příprava dat k publikaci v podobě otevřených dat

Data získaná z IS jedním z popsaných způsobů je následně třeba publikovat jako otevřená data. To znamená minimálně:

  1. V případě API zajistit jeho vytěžení pro získání kompletních dat k publikaci (tj. případná přímá publikace API nenaplňuje podmínky otevřených dat)
  2. Zajistit pravidelnou aktualizaci získaných dat (dle charakteru dat to může být ve frekvenci např. denně, měsíčně nebo ročně)
  3. Publikovat získaná data na web ke stažení a následně publikovat každou jejich aktualizaci
  4. Opatřit je dokumentací, podmínkami užití a kontaktem na kurátora
  5. Katalogizovat je v Národním katalogu otevřených dat (NKOD)

K tomu lze využít nástrojů pro přípravu, publikaci a katalogizaci otevřených dat, jako je třeba LinkedPipes ETL. Publikace otevřených dat by měla být zajištěna koncepčně na úrovni celé organizace. Kompletní postupy jsou k dispozici na POD, včetně vyžadovaných standardů.

Data VDF

Otevřená data ve VDF

Ve VDF jsou poskytována otevřená data, která jsou určena mj. k využití jinými OVS při výkonu veřejné správy i mimo jejich rozsah práv a povinností zachycených v RPP. Nad rámec otevřených dat platí pro otevřená data ve VDF následující:

  • Pokud OVS využívá data z VDF, považuje je za správná a nemusí ověřovat jejich správnost.
  • Poskytovatel dat do VDF garantuje správnost, kvalitu, aktuálnost a pravidelnou aktualizaci údajů publikovaných ve VDF.
  • Poskytovatel dat do VDF zajišťuje automatickou notifikaci všech změn v údajích publikovaných ve VDF zaregistrovaným zájemcům s využitím funkcionality Portálu otevřených dat.

Využívání otevřených dat z VDF při výkonu veřejné správy

Při výkonu veřejné správy může OVS potřebovat údaje jiných OVS, kterým ale nemá přístup v rámci rozsahu stanoveného v RPP. Pokud se jedná o veřejné údaje, přistupuje k nim prostřednictvím VDF. Jsou-li data ve VDF dostupná, není žádný jiný způsob přístupu k datům a sdílení dat povolen. Typicky jsou data z VDF využívána následujícím způsobem:

  • ruční vyhledání potřebných datových sad v NKOD a zjištění odkazů ke stažení dat,
  • nastavení skriptů k pravidelnému importu nalezených datových sad do vlastního IS ze zjištěných odkazů,
  • import datových sad do IS VS,
  • registrace v Notifikačním hubu k pravidelnému a strojovému získávání aktualizací,
  • nastavení skriptů k importu změn získaných z Notifikačního hubu do IS VS.

Publikace otevřených dat do VDF

Pro publikaci otevřených dat do VDF platí stejná pravidla jako pro publikaci otevřených dat uvedená výše. Navíc musí být dodržená následující pravidla:

  • Publikovaná data jsou popsána sémantickým slovníkem pojmů, který je vytvořen na základě údajů v RPP. Popis dat sémantickým slovníkem pojmů je vytvořen a publikován dle otevřené formální normy “Popis dat sémantickým slovníkem pojmů”. Sémantický slovník pojmů je tvořen a publikován dle otevřené formální normy “Sémantický slovník pojmů”.
  • K identifikaci entit, o nichž jsou publikovány údaje ve VDF, jsou použita IRI dle otevřené formální normy “Propojená data”.
  • V publikovaných datech se nepublikují duplicitní údaje s již publikovanými údaji ve VDF. V případě, že OVS publikuje údaje o entitě, o níž již publikuje ve VDF údaje jiný OVS, publikuje OVS pouze nové doplňující údaje k této entitě. V případě, že zavádí vlastní IRI k identifikaci entity než jiný OVS, propojí vlastní IRI s původním dle otevřené formální normy “Propojená data”.
  • Souvislosti mezi entitami v datech stejného poskytovatele i různých poskytovatelů jsou reprezentovány dle otevřené formální normy “Propojená data”. Poskytovatel údajů ve VDF se snaží maximálně propojit entity, o nichž publikuje údaje, na entity, o nichž publikují údaje jiné OVS.

Údaje povinně zveřejňované ve VDF

Ve VDF jsou jako otevřená data povinně zveřejňovány následující údaje:

Poskytovatel zveřejňující údaje ve VDF Zveřejňované údaje Způsob zveřejnění
Český statistický úřad Číselníky zavedené sdělením ve Sbírce zákonů Dle OFN Číselníky
Ohlašovatel agendy ve smyslu § 48 písm. f) zákona č. 111/2009 Sb. o základních registrech Číselníky kódující údaje uvedené v registru práv a povinností dle § 51 odst. 5 písm. h) zákona č. 111/2009 Sb., o základních registrech. Ohlašovatel agendy číselník zveřejňuje ve VDF, pokud již číselník nezveřejňuje Český statistický úřad nebo jiný ohlašovatel.Dle OFN Číselníky

Společná pravidla pro otevřená data i data VDF

Organizační a procesní zajištění publikace dat

Zapojení VDF do výkonu veřejné správy vyžaduje publikaci skutečně právně závazných, platných a pravidelně aktualizovaných datových sad s jasně definovanou zodpovědností OVS za takové sady. Publikující organizace musí pro splnění uvedených požadavků realizovat vhodná organizační opatření, přiřadit pracovníkům příslušné procesní role a implementovat činnosti publikačních procesů do pracovních náplní pracovníků. Jako minimum je vyžadováno přiřazení těchto klíčových procesních rolí:

Koordinátor otevírání dat, do jehož kompetencí a povinností spadá:

  • zajištění součinnosti a kontroly výstupů všech ostatních rolí, které se na otevírání dat podílejí,
  • komunikace se všemi zapojenými pracovníky do publikace dat,
  • externí komunikace s uživateli otevřených dat VS,
  • komunikace a spolupráce s Národním koordinátorem otevřených dat,
  • komunikace s Datovou kanceláří a s příslušným Chief data officer (CDO).

Kurátor dat - klíčová role pro:

  • zajištění kvality, správnosti, aktuálnosti a tím i právní závaznosti dat konkrétní agendy,
  • publikaci datových sad v souladu s platnými právními předpisy ČR a Standardy publikace a katalogizace otevřených dat VS ČR.

Kompletní doporučení, vhodné vzory interních dokumentů, všechny navržené procesní role a standardní publikační procesy jsou uvedeny na Portále otevřených dat.

Ochrana osobních údajů

Pokud jsou předmětem evidence informačního systému osobní údaje ve smyslu zákona č. 110/2019 Sb., o zpracování osobních údajů a nařízení (EU) č. 2016/679, Obecné nařízení o ochraně osobních údajů (GDPR), neznamená to, že nelze ze systému publikovat otevřená data. V těchto případech platí následující doporučení.

  1. V případě, že se jedná o veřejnou evidenci či rejstřík a zvláštní právní předpis nařizuje zveřejnění informací, lze zveřejnit osobní údaje v podobě otevřených dat.
  2. Ochranu osobních údajů lze zajistit Anonymizací či Pseudonymizací. Z dat se odstraní osobní údaje a případně se nahradí bezvýznamovým umělým identifikátorem. Data bez osobních údajů se pak mohou zveřejnit v podobě otevřených dat. V závislosti na charakteru dat je ale nutné zkontrolovat, zda data ve své kombinaci neumožňují identifikaci konkrétní osoby i po odstranění zjevných osobních údajů. Může se jednat o kombinace typu město, věk a pohlaví a podobné.
  3. Data, která není možné nebo vhodné zveřejnit dle předchozího bodu, lze zveřejnit v agregované podobě. Tedy v podobě statistik. V případě zveřejnění statistik je ale žádoucí použít co nejjemnější granularitu dat a časové členění.

Právní aspekty

Legislativní rámec otevřených dat v České republice tvoří jejich úprava obsažená v Zákoně č. 106/1999 Sb., o svobodném přístupu k informacím a v Nařízení vlády č. 425/2016 Sb., o seznamu informací zveřejňovaných jako otevřená data, které stanovuje vybraným orgánům veřejné správy povinnost zveřejňovat data z konkrétních jimi spravovaných informačních systémů ve formě otevřených dat. Podrobnější informace o strategických dokumentech, akčních plánech a souvisejících předpisech ČR i EU jsou k dispozici v aktualizované podobě na stránkách Portálu otevřených dat (POD).

Pravidla pro Evidenci subjektů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci agendového modelu veřejné správy je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k agendovému modelu VS popíše úřad do své informační koncepce.

Principy pro využívání jednotlivých identifikátorů

Jako identifikátor fyzické osoby (a potažmo i právnické, protože za právnickou osobu vždy jedná fyzická osoba), se v různých agendách používají různé druhy identifikátorů, a to jak pro účely vnitřních procesů a služeb (uvnitř úřadu), tak i při výměně údajů (ven z úřadu). Identifikátory subjektů se využívají při úřední komunikaci a interakci s klientem, při evidenci údajů v příslušných informačních systémech a ve spisové dokumentaci a při výměně údajů s dalšími informačními systémy.

Při evidenci subjektů v datovém kmenu úřadu

Cílem PPDF a pseudonymizace je zavést jednotnou formu identifikace subjektu při jeho evidenci. Nelze nadále využívat dosud zneužívané persistentní identifikátory, ale je naopak nutné rychle se přizpůsobit povinnostem pseudonymizace. Proto je nutno respektovat níže uvedené základní principy pro evidenci subjektů:

  1. Identifikátorem pro komunikaci mezi jednotlivými agendovými informačními systémy je vždy AIFO (AIFO se překládá přes služby ISZR a ISSS).
  2. AIFO se nikdy v systému nezobrazí a úředník k němu nesmí mít žádný přístup.
  3. Úředním/klientským identifikátorem fyzické osoby nesmí být AIFO, ale vždy klientské číslo pro danou agendu, které přidělí správce dané agendy a které se využívá jako prezentovaný identifikátor v AISu a pro úředníka. Tento identifikátor musí být bezvýznamový, nelze tedy z něj odvodit další osobní údaje fyzické osoby. Agenda přidělující klientský identifikátor musí poskytovat služby pro jeho získání na základě stykového identifikátoru či AIFO a zpět. Současně řídí oprávnění k použití takové služby.
  4. Při komunikaci s klientem (osobní jednání na přepážce i zpracování doručených dokumentů a zpráv) se využívají stykové identifikátory, jako jsou typ a číslo dokladu a využije se služba jednorázového překladu na AIFO a služby vydavatele klientského identifikátoru pro získání tohoto identifikátoru.
  5. Stykové identifikátory si primárně neeviduji, leda by byly zároveň klientským číslem.
  6. AIFO osoby se nikdy nesmí přímo poskytnout, vždy se využívá služeb překladu z mého AIFO na AIFO příjemce výměny údajů.
  7. Pokud k tomu nejsou specifické důvody, tak při výměně údajů se vyměňuje pouze AIFO a nepřidávají se další identifikátory nebo údaje.

Služby pro překlad aktuálního stykového identifikátoru musí být poskytovány s úrovní dostupnosti kritická – jedná se o ztotožnění osoby. Vydavatel či správce stykového identifikátoru musí zajistit jeho historickou jednoznačnost a služby zajišťující překlad na AIFO i pro historické hodnoty identifikátoru (pro historické hodnoty je požadovaná úroveň dostupnosti – primární služba).

Při interakci s klientem

Při osobním jednání s klientem nebo při jeho prezenčním ztotožnění se využije typ a číslo dokladu, který klient předložil, nebo jinak ověřený stykový identifikátor.

  • Klient předloží doklad s uvedeným identifikátorem, který je stykovým identifikátorem.
  • Prostřednictvím daného AIS se zavolá služba jednorázového ztotožnění osoby přeložením stykového identifikátoru na dané AIFO v jeho agendě.
  • Dále úředník pracuje v AIS podle AIFO subjektu (které sám na obrazovce nevidí), stykový identifikátor si dále neuchovává. Pokud existuje klientský identifikátor, ten při komunikaci uchovat může.
  • Při komunikaci s ostatními AISy a ostatními agendami využije služby svého AISu (kdy AIS prostřednictvím ISSS zajistí výměnu údajů po překladu AIFO).

Při zpracování formulářů pak nastávají tyto tři situace a z nich plynoucí postupy:

  1. Elektronický formulář: Formulář musí být vytvořen tak, aby umožňoval již přenos identity klienta, a při jeho zpracování provede AIS dohledání aktuálních údajů podle AIFO subjektů.
  2. Listinný formulář: Na listinném formuláři se vyžaduje kombinace údajů křestní jméno, příjmení a typ a číslo dokladu, nebo jiný stykový identifikátor. Při zpracování formuláře se opět v AIS provede zavolání příslušné služby pro jednorázový překlad stykového identifikátoru na AIFO, a tím i ztotožnění subjektu pro daný AIS. V tomto případě se všechny údaje (včetně identifikátorů) pamatují z důvodu nutnosti uchovávání samotného formuláře.
  3. Asistované podání: Při asistovaném podání na přepážce příslušný pracovník provede prezenční ztotožnění podle dokladu, a pokud na základě jednání na přepážce bude činit něco jménem subjektu, bude k tomu využívat příslušné služby. Pokud bude pak činit úkon jménem OVM, opět při zápisu do AIS tento AIS zavolá službu jednorázového překladu stykového identifikátoru na AIFO.

Pravidla pro Prostorová data a služby nad prostorovými daty

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci úplného elektronického podání je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k prostorovým datům a službami nad prostorovými daty popíše úřad do své informační koncepce.

Veřejná správa využívá prostorová data ve všech agendách (a jsou jejich nedílnou součástí), které zajišťuje, např. se jedná o agendy v oblastech dopravy, regionálním rozvoji, ochraně životního prostředí, územním plánování, stavební činnosti, zemědělství, lesnictví, při řešení daňových potřeb státu, v oblasti evidence a správy majetku, pro ochranu kulturního dědictví. Prostorová data mají mimořádný význam pro bezpečnost státu, ochranu obyvatelstva, pro předcházení haváriím a živelním pohromám a řešení mimořádných situací. Aktuální, jednotná a rychle dostupná prostorová data jsou nezbytná pro kvalitní operační a krizové řízení na všech úrovních.

Pro zajištění sdílení a efektivního využívání prostorových dat a informací je nezbytné vytvořit odpovídající soustavu zásad, znalostí, institucionálních opatření, technologií, dat a lidských zdrojů, která se označuje jako infrastruktura pro prostorové informace. V řadě zemí je národní infrastruktura pro prostorové informace (NIPI) upravena a definována, v České republice doposud ucelené, přehledné, systematické a formálně zakotvené stanovení NIPI schází, proto byla alespoň stanovena strategie rozvoje této infrastruktury, viz Strategie rozvoje infrastruktury pro prostorové informace v České republice do roku 2020.

Aby bylo možné NIPI efektivně budovat, je kromě centrálních prvků infrastruktury a sdílených služeb, vhodné definovat typovou funkcionalitu (na obecné úrovni) pro informační systém spravující prostorová data jako součást informačních systémů veřejné správy příslušného orgánu veřejné moci. Protože prostorová data a služby jsou pouhým nástrojem pro podporu výkonu agend veřejné správy, ať již na úrovni státní správy, tak i na úrovni samosprávy, je pro stanovení obecného modelu na úrovni business architektury zásadní definovat klíčové konzumenty poskytovaných služeb ve formě agend a činností (dle terminologie základního registru agend orgánů veřejné moci a některých práv a povinností). Je zřejmé, že business vrstva bude odlišná pro jednotlivé segmenty, nicméně vykazuje určité společné rysy, zejména v řídících, podpůrných a provozních činnostech. Z pohledu podpory tzv. hlavních činností je důležitá vazba na Registr práv a povinností zakládající určité kompetence pro výkon konkrétních agend ve smyslu vazby na legislativu a jednotlivé aktéry (účastníky).

Uplatnění prostorových dat a služeb lze tedy fakticky nalézt ve všech oblastech, typicky, bez ohledu na konkrétní segment, při:

  • formulování strategických dokumentů souvisejících zejména s rozvojem území, služeb a segmentů (např. zdravotnictví, školství, sociální služby) či správou zdrojů,
  • podpoře výkonu agend veřejné správy související např. s územním plánováním, výstavbou, životním prostředím, dopravou, památkami, lesním hospodářstvím či integrovaným záchranným systémem,
  • správě majetku, zejména při evidování, údržbě a opravě, investování (např. budovy, pozemky, komunikace, zeleň, infrastruktura),
  • plánování kontrolních činností či řízení rizik v kontextu prostorových souvislostí.

Součástí business architektury je rovněž identifikace klíčových aktérů. Mezi externí lze zařadit veřejnost (fyzické osoby, fyzické osoby podnikající, právnické osoby), odbornou veřejnost, partnery a dodavatelé. Mezi interní patří např. politická reprezentace, vedení OVM, zaměstnanci vykonávající konkrétní agendy a činnosti a také zástupci ICT útvaru jako poskytovatelé ICT (GIS) služeb. Při popisu aplikační architektury je kromě vlastní funkcionality týkající se tvorby a správy prostorových dat potřebné se zaměřit také na sdílení dat nejen uvnitř vlastní organizace, ale také vůči ostatním informačním systémům veřejné správy.

Vlastní funkce systému pro správu prostorových dat tvoří na obecné úrovni zejména:

  • tvorba a pořízení dat
  • správa prostorových dat
  • správa metadat
  • transformace dat
  • vizualizace
  • analýzy
  • workflow
  • statistiky a reporting
  • harmonizace dat INSPIRE
  • tiskové úlohy
  • opendata
  • archiv

Pro publikaci a sdílení jsou klíčové služby vyhledávací služby, prohlížecí, stahovací, transformační a spouštěcí. Z pohledu vnitřního propojení s ostatními prvky ICT infrastruktury organizace jsou zásadní integrace na:

  • Agendové informační systémy (např. stavební a územní řízení, státní správa lesů, památková péče), kde GIS pomáhá zejména s vizualizací agendových údajů v mapě, vizualizací souvislostí či trendů, s jejich tematizací.
  • Elektronický systém spisové služby včetně spisovny; vztah mezi spisovou službu a digitální spisovnou a GIS není zpravidla realizován, přestože množství vstupů a výstupů z GIS má charakter dokumentu v kontextu zákona č. 499/2004 Sb. a národního standardu (NSESSS). GIS se v takových případech chová jako samostatná evidence dokumentů, nicméně nerespektuje příslušné legislativní povinnosti. Jedním z možných řešení je realizace vazby právě na spisovou službu.
  • Správa majetku a řízení investic, kdy majetek je primárně evidován a spravován v ERP (zpravidla v provázaných modulech evidence a údržby majetku a řízení investic s vazbou na účetní evidenci a rozpočet). Pro správu majetku jsou klíčová data katastru nemovitostí (vedená v ISKN) obsahující jak popisnou, tak i grafickou složku. Tato data ISKN jsou zpravidla v pravidelných intervalech dávkově aktualizována (lze však rovněž využít webových služeb dálkového přístupu katastru nemovitostí ČÚZK), přičemž dochází k často k duplicitní správě dat (včetně pravidelných aktualizací) rovněž v GIS. Optimální je zajistit společnou správu referenčních dat, zajistit jejich sdílení a vzájemnou iteraci na úrovni klientů.

Mezi klíčové, z pohledu vnější integrace na sdílené prvky eGovernmentu, patří:

  • Registr územní identifikace, adres a nemovitostí
  • Informační systém katastru nemovitostí
  • Národní geoportál INSPIRE
  • Digitální technická mapa ČR (IS DMVS)
  • Informační systém identifikačního čísla stavby

Pravidla pro Úplné elektronické podání

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci úplného elektronického podání je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k úplnému elektronickému podání popíše úřad do své informační koncepce.

Úř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):

  • 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.

Pravidla pro Integraci informačních systémů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci úplného elektronického podání je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k integraci informačních systémů popíše úřad do své informační koncepce.

Vnitřní integrace u jednoho správce či v jednom AIS

Integrace mezi informačními systémy jednoho správce je primárně zodpovědností a oblastí onoho správce. To neznamená, že taková integrace nepodléhá splnění EG principů, ale primárně se jí OHA nezabývá, dokud správce ISVS doloží soulad se zde uvedenými principy (jako je evidence subjektů, nebo propojený datový fond).

Technicky je doporučenou optimální metodou vybudovat jednu integrační platformu a integraci mezi jednotlivými informačními systémy zajistit formou služeb volaných a orchestrovaných v této integrační platformě. I při integraci (respektive výměně údajů mezi jednotlivými IS či agendami se musí ale myslet například na řádné logování transakcí a audit zpracování osobních údajů, zejména pokud se jedná o údaje o fyzických či právnických osobách.

Pro vnitřní integraci ale vždy platí následující:

  • Jako identifikátor subjektu pro výměnu údajů i ve vnitřní integraci se využije AIFO, pokud se integrace zajišťuje překladem přes eGSB/ISSS.
  • Pokud se integrace odehrává jen v perimetru správce, a tedy mimo překlad přes eGSB/ISSS, tak se jako identifikátor využije buď klientské číslo, nebo stykový identifikátor. To platí i v multiagendovém provozu, kdy jsou subjekty integrovány v jedné evidenci jednoho AIS sloužícího pro podporu více agend.
  • Identifikátor AIFO se v žádném případě nevyužije při integraci AIS na provozní systémy, pokud tyto systémy nevyužívají AIFO v jejich agendě. V případě integrace subjektů mezi AIS a provozními systémy, které nemají pro subjekt přidělené AIFO v podporované agendě, se využije klientský identifikátor.
  • AIFO se neeviduje a neposkytuje ve společných evidencích a v multiagendových AISech, AIFO se v takovém případě využije jen pro vnější integraci a pochopitelně pro ztotožnění a aktualizaci údajů pro konkrétní agendu. Mezi více agendami v jednom ISVS se pro propojení využije klientský identifikátor a AIFA jsou zapsána jen v komponentách AISu pro jednotlivé agendy, nikdy ve společné evidenci. Při vnější integraci pak volá AIS přes společnou evidenci službu eGSB/ISSS či ISZR prostřednictvím svého AIFO.

Vnější integrace na AIS jiného správce

Při vnější integraci se v maximální míře využívá referenční rozhraní, a to zejména eGSB/ISSS jako technický způsob výměny údajů o subjektech a objektech práva. Technická realizace integrace prostřednictvím eGSB/ISSS se řídí příslušnou provozní dokumentací eGSB/ISSS.

Při vnější integraci se využije:

  • při výměně údajů o subjektu (fyzická osoba) překlad AIFO identifikátorů, nikdy se nevyužije přímá výměna prostřednictvím jiného identifikátoru,
  • při výměně údajů o objektu (třeba vozidlo) jeho identifikátor (třeba RZ), ale je-li součástí i sada údajů o subjektu, pak se u fyzických osob (třeba vlastník vozidla) využije opět překlad AIFO mezi dvěma agendami.

Výměna údajů o subjektech při integraci IS

Jedním z důvodů integrace mezi více AIS je realizace propojeného datového fondu, tedy výměny údajů o subjektech a objektech práva.

Při vnitřní integraci u jednoho správce

Při vnitřní integraci mezi komponentami a systémy jednoho správce se primárně AIFO nevyužívá, protože se využije klientský identifikátor. Pomocí klientského identifikátoru a vazby všech údajů vedených o subjektu ve všech agendách (vždy přes jednotlivý AIS) se dá naplnit povinnost nevyžadovat již jednou vedené údaje a v kombinaci s jednotnou evidencí případů lze snadno zajistit povinnosti poskytnout subjektu práva z ISVS a mít přehled o údajích, které o něm vedeme a o rozhodných skutečnostech, které se ho týkají.

Pokud se jedná o integraci mezi AIS a provozními informačními systémy, tak provozní IS kromě ESSL nevyužívají AIFO ve svých agendách. I proto je nutno využívat klientský identifikátor, nebo si na úřadě zavést jiný klidně i neveřejný identifikátor, kterým provážeme údaje vedené i v provozních systémech. V žádném případě k tomu nevyužíváme některý z AIFO identifikátorů, kterým bychom nahrazovali vlastní identifikátor v úřadu.

Při vnější integraci s IS jiného správce

Při výměně údajů v rámci propojeného datového fondu se vždy využije mechanismus výměny prostřednictvím překladu agendových identifikátorů (AIFO) přes ORG. Integrace se uskutečňuje prostřednictvím služeb eGSB/ISSS. I v situaci, kdy OVM vede některé další identifikátory o subjektu, vždy postupuje v souladu s § 8, odst. 3, zákona o základních registrech a využije volání služby poskytované agendovým informačním systémem poskytujícím údaje, službu volá přes eGSB/ISSS a volá ji s identifikací subjektu svým AIFO, kdy následně eGSB/ISSS zajistí překlad AIFO, poskytující AIS pak opět přes eGSB/ISSS zašle odpověď, a to zase s přeložených AIFO tazatele. Jiné identifikátory tedy nejsou nutné.

Obě strany integrace pochopitelně všechny transakce logují a samotné eGSB/ISSS uchovává informaci o využití služby.

Chce-li nějaké OVM získat z jiného AISu údaje o subjektu, musí si nejprve daný subjekt ztotožnit a mít k němu přidělené AIFO své agendy. Nezíská-li od poskytovatele údaje třeba proto, že nejsou správně nastavena oprávnění k údajům v RPP, nebo protože poskytovatel nemá řádně ztotožněný subjekt a nemá k němu AIFO, reklamuje to u poskytovatele jako porušení povinností podle zákona o základních registrech. Poskytovatel pak zjedná nápravu.

Pozor: U údajů takto získaných z jiných agend se jedná o údaje, které úřad vede (i když je technicky získal z jiného AIS), a tedy úřad musí postupovat podle paragrafu 6, odst. 2, Správního řádu a po subjektu je nevyžaduje a nepožaduje jejich doložení.

Pravidla pro Portály veřejné správy a soukromoprávních uživatelů údajů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci portálů veřejné správy a soukromoprávních uživatelů údaje je popsán na samostatné stránce zde nebo v rámci části Architektura sdílených služeb veřejné správy.

Využití a popis k přístupu k portálům VS a SPUU popíše úřad do své informační koncepce.

Úřad musí při provozování portálu zavést a změnit současné procesy orientované především na osobní kontakt s klientem. Současné portály již musí disponovat funkcionalitou propojení se zaručenou identitou dle zákona 250/2017 Sb. a musí se umět přizpůsobit situaci, kdy klient veřejné správy bude komunikovat pouze elektronicky. Začíná se tedy samotným uživatelsky přívětivým prostředím, které musí být v souladu s grafickým manuálem MVČR. Dále je potřeba formulářový engine, který umožní nejen předvyplnit veškeré státu již známé údaje z propojeného datového fondu a elektronické identity poskytnuté národní identitní autoritou. V neposlední řadě je potřeba zajistit předávání všech podání učiněné v portálu do agendových informačních systémů, ve kterých se dle agendy podání řeší a zároveň do spisové služby úřadu.

Portál podporuje samoobslužného klienta, který obsahuje jak přenesenou, tak samosprávnou působnost a obsahuje popis životních situací, ve kterých se řeší mandáty v elektronické komunikaci. Pokud portál vykonává a podporuje agendu veřejné správy dle registru práv a povinností, musí se chovat jako jakýkoliv jiný agendový informační systém a pracovat dle definice agendy.

Při předávání podání z portálu je tak potřeba mít zajištěnou funkcionalitu, která z podání vytvoří "lidsky čitelné" a "strojově čitelné" informace v rámci jednoho dokumentu, typicky formátu PDF/A3 a vyšší. Tento „kontejnerový“ formát pak slouží jak pro plnění požadavku „čitelnosti“ tak i pro zajištění požadavku na automatizované zpracování dat (vložené XML s údaji pro automatizované zpracování). Dokument musí být dále pak opatřen náležitostmi dle zákona č. 297/2016 Sb., typicky elektronickým podpisem nebo elektronickou pečetí a časovým razítkem. Lidsky čitelný formát, typicky PDF, jde do spisové služby pro evidenci a strojově čitelný formát jde od agendového systému. Při provozu portálu nezáleží na technologiích, ani infrastruktuře. Není tedy preferované ani On Premise řešení, ani cloudové řešení, vše záleží na potřebách daného úřadu a možnostech, které technologie dokáží nabídnout. Je vždy potřeba myslet na rozložení zátěže, například daňové přiznání z příjmu fyzických osob se podává 1x ročně a není proto nutné klást na infrastrukturu celoroční nepřetržitý provoz. Každé řešení však musí podporovat přístup k centrálním službám eGovernmentu a dalším službám veřejné správy skrze zabezpečenou infrastrukturu Referenčního rozhraní veřejné správy.

Agendový portál

Agendovým portálem je myšlen portál poskytující služby logicky centralizovaného systému pro jiné orgány veřejné správy. Typicky jde tedy o portál agendy v přenesené působnosti poskytovaný správcem (ohlašovatelem) agendy.

Takový portál musí splnit několik podmínek:

Portál území

V případě portálů samospráv se předpokládají dva trendy: a) jednak budou lokální portály samospráv obsahovat obrácený směr navigace do Portálu občana, kde bude moci klient vyřídit vše ostatní ze státní správy, co případně nenašel v místním portálu a b) lokální portály budou moci být v dlouhodobé perspektivě nahrazovány místně přizpůsobenými službami centrálního Portálu občana v PVS. Takový portál musí splnit několik podmínek:

Portál soukromoprávního uživatele údajů

V případě portálu soukromoprávního uživatele údajů (také jako SPUÚ) se jedná o situaci, kdy vlastník portálu není orgán veřejné moci, ale dle své povahy je podřízen zákonu 111/2009 Sb. SPUÚ je podnikající fyzická osoba nebo právnická osoba, která není orgánem veřejné moci a je podle jiného právního předpisu oprávněna využívat údaje ze základního registru nebo z agendového informačního systému Může se jednat o portály poskytovatelů zdravotních služeb, soukromých pojišťoven, bank, státních podniků, apod. Takový portál a jeho vlastník musí splnit několik podmínek:

  1. Musí mít zřízenou datovou schránku pro komunikaci s veřejnou správou
    • Právnické osoby mají datovou schránku zřízenou ze zákona
    • Zřídit datovou schránku je možné dle informací na webu České pošty
    • Datová schránka se může obsluhovat skrze webové rozhraní na adrese www.mojedatovaschranka.cz nebo mít funkcionality integrovány do vnitřních systémů organizace. Nejčastěji se jedná o elektronickou spisovou službu.
  2. Musí být ohlášen v rejstříku SPUÚ v registru práv a povinností. Zde je možnost kontroly https://rpp-ais.egon.gov.cz/AISP/verejne/katalog-spuu.
    • Ohlášení do rejstříku SPUÚ probíhá pomocí agendového informačního systému působnostního viz https://rpp-ais.egon.gov.cz/AISP/. Do tohoto systému má přistup každý ohlašovatel agendy.
    • Pokud tedy existuje agenda, v rámci které je SPUÚ oprávněn čerpat údaje ze základních registrů nebo z agendového informačního systému, je třeba kontaktovat správce agendy a požadovat zavedení do rejstříku SPUÚ.
    • Pokud není soukromoprávní uživatel údajů ohlášen v AISP a správce agendy, ani jiné OVM, jej ohlásit nechce, může SPUÚ kontaktovat správce Registru práv a povinností (posta@mvcr.cz) se žádostí o ohlášení do rejstříku SPUÚ s těmito údaji (Název organizace, adresa organizace, IČO, DIČ, zákon a paragraf opravňující k přístupu do základních registrů nebo agendovému informačnímu systému, kontaktní osoba)
  3. Musí být ohlášen jako kvalifikovaný poskytovatel služeb online služeb (dále též Service Provider). Více také zde https://www.eidentita.cz/Home/Ovm. Ohlášení může proběhnout automatizovaně skrze formulář, pokud to umožňuje typ zřízení datové schránky (typ 10, 14, 15, 16). Pokud žadatel tento typ nemá, je nutné kontaktovat Správu základních registrů skrze datovou schránku napřímo s požadavkem obsahujíc všechny údaje, jako v případě automatizovaného způsobu:
    • IČO subjektu
    • Název kvalifikovaného poskytovatele (SeP)
    • Popis kvalifikovaného poskytovatele
    • URL adresa odkazující na úvodní webové stránk
    • URL adresa pro odeslání požadavků
    • Adresa pro příjem vydaného tokenu (URL)
    • URL adresa, na kterou bude uživatel přesměrován při odhlášení z Vašeho webu
    • Načtení certifikátu
    • Adresa pro načtení veřejné části šifrovacího certifikátu z metadat (URL). Touto veřejnou částí budou šifrována data v tokenu
    • Logo kvalifikovaného poskytovatele
  4. Musí umět přijímat a zpracovávat data pomocí standardů SAML2 nebo WS-Federation

Postup ohlášení portálu jako kvalifikovaného poskytovatele služby

Následující kroky popisují jednotlivé části procesu, který je naznačen níže, na základě ověření přes ISDS. Aktuálně je registrace organizace prostřednictvím portálu národního bodu přístupná pouze pro orgány veřejné moci (OVM), ostatní subjekty musí provést registraci přímo u Správy základních registrů (viz krok 8). Kompletní příručka je dostupná zde.

  1. Uživatel jako zástupce organizace požaduje po portálu národního bodu, který je Service Providerem, službu umožňující registraci dané organizace. Tato registrace umožní fungování dané organizace v NIA a vytváření jednotlivých Service Providerů.
  2. Portál národního bodu kontaktuje Národní identitní autoritu, která ověření zprostředkovává, s požadavkem na ověření dané osoby (uživatele).
  3. Pro ověření uživatele pro registraci organizace či konfigurací jednotlivých Service Providerů je jako Identity Provider určen Informační systém datových schránek (ISDS). Národní identitní autorita provede přesměrování na přihlášení prostřednictvím datových schránek.
  4. Uživatel provede ověření vlastní osoby přihlášením k datovým schránkám. Aby mohl uživatel registrovat organizaci na portálu národního bodu, musí být přihlášen prostřednictvím ISDS (v definované roli a typem schránky OVM). V případě, že organizace není OVM, je potřeba provést registraci u Správy základních registrů.
  5. V případě, kdy je uživatel úspěšně ověřen, Informační systém datových schránek předá Národní identitní autoritě jako výsledek ověření autentizační token obsahující IČO a název subjektu, roli přihlašovaného uživatele a další atributy.
  6. Národní identitní autorita provede sběr atributů v Informačním systému základních registrů (ISZR) na jehož základě následně provede kontrolu existence IČO.
  7. Národní identitní autorita předává portálu národního bodu potřebné atributy z Informačního systému základních registrů a atributy přijaté v autentizačním tokenu z Informačního systému datových schránek, které jsou nutné ke zpracování formuláře pro registraci.
  8. Na základě úspěšného splnění předchozích kroků umožní portál národního bodu uživateli službu registrace organizace (SeP) a zobrazí mu vyplněný formulář pro registraci. Toto platí pouze pro organizace, které jsou OVM. Není-li organizace OVM, jsou místo registračního formuláře zobrazeny podrobné informace o tom, jakým způsobem provést registraci přímo u Správy základních registrů.
  9. Uživatel potvrdí správnost údajů a provedení registrace organizace (SeP).
  10. Portál národního bodu zpracuje přijatý požadavek na registraci a po úspěšném zaregistrování umožní uživateli provést konfiguraci jednotlivých Service Providerů spadající pod danou organizaci (seznam konfigurací kvalifikovaných poskytovatelů).
  11. Uživatel provede konfiguraci Service Providera zahrnující následující údaje:
    • IČO subjektu
    • Název kvalifikovaného poskytovatele
    • Popis kvalifikovaného poskytovatele
    • URL adresa odkazující na úvodní webové stránky kvalifikovaného poskytovatele
    • URL adresa pro odeslání požadavků
    • Adresa pro příjem vydaného tokenu
    • URL adresa, na kterou bude uživatel přesměrován při odhlášení z Vašeho webu
    • Načtení certifikátu
    • Adresa pro načtení veřejné části šifrovacího certifikátu z metadat
    • Zpřístupnění autentizace prostřednictvím brány eIDAS
    • Logo kvalifikovaného poskytovatele

Příklad pro poskytovatele zdravotních služeb

Poskytovatel zdravotních služeb není orgán veřejné moci, a proto je třeba zajistit kromě výše uvedeného postupu i následující kroky:

  1. Požádat Ministerstvo zdravotnictví o zavedení do registru práv a povinností jako SPUÚ dle povinností vyplývající ze zákonů č. 250/2017 Sb. a č. 372/2011 Sb., ideálně pod agendou A1086
  2. Na adrese https://www.eidentita.cz/Home/Ovm se přihlásit jako oprávněný uživatel datovou schránkou poskytovatele zdravotních služeb
    • Nově by se mělo nabídnout ruční zadání údajů s dalším postupem
    • Pokud se neobjeví, postupovat dle obecných bodů výše – poslání datové zprávy obsahující potřebné údaje (URL, logo….)
  3. Upravit si svůj profil na https://www.eidentita.cz/Home/Ovm pro přístup jiných osob (IT oddělení např.) a správu svého profilu, konfigurovat pro Portál pacienta poskytovatele zdravotních služeb.

Pravidla pro Přístupnost informací

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci přístupnosti informací je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k přístupnosti informací popíše úřad do své informační koncepce.

Legislativní rámec pro přístupnost

Legislativní rámec pro povinnosti přístupnosti je poměrně široký. Níže jsou uvedeny pouze klíčové předpisy, které mají přímý vliv na přístupnost informací:

  1. Obecná úroveň
    1. Mezinárodní přímo aplikovatelná Úmluva o právech osob se zdravotním postižením
    2. Zákon č. 198/2009 Sb., o rovném zacházení a o právních prostředcích ochrany před diskriminací
  2. Úroveň základních služeb
    1. Procesně-správní předpisy, jako je Zákon č. 500/2004 Sb., Správní řád, apod.
    2. Zákon č. 155/1998 Sb., o komunikačních systémech neslyšících a hluchoslepých osob
    3. Nařízení EU č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu (zejména článek 15)
    4. Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů
  3. Úroveň internetových stránek a mobilních aplikací
    1. Zákon č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací subjektů veřejného sektoru
    2. Zákon č. 365/2000 Sb., o informačních systémech veřejné správy (zejména § 5, odst. 2, písm. f), § 9, a další)
    3. Částečně legislativa ohledně spisové služby
  4. Úroveň realizace veřejných zakázek
    1. Zákon č. 134/2016 Sb., o zadávání veřejných zakázek (zejména § 93)

Vesměs z legislativy plynou pro OZP následující práva a pro veřejnou správu povinnosti:

  1. OZP musí mít možnost využívat všechny služby veřejné správy jako kdokoliv jiný
  2. OZP musí mít možnost plnohodnotně využívat elektronické služby stát i elektronické služby subjektů veřejného sektoru
  3. Existuje zde obecná absolutní povinnost přístupnosti výsledků všech veřejných zakázek či zakázek podle legislativy k VZ, pokud jsou jejich výsledky určeny pro jakékoliv užívání fyzickými osobami, to se pochopitelně vztahuje i obecně na veškeré ICT zakázky.
  4. Subjekty veřejného sektoru musejí mít svoje informace přístupné a to zejména na internetových stránkách a ve svých aplikacích
  5. Přístupnost se vztahuje i na veškeré informační systémy pro zaměstnance, protože ani zaměstnanec s OZP nesmí být diskriminován tím, že není schopen pracovat se svým pracovním systémem

Standardy a metodiky

K dispozici jsou technické standardy a metodiky, které určují konkrétní technické postupy pro tvorbu a správu přístupného obsahu. Nejdůležitějšími v oblasti informačních systémů jsou následující:

  • WCAG - Web content accessibility guidelines - Základní standard pro přístupnost obsahu
  • WAI-ARIA: Standard Accessible Rich Internet Applications suite - Standard pro webové aplikace
  • MAAP - Mobile accessibility applications principles - Soubor opatření pro přístupnost mobilních aplikací (přičemž pro jednotlivé platformy jsou opět k dispozici podrobné standardy)

Více o standardech a jejich realizaci se můžete dočíst třeba v sekci Standardy a normy na portálu pristupnost-informaci.cz

Architektonická řešení

Na obecné úrovni lze konstatovat, že přístupnost A to jak u internetových stránek tak ale třeba i u informačních systémů, je záležitostí dodavatele. Pokud je daná služba informační systém, aplikace, stránka poptávána jako dodávka v rámci veřejné zakázky, pak zde dopadají jednak obecné povinnosti stanovené v legislativě týkající se veřejných zakázek, jednak technické podrobnosti stanovené v legislativě týkající se přístupnosti internetových stránek a mobilních aplikací. Základním architektonickým řešením tedy je zahrnout potřebu přístupnosti a naplnění konkrétních technických norem jako nepřekročitelný požadavek v rámci architektury a v rámci požadavků na dodavatele. Je tedy nutno architektonicky a realizačně zajistit:

  • Aby všechny internetové stránky (ať už veřejné či nikoliv) splňovaly požadavky na přístupnost.
  • Aby všechny mobilní aplikace splňovaly požadavky na přístupnost.
  • Aby všechny aplikace, systémy a informační systémy dodávané v jakékoliv formě veřejného investování také splňovaly požadavky na přístupnost.
  • Aby byl elektronický systém spisové služby, agendové informační systémy a další aplikace a procesy nastaveny tak, aby digitální dokumenty odesílané organizací byly přístupné.
  • Aby se požadavky na přístupnost staly nedílnou součástí požadavků na dodávky a veřejné zakázky i požadavků na interní vývoj.

Pravidla pro Elektronickou fakturaci

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci elektronické fakturace je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k elektronické fakturaci popíše úřad do své informační koncepce.

Dle zákona č. 134/2016, o zadávání veřejných zakázek se týká všech orgánů veřejné moci, kteří zadali k postoupení nadlimitní veřejnou zakázku a to od 1. 1. 2019 pro ústřední orgány moci a následně od 1.4.2020 pro uzemní samosprávu dle zákona č. 134/2016 Sb., o zadávání veřejných zakázek, §279 (5) b). Všichni povinní tedy musí kromě procesních změn zajistit i příjem a vydávání elektronických faktur dle evropských a českých pravidel.

Technické aspekty

E-fakturaci je možné implementovat a realizovat ve svých organizačních jednotkách za dodržení jednoho z následujících technických standardů, který je v souladu se směrnicí 2014/55/EU:

  • Evropská norma pro elektronickou fakturaci EN 16931-1:2017 - otevřená a zdarma dostupná na této stránce
  • Syntaxe dle Evropské směrnice 2014/55/EU čl. 3, odst. 2
  • XML zprávu meziodvětvové faktury UN/CEFACT podle XML schémat 16B (SCRDM - CII)
  • UBL zprávy faktury a dobropisu podle ISO/IEC 19845:2015

Je třeba zmínit, že směrnice 2014/55/EU:

  • nepředepisuje, která syntaxe by měla být použita pro elektronickou fakturaci v rámci veřejné zakázek. Pouze uvádí, které syntaxe jsou veřejní zadavatelé povinni akceptovat. Je zcela možné a velmi pravděpodobné, že jiné syntaxe, které nejsou uvedeny na seznamu výše, se budou i nadále používat, a to i pro přeshraniční výměny, zvláště tam, kde již existuje rozšířená národní nebo místní praxe. To je případ českého národního formátu elektronické faktury ISDOC (Information System Document), verze 5.2 a vyšší (který je definován vyhláškou č.194/2009 Sb a který musí být dle Usnesení vlády č. 347/2017 akceptován veřejnoprávními subjekty od 1.1.2019). Tento formát logicky není součástí výše uvedené směrnice, jakkoli je syntaxi UBL 2.1 velmi blízký, jelikož vychází z verze UBL 2.0. V rámci vnitřního trhu České republiky je formát ISDOC velmi široce rozšířen, zejména mezi soukromoprávními subjekty, které ve veřejné zakázce figurují v roli dodavatele, tedy vystavitele faktury.
  • neponechává veřejným zadavatelům žádný prostor odmítnout fakturu ve kterékoliv ze syntaxí, které jsou uvedeny na seznamu, jenž bude zveřejněn v Úředním věstníku Evropské unie, v návaznosti na článek 3 směrnice. Článek 7 jasně uvádí, že veřejní zadavatelé a zadavatelé v EU musí přijímat a zpracovávat elektronické faktury, které splňují normu a odpovídají kterékoli ze syntaxí uvedených na zveřejněném seznamu.

Právní aspekty

Implementace e-fakturace do prostředí veřejné správy České republiky je dána směrnicí 2014/55/EU, která nabyla účinnosti 19. 4. 2018. K tomuto datu je také nutné mít ve svých spisových službách v rámci organizace nastavené technickoorganizační opatření, která budou v souladu s výše uvedenou směrnicí a technickými standardy z ní vyplývající. Směrnice byla inkorporována do české legislativy v rámci §221 zákona č. 134/2016, o zadávání veřejných zakázek. Zadavatel nesmí odmítnout elektronickou fakturu vystavenou dodavatelem za plnění veřejné zakázky z důvodu jejího formátu, který je v souladu s evropským standardem elektronické faktury.

Všechny veřejné zakázky, které jsou nadlimitní mohou být dodavatelem vyžadovány ve formě e-fakturace.

V neposlední řadě bylo schváleno Usnesení vlády č. 347/2017, které dává povinnost od 1. 1. 2019 Ústředním orgánům státní správy a jimi podřízeným organizačním složkám státu přijímat elektronické faktury ve formátech stanovených Evropskou směrnicí 2014/55/EU a dále ve formátu isdoc/isdocx (Information System Document) verze 5.2 a vyšší

Pravidla pro Portál občana a Portál veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci portálu občana a portálu veřejné správy je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k portálu občana a portálu veřejné správy popíše úřad do své informační koncepce.

Portál občana i portál veřejné správy jsou centrálně poskytované a provozované portály. Integrovat, či federovat služby úřadu lze přes vlastní řešení v podobě agendových portálů, portálů území či soukromoprávních uživatelů údajů. Integrace je celkem na 3 stupních:

  1. Proklik na vlastní řešení s využitím Single Sign-On. Obsahuje pouze vlastní prostor na portálu občana, kde úřad zveřejní svou informační dlaždici, skrze kterou se klient dostane, s využitím principu Single Sign-On a zapojení do národního identitního prostoru, na vlastní řešení
  2. Poskytování údajů do vlastního prostoru na portálu občana. Kromě možnosti prokliku na vlastní řešení zapojeného do národního identitního prostoru obsahuje i vždy aktuální údaje o klientovi poskytované skrze propojený datový fond
  3. Kompletní vyřešení služby veřejné správy na portálu občana pomocí formulářového řešení se všemi integracemi v bodech 1 a 2.

Přihlášení k portálu občana

Pro přístup na Portál občana je nutností přihlášení uživatele. Zvolený způsob přihlášení určuje i rozsah služeb, které jsou pro uživatele přístupné. Přihlašovací stránka Portálu občana je dostupná na adrese https://obcan.portal.gov.cz. Přihlášení je možné:

  • prostřednictvím kvalifikovaného systému elektronické identifikace (NIA) v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci, a to s využitím občanského průkazu s elektronickou částí (pouze průkazy vydávané od 1. 7. 2018, nevyžadována registrace) nebo s využitím identifikačního prostředku Jméno, heslo a SMS (nutná registrace), příp. s využitím dalších prostředků identifikace.
  • prostřednictvím autentizačního rozhraní Informačního systému datových schránek v souladu se zákonem č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů. Přihlášení je umožněno pouze těmto typům subjektů – držitelů datových schránek:
    • fyzická osoba (FO)
    • podnikající fyzická osoba (PFO)

Přitom lze využít pouze datové schránky zřízené na žádost, nikoli ze zákona, tedy nikoli ty zřizované automaticky advokátům, statutárním auditorům, daňovým poradcům nebo insolvenčním správcům. Všechny možnosti přihlášení jsou na sobě nezávislé, ale pro plné využití všech služeb Portálu občana je doporučeno použít elektronický občanský průkaz a dále mít připojenou datovou schránku. V obou případech se jedná o přístup se zaručenou identitou v souladu se zákonem č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, jinými slovy o přístup do informačního systému veřejné správy nebo elektronické aplikace s využitím prostředku pro elektronickou identifikaci, při jehož vydání nebo v souvislosti s ním anebo v souvislosti s umožněním jeho využití byla totožnost osoby ověřena státním orgánem, orgánem územního samosprávného celku nebo orgánem veřejné moci, který není státním orgánem ani orgánem územního samosprávného celku, nebo který byl vydán v rámci kvalifikovaného systému elektronické identifikace.

Evidence údajů

Portál občana uchovává perzistentně typově takovéto informace:

  • BSI (bezvýznamové směrové identifikátory) – jde o celou sadu identifikátorů, které slouží ke komunikaci s okolními systémy (např. AIFO – ISZR, SePP – NIA atd.). Tyto identifikátory mají význam cizího klíče. Z jejich hodnoty (převážně jde o GUID) nelze přímo vyčíst žádné informace o uživateli. Tyto identifikátory neopouštějí perimetr PO jinak, než při komunikaci s dotčeným systémem.
  • Nastavení – jde o informace ovlivňující zobrazené informace na Portálu občana (např. zobrazení dlaždic, nastavení notifikací apod.). Z jejich hodnot nelze přímo vyčíst žádné informace o uživateli.
  • Dokumenty – jde o celou řadu „souborů“, které se vytvářejí v Portálu občana a nebo které si uživatel do PO nahrál. Jde například o tisknutelnou formu podání, archiv DZ apod. Tyto dokumenty se ukládají do speciální zabezpečené oblasti, která se „odemyká“ až při přihlášení uživatele. Tyto dokumenty mohou obsahovat i zvláštní kategorie osobních údajů (dříve jako citlivé údaje), ale z pohledu PO jsou „neviditelné“ (Portál občana neprovádí parsování těchto dokumentů).
  • Komunikační atributy – v současné době jde o e-mail a telefonní číslo. Komunikační atributy neopouštějí přímo perimetr Portálu občana, ale slouží pouze pro navázání komunikace Portálu občana s uživatelem, resp. zasílání notifikací. Portál občana uživatele notifikuje pouze v případě jeho žádosti ve specifických případech (nastavení).

Transientně přes Portál občana prochází mnoho uživatelských informací. Jejich šíře se nedá přesně specifikovat – záleží, s jakým AIS uživatel prostřednictví Portálu občana komunikuje. Nicméně tyto informace se neukládají (jde pouze o on-line náhledy na informace). Co se týče notifikací změn údajů v základních registrech, proces je spouštěn v definovaných časech (konfigurace Portálu občana), Portál občana zjišťuje na základních registrech změnu přihlášených AIFO. Pokud taková změna proběhla a uživatel si nastavil notifikaci, PO vytvoří zprávu (podle nastavení uživatele) a uloží ji do fronty seznamu zpráv.

Komunikace s dalšími subjekty

Komunikace na úrovni frontend

Komunikací na úrovni frontend je míněno především sdílení společného prostoru kvalifikovaného systému elektronické identifikace (NIA). V tomto prostoru má uživatel možnost procházet přes jednotlivá portálová řešení a využívat tzv. principu „single sign-on“, tj. jednotného přihlášení sdíleného mezi všemi portály či aplikacemi. NIA se řídí ustanoveními zákona č. 250/2017 Sb., o elektronické identifikaci. V návaznosti na výše uvedené slouží tzv. statické dlaždice na Portálu občana pro přechod uživatele mezi Portálem občana a dalšími portály či aplikacemi bez potřeby další autentizace. Portál občany tedy z pohledu funkcionality statických dlaždic slouží jako rozcestník. V současné době si uživatel Portálu občana sám vybírá a aktivuje služby (v podání dlaždic) z katalogu. V dalších fázích rozvoje je uvažováno o nabízení relevantních dlaždic dle jejich obsahu a rolí, ve kterých uživatel bude vystupovat. Aktivní služby v podobě dlaždic jsou uživateli zobrazeny na dashboardu Portálu občana.

Komunikace na úrovni backend

Portál občana standardně napřímo komunikuje s jen omezeným množstvím systémů, a to centrálně sdílených služeb. Konkrétně jde o:

  • Informační systém základních registrů prostřednictvím svých vlastních nebo kompozitních služeb,
  • Informační systém datových schránek.

Pro komunikaci s ostatními systémy Portál občana výhradně využívá eGon Service Bus / Informační systém sdílené služby.

Komunikace prostřednictvím ISZR
  • Čtení ze Základních registrů (ROB, ROS):
    • přístup k údajům v základních registrech probíhá v agendové činnosti (RPP), kterou použije čtenář;
    • činnost musí mít oprávnění na přístup k Základním registrům.
  • Čtení přes kompozitní služby (AIS EO):
    • čtení přes kompozitní služby probíhá v agendové činnosti (RPP), kterou použije čtenář;
    • činnost musí mít oprávnění na čtení z AIS.
    • činnost musí mít oprávnění na čtení z ROB podle typu použité služby (ověření AIFO nebo referenčních údajů použitých pro vyhledávání).

Mezi napřímo volané služby patří např. E03 robCtiAifo (čtení referenčních údajů z registru ROB), E22 rosCtiPodleUdaju, E45 orgPrihlasAifo (zaevidování AIFO k notifikaci změn v ROB a ORG pro volající AIS), E98 iszrCtiSouborCiselniku, E106 rppVypisSeznamAgend, E153 iszrZpracujFormular, E181 robVypisSouhlasuPoskytnuti, E199 orgZjistiAis (zjištění kombinací AIFO / Agenda, ve kterých v ORG existuje AIFO odpovídající vstupnímu AIFO) nebo E226 eidentitaCtiAifo (převod bezvýznamového identifikátoru fyzické osoby na odpovídající AIFO AIS).

Komunikace prostřednictvím eGSB/ISSS

Pokud hovoříme o spolupráci přes back-end, je tím míněno napojení Portálu občana na publikační AIS a spolupracovat přes služby, které jsou vystaveny na eGSB/ISSS. Připojení publikačního AIS je z pohledu náročnosti poměrně složité a vyžaduje součinnost ze strany provozovatele eGSB/ISSS. Jeho vstupy jsou nezbytné zejména při definování kontextů (schémat datových zpráv), které jsou sice v kompetenci publikátora, ale pro zachování jednotného formátu přes všechny publikátory, je nutné schválení ze strany provozovatele eGSB/ISSS. Portál občana nekonzumuje veškerá data, která jsou publikována na eGSB/ISSS už i z toho důvodu, že ne vše je určeno pro uživatele – fyzickou osobu. Výběr toho, co a jak zobrazovat na Portálu občana, je tedy výsledkem konkrétní spolupráce gestora publikačního AIS a Portálu občana. Po shodě na rozsahu služeb postupují řešitelé Portálu občana v těchto krocích:

  1. vývoj pro čtení dat (čtenářská aplikace),
  2. oprávnění pro čtení a získání testovacích dat,
  3. testování čtení dat.

Po ověření dostupnosti eGSB/ISSS si Portál občana z katalogu služeb stáhne potřebné WSDL a XSD definice služeb a kontextů pro dostupné publikační AIS. Na základě těchto souborů unikátních pro každý publikační AIS a obecného popisu služeb eGSB/ISSS popsaných v dokumentu „Využití služeb eGSB/ISSS čtenářskými AIS“ si Portál občana vytvoří vlastní klientské rozhraní webových služeb pro čtení dat pomocí eGSB/ISSS.

Pravidla pro Národní identitní autoritu

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci Národní identitní autority je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k Národní identitní autoritě popíše úřad do své informační koncepce.

Úřad musí zajistit identifikaci a autentizaci klientů veřejné správy prostřednictvím kvalifikovaného systému elektronické identifikace (v současnosti pouze NIA) tam, kde ověření totožnosti vyžaduje právní předpis nebo výkon působnosti. Pro využití Národní identitní autority se musí organizace stát tzv. Kvalifikovaným poskytovatelem, dle postupu popsaném u Portálů veřejné správy a soukromoprávních uživatelů údajů.

Zásadním požadavkem bezpečnosti a transparentnosti pro informační systémy veřejné správy je požadavek na jednotnou elektronickou identifikaci externích uživatelů. Pro každou operaci je nutná znalost osoby, která tuto operaci provádí zvláště z hlediska nepopiratelné zodpovědnosti osoby. Externí uživatelé (klienti) informačních systémů veřejné správy musí být jednoznačně identifikováni zvláště z důvodů ochrany osobních údajů a dále z procesního hlediska, jak předpokládá správní řád (jednoznačné prokázání totožnosti účastníků řízení).

Úloha správy přístupů se pro každý informační systém veřejné správy skládá z následujících kroků:

  • Identifikace – jednoznačné a nepopiratelné určení fyzické osoby, která přistupuje k informačnímu systému veřejné správy
  • Autentizace – prokázání, že přistupující osoba je tou osobou, za kterou se vydává. Autentizace probíhá předložením autentizačních prostředků (například uživatelské jméno a heslo, autentizační certifikát), které osobě přidělil správce informačního systému
  • Autorizace – na základě údajů o identifikované a autentizované osobě a dalších údajů o této osobě (například zařazení na pracovní pozici) zařazení osoby do odpovídající role a z toho vyplývající vyhodnocení oprávnění na úkony a data v rámci informačního systému.

NAP v této oblasti vyžaduje naplnění následujících principů pro všechny informační systémy veřejné správy:

  1. Každý úřad, který poskytuje své služby elektronicky a potřebuje pro ně ověřeného klienta, musí využít služeb kvalifikovaného systému elektronické identifikace (v současnosti pouze NIA)
  2. Každý úřad musí akceptovat nejen identitu českého občana, ale kteréhokoliv občana Evropské Unie dle eIDAS.
  3. Při tvorbě identitního prostoru si prvně udělat analýzu, zda nepostačuje již některý z federovaných identit v rámci kvalifikovaného systému elektronické identifikace (v současnosti pouze NIA)
  4. Jakýkoliv nový identitní prostor musí být budován tak, aby byl federovaný v rámci kvalifikovaného systému elektronické identifikace (v současnosti pouze NIA)
  5. Prostředky pro identifikaci a autentizaci jsou vždy vydány bezpečnou a jednoznačnou cestou identifikované osobě tak, aby byla zajištěna minimálně úroveň důvěry značná. O tomto vydání prostředků existuje trvalý záznam spolu s údaji, jak byla ověřena identita osoby
  6. Osoba, jíž byly prostředky vydány, nedílně zodpovídá za ochranu těchto prostředků před odcizením a zneužitím
  7. Osoba, jíž byly prostředky vydány, nese nedílnou zodpovědnost za všechny úkony, které byly v informačním systému provedeny při použití těchto prostředků
  8. Věcný správce agend, které jsou vykonávány v rámci informačního systému, zodpovídá za obsazení osob do rolí (technicky vykonává technický správce informačního systému, vždy však na základě podkladů o věcných správců). Tuto svoji zodpovědnost může delegovat v rámci organizační struktury na více zodpovědných osob.

Pravidla pro Referenční rozhraní

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci Národní identitní autority je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k Referenčnímu rozhraní popíše úřad do své informační koncepce.

Způsob získání referenčních údajů

Webové služby

Prostřednictvím webových služeb může subjekt čerpat referenční údaje ze ZR. Subjekt, který působí v agendě, má tuto agendu řádně ohlášenou v RPP, má zaregistrovaný svůj agendový informační systém (také jako AIS) a vydaný platný certifikát od správy základních registrů (také jako SZR), přičemž na čerpání údajů musí mít vlastní zákonné zmocnění ve svém zákoně a dle zákona č.111/2009 Sb., o základních registrech, je tento subjekt oprávněn čerpat referenční údaje ze ZR prostřednictvím vnějších služeb informačního systému správy základních registrů (také jako ISZR).

Pro získávání referenčních údajů webovými službami je nezbytné nejdříve ztotožnit svůj datový kmen vůči ZR a následně se přihlásit pro příjem notifikací o změnách.

Czech POINT

Zkratka Czech POINT znamená Český Podací Ověřovací a Informační Národní Terminál. Jde o kontaktní místo veřejné správy, které poskytuje občanům zejména ověřené údaje vedené v centrálních registrech, jako jsou rejstřík trestů, obchodní rejstřík nebo registr živnostenského podnikání. Kromě standardních služeb, lze využít výpisy ze základních registrů podle zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů. Občané tak mají možnost ověřit si údaje, které jsou o nich v registrech vedeny, úředníci pak mají prostřednictvím formulářů v části CzechPOINT@office přístup k referenčním údajům ze základních registrů.

Jedním z cílů zavádění je zrychlit, zpřístupnit a zefektivnit služby občanům a dalším subjektům. Czech POINT je tedy kontaktním místem veřejné správy, které umožňuje na jediném místě získávat výpisy nebo činit podání.

Informační systém datových schránek

Pomocí datových schránek je možné zasílat dokumenty v elektronické podobě orgánům veřejné moci a také je takto od nich přijímat.

Komunikace prostřednictvím datových schránek nahrazuje klasický způsob doručování v listinné podobě, protože zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, zrovnoprávňuje papírovou a elektronickou verzi zasílaného dokumentu. Orgánům veřejné moci a právnickým osobám jsou datové schránky zřízeny automaticky, všem ostatním na základě jejich žádosti. Požádat o výpisy může každý, kdo má zřízenou datovou schránku a je oprávněnou osobou podle § 8 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů.

Portál občana a portál veřejné správy

Fyzické osoby (občané) mají možnost žádat o výpisy ze základních registrů prostřednictvím datové schránky na svém personalizovaném účtu portálu občana, pokud mají na portálu občana zřízenou datovou schránku a připojenou do svého profilu. Do portálu občana je možné se přihlásit datovou schránkou, jménem – heslem – SMS nebo elektronickou občankou s čipem, vydávanou od 1. 7. 2018.

Kdo může žádat o referenční údaje ze ZR
Webové služby

Subjekt státní správy svým AIS, který má zákonné zmocnění ve svém zákoně využívat referenční údaje ze ZR, působící v řádně ohlášené agendě v registru práv a povinností a má vydaný platný certifikát od správy základních registrů pro přístup do ZR. Dále soukromoprávní subjekt práva zprostředkovaně přes AIS některého z orgánu veřejné moci, který má opět zákonné zmocnění využívat údaje ze základních registrů v rámci přidělené agendy řádně ohlášené v RPP.        

Czechpoint

Na kontaktním místě, dle typu jednotlivých formulářů, které jsou v rámci Czechpoint k dispozici, může žádat fyzická, podnikající fyzická osoba i právnická osoba. Bližší informace, kdo může žádat u jednotlivého typu formuláře je k dispozici v sekci Typy žádostí pro získání referenčních údajů ze ZR.

Informační systém datových schránek

Informační systém datových schránek je prostředek pro získávání referenčních údajů ze základních registrů formou zaslání jednoho z formulářů v sekci  Typy žádostí pro získání referenčních údajů ze ZR. Požádat o výpisy může každý, kdo má zřízenou datovou schránku a je oprávněnou osobou podle § 8 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů. Ostatní subjekty si mohou datovou schránku zřídit volitelně.

Portál občana a portál veřejné správy

Žádat o výpis údajů ze základních registrů v rámci portálu občana má možnost podat každá fyzická osoba (občan), která má na svém personalizovaném účtu portálu občana zřízenou datovou schránku připojenou ke svému profilu. V rámci portálu veřejné správy, má možnost podat žádost o získání referenčních údajů ze základních registrů každý subjekt, který je uveden v sekci Typy žádostí pro získání referenčních údajů ze ZR, dle typu žádosti.    

Typy žádostí pro získání referenčních údajů ze ZR

Žádost o výpis údajů z registru obyvatel – dle § 58 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (fyzická osoba), o kterém jsou údaje vedeny.
  • Za subjekt práva podle § 58 odst. 9 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů, může žádat jeho zákonný zástupce.
  • Za subjekt práva může žádat zmocněnec na základě plné moci s úředně ověřeným podpisem zmocnitele.

Žádost o veřejný výpis údajů z registru osob – dle § 61 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat jakákoliv fyzická osoba (nemusí být subjektem práva).
  • Žádat lze o poskytnutí údajů o jakékoliv podnikající fyzické osobě, právnické osobě nebo orgánu veřejné moci.
  • Ve výpisu se objeví všechny údaje jako v neveřejném výpisu (viz níže) kromě osobních údajů osob, které jsou ve vazbě na registr obyvatel.

Žádost o výpis (neveřejný) údajů z registru osob – dle § 61 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (podnikající fyzická osoba nebo statutární orgán právnické osoby), o kterém jsou údaje vedeny v registru osob.

Žádost o záznam o využívání údajů v registru obyvatel – dle § 14 zák. č.111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (fyzická osoba), o kterém jsou údaje vedeny v registru obyvatel.
  • V žádosti subjekt uvede období, za které má být záznam poskytnut.
  • Každá fyzická osoba, která má zřízenu datovou schránku, obdrží vždy za uplynulý kalendářní rok bezplatně Záznam o využívání údajů v registru obyvatel automaticky do datové schránky, v souladu s § 14 odst. 4 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.
  • Informace, jak číst záznam o využívání údajů naleznete v praktické příručce: viz http://www.szrcr.cz/obcan-a-podnikatel

Žádost o záznam o využívání údajů v registru osob – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (podnikající fyzická osoba nebo statutární orgán právnické osoby), o kterém jsou údaje vedeny.
  • V žádosti subjekt uvede období, za které má být záznam poskytnut.
  • Každá podnikající fyzická a právnická osoba, která má zřízenu datovou schránku, obdrží vždy za uplynulý kalendářní rok bezplatně Záznam o využívání údajů v registru osob automaticky do datové schránky, v souladu s § 14 odst. 4 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o změnu údajů při zjištění nesouladu v registru obyvatel – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • O změnu údajů při zjištění nesouladu v registru obyvatel může žádat subjekt práva (fyzická osoba).
  • Na základě žádosti dojde k podání návrhu na změnu referenčních údajů vedených o subjektu práva v registru obyvatel.
  • Dojde-li ke změně referenčního údaje, obdrží fyzická osoba, která má zřízenu datovou schránku, bezplatně Výpis referenčních údajů automaticky do datové schránky, v souladu s § 14 odst. 5 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o změnu údajů při zjištění nesouladu v registru osob – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • O změnu údajů při zjištění nesouladu v registru osob může žádat subjekt práva (podnikající fyzická osoba nebo statutární orgán právnické osoby).
  • Na základě žádosti podává žadatel návrh na změnu referenčních údajů vedených o osobě v registru osob.
  • O změnu údajů při zjištění nesouladu v registru osob může žádat podnikající fyzická osoba nebo statutární orgán právnické osoby.
  • Dojde-li ke změně referenčního údaje, obdrží každá podnikající fyzická nebo právnická osoba, která má zřízenu datovou schránku, bezplatně Výpis referenčních údajů automaticky do datové schránky, v souladu s § 14 odst. 5 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o poskytnutí údajů z registru obyvatel třetí osobě – dle § 58a zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Na základě žádosti poskytne subjekt práva (fyzická osoba) své údaje jiné fyzické nebo právnické osobě.
  • Těmto je možné poskytnout všechny nebo vybrané údaje vedené k Vaší osobě v registru obyvatel.
  • Orgánu veřejné moci není nutné poskytnout Vaše údaje tímto způsobem, neboť tento má povinnost si referenční údaje zjistit.

Žádost o odvolání poskytnutí údajů z registru obyvatel třetí osobě – dle § 58a zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Na základě žádosti přestanou být poskytovány Vaše údaje jiné fyzické nebo právnické osobě. Dojde k odvolání Vámi vybraných předchozích souhlasů s poskytnutím údajů třetí osobě učiněných žádostí výše.
Poplatky spojené s žádostmi o výpisy
  • Portál občana a portál veřejné správy – podání žádostí datovou schránkou využitím formulářů uveřejněných na Portálu občana a portálu veřejné správy a vydání výpisů je bezplatné.
  • Czech POINT – žádosti podané prostřednictvím kontaktního místa veřejné správy Czech POINT jsou zpoplatněny, avšak podání žádostí o změnu referenčních údajů a poskytnutí/odvolání poskytnutí referenčních údajů třetí osobě jsou bezplatné.

Povinnost využívat referenční rozhraní

Povinnost využívat referenční rozhraní pro uskutečňování takzvaných "vazeb" mezi jednotlivými informačními systémy veřejné správy ukládá zákon o informačních systémech veřejné správy. Tedy obecně platí, že pro sdílení údajů, výměnu údajů a propojování jednotlivých informačních systémů veřejné správy různých správců, má být primárně využíváno právě referenční rozhraní. U informačních systémů stejného správce toto nemusí platit vždy, pokud se nevyužívá překlad agendových identifikátorů při komunikaci o subjektu práva vedené v rámci dvou nebo více agend.

Je nutné zdůraznit, že pouze využitím referenčního rozhraní je korektně prováděn překlad AIFO (AIFO jedné osoby v jedné agendě nesmí být poskytnuto jiné agendě). Pouze referenční rozhraní je napojeno na registr ORG a provádí překlad AIFO.

Možnost využívat referenční rozhraní

Mimo povinnost pro správce informačních systémů veřejné správy, je zde i možnost využití referenčního rozhraní, resp. služeb, které poskytuje, i pro jiné subjekty. Konkrétně jde o subjekty typu SPUÚ (Soukromoprávní uživatel údajů) dle zákona 111/2009 Sb., kteří pro využití služeb referenčního rozhraní potřebují zákonné zmocnění.

Užívání referenčního rozhraní při výměně údajů v rámci propojeného datového fondu

Výměna/sdílení údajů mezi jednotlivými informačními systémy veřejné správy se realizuje výhradně prostřednictvím referenčního rozhraní, a to konkrétně komponenty eGSB/ISSS. Jak se upřesňuje v části propojený datový fond, tak výměna údajů se realizuje vždy v rámci kontextu na subjekt práva.

Přístup ke službám referenčního rozhraní je na síťové úrovni možný pouze prostřednictvím Centrálního místa služeb (CMS), potažmo komunikační infrastruktury veřejné správy (KIVS), které můžeme nazvat privátní sítí pro výkon veřejné správy na území státu.

Správci agendových informačních systémů musejí realizovat napojení na referenční rozhraní, a to podle příslušných metodických dokumentů a provozních řádů:

Užívání referenčního rozhraní pro čerpání referenčních údajů

Správci agendových informačních systém se kromě provozních řádů řídí i dalšími postupy a to především legislativními. Současný stav (rok 2020) stále nutí k zákonnému zmocnění pro využívání referenčních údajů. V

Užívání referenčního rozhraní pro poskytování agendových údajů

Správci agendových informačních systémů poskytujících údaje z daných agend realizují napojení svých AISů na eGSB/ISSS v roli publikátora a kontrolu oprávnění k využívání údajů podle oprávnění v RPP. Pro výměnu údajů vybudují služby svého AIS tak, aby mohly být volány a zprostředkovány eGSB/ISSS.

Užívání referenčního rozhraní pro čerpání agendových údajů

Správci agendových informačních systémů využívajících údaje poskytované jinou agendou realizují volání služeb eGSB/ISSS (nemusí znát konkrétní AIS, požadují údaje od agendy), a to jen tehdy, pokud k tomu mají příslušné oprávnění zapsané u agendy poskytovatele v RPP.

Užívání referenčního rozhraní při zápisu a editace údajů v základních registrech

Editoři referenčních údajů v základních registrech realizují napojení svých editorských agendových informačních systémů na ISZR službami vnějšího rozhraní podle příslušné dokumentace Správy základních registrů a v případech, kdy agendové informační systémy nejsou též samostatnými evidencemi dokumentů, pak napojení těchto systémů na eSSL v rámci vnitřních vazeb. Pro editaci údajů a vyřizování reklamací údajů v základních registrech nevyužívají jiné rozhraní než právě ISZR.

Pravidla pro Univerzální kontaktní místo veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci univerzálního kontaktního místa je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k univerzálním kontaktním místům popíše úřad do své informační koncepce.

Úřad musí při tvorbě a správě svých služeb zohlednit možnost vyřízení služby jak samoobslužně, tak asistovaně. Primární odpovědnost za toto rozhodnutí nese věcný správce služby, což např. u služeb v přenesené působnosti není vždy daný úřad. Může však být dána určitá vlastní zodpovědnost za způsob, jakým je umožněno danou službu v přenesené působnosti vyřídit a pokud tuto možnost věcný správce poskytuje, je úřad povinen zohlednit všechny možnosti vyřízení. Nesmí také nastat situace, kdy služba veřejné správy, která je publikována pro samoobsluhu klienta nebude obsahovat všechny možnosti vyřízení, které má k dispozici v asistované formě.

Samoobslužná univerzální kontaktní místa

Aby se plně podporovala samoobsluha služby veřejné správy, musí splnit následující podmínky:

Asistovaná univerzální kontaktní místa

Při provozování asistovaných univerzálních kontaktních míst je potřeba zajistit přidělení rolí v CzechPOINT pro pracovníky poskytující jeho služby skrze správce, tzv. lokálního administrátora.

V rámci asistovaných univerzálních kontaktních míst je nutné počítat s neustálým rozvojem a přidáváním služeb, které musí v co největší míře odpovídat těm samoobslužným. Žádná samoobslužná služby nesmí být bez své asistované varianty, která však může být řešena i v rámci úřadu, pokud tak vyžaduje její specifická náročnost (například daňové přiznání).

Pravidla pro Systém správy dokumentů

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci správy dokumentů je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k systémům správy dokumentů popíše úřad do své informační koncepce.

Spisovou službu považujeme za společnou schopnost na úrovni úřadu (capability), kde většina principů je shodných napříč celým úřadem (motivační vrstva, aplikační vrstva ESSL a integrace, byznysová vrstva procesů a funkcí a interakcí) a na úrovni jednotlivých agend se odlišuje dle výkonu dané agendy minimálně. Architekturu výkonu spisové služby tedy je třeba zahrnout do mapy schopností úřadu.

Při zpracování Enterprise architektury úřadu i při zpracování a realizaci jednotlivých architektur, týkajících se ať už agend nebo schopností, nebo jejich řešení, je nutno zahrnout spisovou službu jako obecnou schopnost a správným způsobem řešit její realizaci. Je přitom nutno zvážit, do jaké míry je faktický i technický výkon spisové služby společný v rámci celé organizace a jestli a jakým způsobem se bude lišit v rámci jednotlivých agend či řešení. Jednoznačným doporučením je mít jeden elektronický systém spisové služby a u ostatních informačních systémů, včetně agendových informačních systémů a provozních informačních systémů, zajistit úkony spojené se správou dokumentů (příloh k transakcím) a s výkonem spisové služby formou integrace na elektronický systém spisové služby předepsaným rozhraním.

Součástí architektury úřadu by tedy z pohledu spisové služby měly být vždy alespoň následující elementy:

  • Elektronický systém spisové služby (splňující požadavky Národního standardu) včetně modulů podatelny a výpravny umožňující příjem a odesílání i digitálních dokumentů správnými komunikačními kanály
  • Jmenný rejstřík (může být i samostatnou komponentou), nejlépe integrovaný na rejstřík kmenových dat klientů úřadu, notifikovaný ze základních registrů.
  • Spisovna pro uchování uzavřených spisů a vyřízených digitálních dokumentů po dobu skartační lhůty
  • Rozhraní ESSL zajišťující úkony spojené s dokumenty a procesy evidence dokumentů a správy jejich metadat v ESSL formou aplikačních služeb pro další informační systémy úřadu (agendové, provozní)
  • Informační systémy spravující dokumenty integrované na rozhraní ESSL

Jelikož legislativa obecně počítá s tím, že v rámci úřadu je vždy provozován jeden ESSL a ostatní agendové a provozní informační systémy jsou na něj integrovány a úkony spojené s dokumenty se realizují formou rozhraní ESSL, měla by v úřadu být implementována integrace všech informačních systémů spravujících dokumenty (pokud nejsou samy samostatnou evidencí dokumentů v elektronické podobě) s ESSL a samotný ESSL navázán na úložiště pro uchovávání komponent digitálních dokumentů. Na obrázku níže je znázorněn obecný stav pochopení integrace elektronického systému spisové služby za využití jednoho centrálního úložiště pro digitální dokumenty.

Hovoříme-li o integraci informačního systému s elektronickým systémem spisové služby a o správě úkonů spojených s dokumentem, může tato integrace být na úrovni byznysových objektů a jejich metadat řešena v souladu s následujícími pravidly:

  1. Digitální dokument, respektive jeho komponenty a datové soubory, jsou uloženy v úložišti digitálních dokumentů, které zajišťuje péči o digitální soubory
  2. Metadata o dokumentu jsou spravována evidenčním nástrojem, tedy:
    • Elektronickým systémem spisové služby, nebo
    • informačním systémem, který plní funkci samostatné evidence
  3. Se soubory v úložišti jsou oprávněny pracovat:
    • elektronický systém spisové služby, nebo
    • informační systém sloužící jako samostatná evidence, nebo
    • informační systém integrovaný na ESSL prostřednictvím ESSL
  4. Ve Jmenném rejstříku se vede evidence údajů o subjektech, jejichž se týkají dokumenty evidované ve spisové službě

Vazby na architekturu agendového informačního systému

V rámci architektury každého informačního systému veřejné správy sloužícího pro podporu výkonu činností agendy veřejné správy je nutno myslet také na oblast výkonu spisové služby. Vzhledem k tomu, že prakticky v každé agendě veřejné správy se buď vytváří, nebo zpracovávají, nebo odesílají, nebo evidují dokumenty, anebo u ní dochází k zápisu záznamu do spisu (z pohledu legislativy týkající se spisové služby), je nutno zajistit úkony spojené se spisem a dokumentem. Vesměs existují dvě formy, jak zajistit povinnosti výkonu spisové služby v souvislosti s daným AISem, a to následující:

  1. Integrovat AIS na ESSL prostřednictvím předepsaného rozhraní a zajistit, aby úkony spojené s dokumentem vykonával AIS prostřednictvím tohoto rozhraní.
  2. Zajistit, aby daný AIS splňoval požadavky Národního standardu pro ESSL kladené na tzv. „samostatnou evidenci“ a vykonávat úkony spojené s dokumenty a všechny procesy týkající se výkonu spisové služby v samostatné evidenci tímto systémem.

Vazby na architekturu provozních systémů

Velice často se zapomíná na to, že výkon spisové služby se týká všech dokumentů, a tedy nejen úředních dokumentů typu podání a rozhodnutí v rámci výkonu agend veřejné správy. U veřejnoprávních původců se jedná o evidenci a správu veškerých dokumentů (s výjimkou těch, které si daný původce odůvodněně vyňal z evidence ve svém spisovém řádu), a tedy je nutno zajistit výkon spisové služby v elektronické podobě také pro pracovní a provozní a neúřední dokumenty. To se týká jak dokumentů pracovního charakteru (zápisy z porad, organizační a řídící dokumenty, řídící akty, interní sdělení), tak ale také všech dokumentů ekonomického a provozního charakteru (faktury, objednávky, smlouvy ekonomické doklady, personální dokumentace, žádanky, závěrky a výkazy apod.).

V případě provozních informačních systémů jednoznačně doporučujeme jejich integraci na elektronický systém spisové služby. Zejména u ekonomických informačních systémů, systému pro řízení personalistiky a mezd a zdrojů a dalších manažerských informačních systémů týkajících se různých žádanek, evidencí, a workflow procesů, se dost často na výkon spisové služby zapomíná. Zde je vhodná integrace na ESSL, neboť zajištění splnění všech požadavků Národního standardu na samostatné evidence pro tyto systémy by s sebou přineslo neúměrné finanční náklady spojené s pořízením a rozvojem těchto provozních IS. Integrací na ESSL se také zajistí řádné realizování skartačních řízení u těchto druhů dokumentů.

Souvislosti s architekturou údajů o subjektech

Určení původci jež vykonávají spisovou službu v elektronické podobě musejí podle § 64, odst. 4 až 8, Zákona č. 499/2004 Sb., o archivnictví a spisové službě provozovat jako samostatnou komponentu takzvaný "Jmenný rejstřík", kam źapisují určené minimální údaje o všech subjektech, kterých se týkají jimi evidované dokumenty.

Realizace propojení jmenného rejstříku a ostatních komponent, respektive realizace procesů evidence subjektů je následující:

  • V úřadu je u každého ESSL jako logická komponenta i Jmenný rejstřík. Funkce Jmenného rejstříku může za splnění všech dalších podmínek zastávat i zdroj evidence subjektů.
  • Do jmenného rejstříku se evidují údaje o všech subjektech kterých se týkají evidované dokumenty a to s využitím AIFO fyzických osob v agendě spisové služby, nikoliv v agendách, ve kterých se o osobách úřaduje. Pro vazby jmenného rejstříku na eSSL a další evidence dokumentů je třeba využívat interní identifikátor, nikoliv AIFO.
  • Evidence subjektů ve Jmenném rejstříku a evidence subjektů za účelem úřadování v agendě jsou dvě oddělené věci, proto je nutno dbát na správné postupy, viz související kapitoly k evidenci subjektů a identifikátorům.

Možné způsoby zajištění digitální kontinuity dokumentů

Je velmi důležité pamatovat na problematiku digitální kontinuity a o své elektronické dokumenty se aktivně starat. Veřejnoprávní původci musí zajistit evidenci dokumentů a to buď v systému spisové služby, nebo v samostatných evidencích dokumentů. Oba výše uvedené způsoby pak musí splňovat požadavky Národního standardu pro elektronické systémy spisové služby v souladu se zákonem č. 499/2004 Sb. Zaměříme-li se na elektronické dokumenty ve smyslu nařízení eIDAS, pak budeme hovořit o elektronickém systému spisové služby a elektronických evidencích dokumentů. Jedním z klíčových požadavků Národního standardu je existence tzv. transakčního protokolu – zápisu provedených operací uskutečněných v rámci elektronického systému spisové služby nebo v rámci samostatné evidence dokumentů v elektronické podobě. Transakční protokol v případě elektronických dokumentů zajišťuje, že od okamžiku zaevidování dokumentu až do okamžiku jeho předání do archivu nebo okamžiku vyřazení a zničení je systematicky evidována jakákoliv operace týkající se evidovaného dokumentu. Tímto je zcela jednoznačně po dobu životního cyklu dokumentu zajištěno, že lze v rámci evidenčního systému garantovat určité vlastnosti elektronického dokumentu, zejména pak věrohodnost původu a neporušenost obsahu. U každého elektronického dokumentu musí být rovněž zajištěna po celou dobu životního cyklu jeho čitelnost, a to jak v technickém slova smyslu, tak z pohledu jeho uživatelsky vnímatelné podoby.

U veřejnoprávních původců je s ohledem na výše zmíněný požadavek prokázání věrohodnosti původu a neporušitelnosti obsahu dokumentu stanovena zákonná povinnost ověřování elektronických podpisů, elektronických pečetí a elektronických časových razítek, pokud je příchozí elektronický dokument obsahuje. Uvedení původci jsou ze zákona povinni výsledky ověření zaznamenat ve svých evidenčních systémech, které jak bylo uvedeno výše, musí splňovat zákonem stanovené požadavky, včetně požadavku na vedení transakčního protokolu. Proto není nutné po prvotním ověření u veřejnoprávních původců používat takové metody, jaké se používají běžně pro zajištění „věrohodnosti původu“ u soukromoprávních původců - například není nutné opětovně opatřovat elektronické dokumenty časovými razítky před jejich expirací a podobně - věrohodnost původu elektronických dokumentů je u veřejnoprávních původců zajištěna řádnou systematickou evidencí dokumentů v určených systémech, kde je navíc pomocí transakčního protokolu možné po celou dobu životního cyklu dokumentu prokázat veškeré operace, které se s evidovaným dokumentem uskutečnily - tj. pro prokázání věrohodnosti původu je zcela dostačující systematická evidence a transakční protokol.

Výše uvedené lze u veřejnoprávních původců i snadno ověřit – audit systémů zajišťujících vedení spisové služby je možné realizovat v průběhu času a každý veřejnoprávní původce má zákonem stanovenou povinnost kontroly těchto činností. Elektronické systémy spisové služby, ale i některé významné samostatné evidence dokumentů (typicky agendové informační systémy), splňují z pohledu zákona o kybernetické bezpečnosti charakteristiku tzv. významného informačního systému, neboť v případě jejich výpadku nebo nesprávného fungování by veřejnoprávní původci nemohli plnit řádně a souvisle svůj výkon. S ohledem na to by tyto měly být jako významné informační systémy identifikovány a oznámeny Národnímu úřadu pro kybernetickou a informační společnost procedurou dle kybernetického zákona. Tím se tyto systémy dostanou rovněž pod pravidelný dohled útvarů zajišťujících kybernetickou bezpečnost.

Elektronické systémy spisové služby a samostatné evidence dokumentů též zpracovávají osobní údaje fyzických osob, proto veřejnoprávní původci nad těmito systémy mají s ohledem na povinnosti vyplývající z obecného nařízení na ochranu osobních údajů a ze zákona o zpracování osobních údajů řadu povinností, které též zvyšují celkovou důvěryhodnost systémů, ve kterých veřejnoprávní původci evidují své dokumenty.

Výše uvedenými opatřeními lze u veřejnoprávních původců zcela spolehlivě prokázat věrohodnost původu a to i u přijatých dokumentů obsahující elektronické podpisy, elektronické pečetě a elektronická časová razítka a to bez nutnosti jejich opětovného opatřování časovými razítky nebo jinými autentizačními či autorizačními prvky.

Možné problémy

Možným rizikem zajištění digitální kontinuity založeného na základě transakčních protokolů eSSL je problematika kolizních dokumentů. Jedná se o situaci, kdy je do transakčního protokolu v souladu s NSeSSS poznamenán otisk (tzv. hash) dokumentu spolu s označení použitého hashovacího algoritmu, ovšem stejný hash může odpovídat i jiným dokumentům. Následně není možné, především u přijatých dokumentů, dovodit o jakém dokumentu (skrze jeho hash) transakční protokol pojednává, což výrazně komplikuje případné dosvědčení právní validity.

Pro eliminaci tohoto rizika, lze využít postupy, kterými se prodlužuje ověřitelnost podle standardu ETSI (The European Telecommunications Standards Institute) a který odpovídá předpisům eIDAS. Jde tedy o opakovaného přidávání kvalifikovaných elektronických časových razítek a validačních informací sloužící k prodlužování možnosti ověření platnosti podpisů a pečetí na elektronických dokumentech. Zjednodušeně lze říci, že tato opatření mají charakter nového elektronického podepsání, nového zapečetění či nového opatření kvalifikovaným elektronickým časovým razítkem. Tyto možnosti totiž znamenají, že se na autentizaci původního dokumentu použijí aktuálně dostatečně silné kryptografické postupy a algoritmy (konkrétně dostatečně robustní hashovací funkce a dostatečně velké klíče), a tím je – opět na určitou dobu – dostatečně ztíženo hledání kolizních dokumentů. Vzhledem k různým právním účinkům elektronických podpisů (představujících projev vůle), elektronických pečetí (představujících vyjádření původu) a časových razítek (představujících „fixaci v čase“) se v praxi, k prodloužení možnosti ověření platnosti původních podpisů a pečetí, využívají právě kvalifikovaná elektronická časová razítka. Důležité je, aby každý jednotlivý krok tohoto dlouhodobého procesu byl proveden včas. Tedy aby další časové razítko bylo přidáno ještě dříve, než zaúčinkuje tzv. časová pojistka (než skončí v čase omezená možnost ověření původního podpisu či pečeti). Případně promeškání nejzazšího okamžiku způsobí, že pozdě přidané časové razítko již nemá prodlužující účinek.

V praxi přitom není nutné (včas) přidávat časová razítka k jednotlivým dokumentům. Vhodnými postupy je možné minimalizovat spotřebu časových razítek, například společným umístěním více dokumentů (či pouze jejich otisků) do vhodného kontejneru (ASiC), a časovými razítky opatřovat pouze kontejner jako takový. Sdružování do kontejnerů je vhodné dle logického spojení dokumentů, například do úrovně spisů. Stejně tak není podstatné, kdo podniká výše naznačená opatření, nutná pro zajištění digitální kontinuity dokumentů.

Je však nutné konstatovat, že ač riziko kolizních dokumentů existuje, současné legislativní prostředí nedává veřejnoprávním původcům dostatečný prostor k rozhodnutí a vlastnímu zvážení rizik a dodatečné připojování elektronických pečetí či časových razítek by mohlo být v rozporu s péčí řádného hospodáře, neboť u nákladů na zajištění takového postupu by se mohlo jednat o neúčelně vynaložené prostředky veřejného rozpočtu.

Pravidla pro Systémy a služby spojené s právním řádem a legislativou

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci systémů a služeb spojených s právním řádem a legislativou je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k systémům a službám spojených s právním řádem a legislativou popíše úřad do své informační koncepce.

Míra možnosti a dokonce povinnosti využívat výše zmíněné informační systémy a jejich sdílené služby závisí na tom, v jakém postavení vůči konkrétní legislativě je příslušný úřad.

V tomto případě tedy můžeme rozdělit úřady do třech následujících kategorií:

  • Gestor legislativy: Je zodpovědný za přípravu, provádění procesu připomínkování a projednání a následnou realizaci schválené legislativy. Gestor by také měl pravidelně provádět zhodnocení platné legislativy a na základě toho navrhovat její úpravy.
  • Spolupracující subjekt: Jedná se o subjekt, který se aktivně podílí na spolutvorbě legislativy a je aktivně zapojen do procesu připomínkování a vyhodnocování daných návrhů
  • Uživatel legislativy: Jedná se o subjekt, který se Danou legislativou řídí ať už v rámci veřejnoprávní činnosti jako výkon působnosti v dané agendě, nebo je pro něj příslušná legislativa jinou formou nějak závazná a ovlivňuje jeho činnost

V Každé z těchto třech základních rolí mohou být výše zmíněné informační systémy aktivně používány.

Nesmí se zapomínat ani na povinnosti výkonu spisové služby, ty se pochopitelně vztahují i na procesy návrhu a projednávání legislativy. Jsem-li tedy gestor za legislativu, především si zajistím integraci svých autorských systémů na ESSL a následně i integraci na závazně používané informační systémy (eLegislativa, ODOK, EKLEP, apod.).

Při vyhodnocování a následné přípravě návrhů na změnu jsou dvěma klíčovými zdroji platná legislativa (aktuální znění právních předpisů a jejich vazeb) a dopad na faktický výkon (zdrojem je RPP a agendový model a seznam úkonů v agendě). Pomocí vazeb s ostatními právními předpisy si také úřad zmapuje souvislosti na další schopnosti. Třeba u agendového zákona je třeba zohlednit i povinnosti spisové služby, povinnost nevyžadovat údaje, které již mám, apod. I s ohledem na to je vhodné jako zdroj mít vždy aktuální či očekávaná znění právních předpisů.

Při tvorbě architektury je pak nanejvýš vhodné mít prvky architektury s vazbou na příslušnou legislativu. Například pokud spravuji informační systém, tak ten slouží pro podporu procesu v zákoně. Tedy vím, že systém provozuji na základě zákona o ISVS a na základě příslušných agendových zákonů a požadavky na funkce musi zajistit realizaci příslušných procesů v jednotlivých zákonech.

Zdroje informací o právních předpisech a jejich promítnutí do agend veřejné správy se hodí i pro tvorbu a aktualizaci vnitřních směrnic a předpisů v organizaci. Kupříkladu, změní-li se legislativa k základním registrům či ke spisové službě, vím, že to bude mít dopad na moje procesy a tedy i na předpisy a směrnice jež procesy určují. Dojde tedy jistě ke změnám agendových procesních metodik, ke změně Spisového řádu, apod. K tomu také mám využívat výše zmíněné zdroje a zajistit jejich integraci na komponenty, které využívám k udržování dokumentace.

Pokud daný úřad není gestorem za příslušnou legislativu, ale přesto je pro něj legislativa závazná, pak by měl také splnit některé z výše uvedených základních principů. Aktuální údaje o stavu právních předpisů včetně vazby mezi jednotlivými ustanoveními a jednotlivými právními předpisy musí sloužit jako základ pro byznysovou architekturu. Druhým zdrojem jsou pak údaje v registru práv a povinností.

Je vhodné tedy:

  • Vybudovat a udržovat mechanismus, jak pokud možno automatizovaně zpracovávat dekomponované právní předpisy
    • Lze realizovat s využitím služeb ESbírky, či obdobného systému
    • Zajistit si notifikace o aktualizacích právních předpisů, jež mě zajímají a o aktualizacích vazeb z jiných právních předpisů na ně
  • Vytvořit procesy a podporu pro sledování návrhů změn a stavu jejich projednávání
  • Být schopen přiřadit klíčové elementy architektury ke konkrétním ustanovením či alespoň ke konkrétním právním předpisům
  • Udržovat povědomost o všech právních předpisech, kterými se řídím

Z hlediska aplikační architektury očekává NAP následující změny na centrální i lokálních úrovních:

  • Po dokončení systému eSbírka (a doběhnutí stávajících kontraktů nejpozději do 5 let - udržitelnost) přestanou úřady do svého portfolia zařazovat aplikace pro seznamování se s právem od komerčních dodavatelů a přejdou na eSbírku. Komerční aplikace s redukovanými licencemi mohou zůstat pro doplňkové služby jako jsou výklady práva, judikáty a další obsah, který ještě nebude zahrnut do eSbírky nebo si ponechá soukromoprávní (komerční) charakter.
  • Po dokončení systému eLegislativa se změní úloha systémů EKLEP/VEKLEP. Jakmile eLegislativa přinese převážnou část potřebných funkcí, význam uvedených systémů se bude snižovat - o jejich pánu rozvoje/ ukončení ještě bude nutno jednat.
  • Systém ODOK musí být integrován na systém eLegislativa.

Od okamžiku spuštění systému eSbírky a eLegislativy budou všechny úřady povinny ve svých systémech a propojených materiálech používat pouze odkazy do eSbírky a nikoliv textové vyjádření formou např. §1 zákona č. 100/2000 Sb.

Pravidla pro Elektronické úkony a doručování

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci elektronických úkonů a doručování je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k elektronickým úkonům a doručování popíše úřad do své informační koncepce.

Úřadu je doporučeno využívat systém ISDS jako integrální součást své elektronické spisové služby. Úřady musí mezi sebou komunikovat prostřednictvím systému ISDS a svých datových schránek, pokud se jedná o výměnu dokumentů a jejich zaručeného doručení. Pokud se jedná o výměnu údajů mezi úřady, nevyužívají se datové schránky, ale propojený datový fond a jeho refereční rozhraní. Je nutné brát v potaz, že veškeré úkony činěné skrze datovou zprávu směrem do úřadu od klienta VS se pokládají za elektronicky podepsané a není potřeba po klientovi vyžadovat žádné další formy autorizace.

ISDS umožňují na vyžádání u věcného správce (Ministerstva vnitra) využívat identitní prostor datových schránek k přihlašování do vlastních řešení - typicky portálů. Tento způsob identifikace a autentizace klienta VS bude umožněn pouze do 1.7.2020, kdy vyprší přechodné ustanovení zákona 250/2017 Sb., které zavádí povinnost využívat systém Národní identitní autority .

Pro zajištění digitální kontinuity datové zprávy, podobně jako v části Systém správy dokumentů, je z pohledu uživatele (příjemce) nutné si vždy uložit nejen přijatý dokument, ale celou datovou zprávu (obálka + dokument). Tato celá datová zpráva lze kdykoliv zpětně věřit proti samotnému informačnímu systému datových schránek, samotný dokument však ne.

Pravidla pro Jednotný identitní prostor veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci jednotného identitního prostoru veřejné správy je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k jednotnému identitnímu prostoru popíše úřad do své informační koncepce.

Úřad musí zajistit propojení svého identitního systému (AD/LDAP/IDM) se systémem Jednotného identitního prostoru (také jako JIP/KAAS) pro tu část zaměstnanců, kteří se přihlašují k informačním systémům veřejné správy. Využití může být provedeno 2 druhy:

  • Vytvoření vlastních aplikačních rolí pro systémy, jejichž je OVM správce
  • Využití existujících rolí v registru práv a povinností

Pro uživatele, kteří nejsou pokrytí centrální licencí provozovatele, lze zakoupit licenci zvlášť. Cena takovéto licence je pro 1 uživatele přibližně 2 000 Kč za první rok a 500 pro další roky.

Pravidla pro Jednotné obslužné kanály a uživatelská rozhraní úředníků

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci jednotných obslužných kanálů a uživatelských rozhraní úředníků je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k jednotným obslužným kanálům a UI úředníků popíše úřad do své informační koncepce.

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Pravidla pro Sdílené služby INSPIRE

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci sdílených agendových IS v přenesené působnosti je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu ke sdíleným službám INSPIRE popíše úřad do své informační koncepce.

Stručný přehled povinností pro naplnění technických požadavků INSPIRE (detailně viz Strategie implementace INSIRE):

  1. vytvořit, zpřístupňovat a aktualizovat metadata dat a služeb INSPIRE (v souladu s nařízením (ES) č. 1205/2008); Metadata musí být zpřístupněna na Národní geoportál INSPIRE buď pomocí služby vytvořené nad katalogem každého poskytovatele nebo uložením metadat do katalogu geoportálu. Metadaty je možné popsat i aplikace využívající prostorová data.
  2. zpřístupňovat vyhledávací a prohlížecí síťové služby (v souladu s nařízením (ES) č. 976/2009); Požaduje se vytvořit vyhledávací službu, která umožní vyhledat služby na základě specifikovaných vyhledávacích kritérií, a prohlížecí službu, která umožní datové sady zobrazit.
  3. vytvořit a aktualizovat nově vytvořené nebo rozsáhle rekonstruované datové sady; Požaduje se publikovat prostorová data ve formátu GML dle datových specifikací maximálně do 6 měsíců od počátku jejich platnosti v produkčních databázích, sledovat jejich kvalitu a informace o ní zpřístupnit v metadatech.
  4. zpřístupňovat stahovací a transformační síťové služby (mít je v souladu s nařízením (ES) č. 976/2009); Požaduje se umožnit stahování INSPIRE datových sad on-line (WFS) nebo tzv. předpřipravených datových sad off-line způsobem. Transformační služby musí umožňovat transformovat datové sady neharmonizovaných dat ve formátu GML do požadovaného geodetického referenčního systému. Je požadováno zajistit kvalitu služby a popsat ji v metadatech;
  5. poskytovat přístup k datovým sadám a službám orgánům a subjektům Evropské unie (v souladu s nařízením (EU) č. 268/2010); Požaduje se poskytovat datové sady nebo služby orgánům a subjektům Evropské unie do 20 dnů od doručení žádosti s možností využití standardizované licence.
  6. mít interoperabilní a harmonizované služby prostorových dat v souladu s nařízením (EU) č. 1089/2010; mít v souladu s novelizovaným nařízením (ES) č. 976/2009 služby umožňující spuštění služeb založených na prostorových datech; Požaduje zpřístupnit informace o kvalitě služeb a doplnit ke službám další operace zajišťující interoperabilitu (do října 2020).

Při implementaci technických požadavků Směrnice INSPIRE je nutné náročnosti jednotlivých činností poskytovatelů dat dále rozlišit podle role ve vztahu k tvorbě, správě a rozvoji infrastruktury INSPIRE. Zapojení všech dotčených subjektů do infrastruktury INSPIRE předpokládá jejich rozdělení do různých rolí ve vztahu k prostorovým datům, službám založených na prostorových datech, anebo aplikacím, které jsou nad daty nebo službami vytvořeny. Je samozřejmostí, že jeden poskytovatel může vystupovat ve více rolích:

  • Povinný subjekt (definován v § 2 písm. b) zákona č. 123/1998 Sb.)
  • Jiný poskytovatel (definován v § 11a odst. 3 zákona č. 123/1998 Sb.)
  • Gestor národní datové sady INSPIRE – povinný subjekt odpovědný za konsolidaci a publikaci výsledné národní datové sady INSPIRE, pokud je jediným poskytovatelem pro dané téma příloh Směrnice INSPIRE. V opačném případě koordinuje spolugestory přispívající svými prostorovými daty do obsahu národní datové sady INSPIRE (přesně a úplně definován ve Strategii implementace INSPIRE)
  • Spolugestor národní datové sady INSPIRE - Jeden či více povinných subjektů k danému tématu příloh Směrnice INSPIRE, který odpovídá za harmonizaci příslušné části NDSI (přesně a úplně definován ve Strategii implementace INSPIRE)

Tabulka uvádí základní přehled oblastí, které jsou pro jednotlivé role závazné:

Pravidla pro Sdílené agendové IS v přenesené působnosti

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci sdílených agendových IS v přenesené působnosti je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu ke sdíleným agendovým IS pro přenesenou působnost popíše úřad do své informační koncepce.

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Pravidla pro Sdílené agendové IS pro samostatnou působnost územních samospráv

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci sdílených agendových IS pro samostatnou působnost je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu sdíleným agendovým IS pro samostatnou působnost popíše úřad do své informační koncepce.

OVS, které musí vybudovat IT podporu pro samosprávné agendy a mají pro to k dispozici potřebné zázemí (infrastrukturu, kapacity, znalosti), typicky ORP (zejména statutární města a bývalá okresní města) nebo kraje, mohou poskytnout podporu v malým obcím (1. a 2. typu) ve svém správním území. A to za podmínek daných změnami legislativy, ke kterým bude muset pro plnou realizaci tohoto konceptu dojít. Stejná forma sdílení je možná mezi těmito úrovněmi samosprávy i v případě spisové služby a provozních systémů, pokud malé obce nevyužijí možnosti sdílení centrálních služeb, budou-li k dispozici.

NAP doporučuje municipalitám pro určitou dílčí sadu sdílených služeb použít jako základní prvek správní obvody ORP a vychází z následujících předpokladů:

  • ORP jsou nejmenšími subjekty, které zpracovávají architektonický plán.
  • Správní obvod ORP je jednoznačně dán a všechny subjekty, kterých se bude sdílení ve správním obvodě týkat, jsou známy.
  • Poskytování služeb a dat je určeno standardy (např. u spisové služby).
  • Tento model již v řadě ORP funguje.

Pro jiné sdílené služby (například dlouhodobé ukládání dokumentů v elektronických digitálních spisovnách) se mohou využít technologická centra krajů, neboť:

  • Mají vybudovanou infrastrukturu
  • Disponují IT kapacitami a kompetencemi

Pro další sdílené služby, například pro aplikační služby ekonomických systémů nebo spisových služeb, bude možné v dohledné době 3 let (2022) využít SaaS služby eGovernment Cloudu, protože:

  • Procesy a o IT potřeby v těchto oblastech fungování samospráv jsou vysoce standardizované a opakovatelné, proto jsou velmi vhodné pro řešení v cloudu
  • Tyto funkce a jejich podpora zůstávají v plné zodpovědnosti obcí, a proto tyto potřebují multi-tenantní řešení

Sdílené aplikační služby kraje

Doporučujeme, aby kraje pro obce zřídily a poskytovaly služby například informačního systému spisové služby.

Krajské sítě

Publikace služeb krajských center do krajské sítě a dále přes krajský konektor do CMS.

Sdílené aplikační, technologické a síťové služby ORP

Malé obce, typicky všechny obce prvního a druhého typu, provozující méně než 10 přístupových zařízení, jsou zproštěny povinnosti zajišťovat informatizaci svých služeb veřejné správy a svůj podíl na eGovernmentu vlastními silami.

Pravidla pro Sdílené provozní informační systémy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci sdílených provozních IS je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu ke sdíleným provozním IS popíše úřad do své informační koncepce.

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Pravidla pro Sdílené statistické, analytické a výkaznické systémy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci Sdílených statistických, analytických a výkaznických systémů je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu ke sdíleným statistickým, analytickým a výkaznickým systémům popíše úřad do své informační koncepce.

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Pravidla pro eGovernment cloud

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci eGovernment Cloudu je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k eGovernment Cloudu popíše úřad do své informační koncepce.

Rozhodnutí o vstupu do eGC

Jedním ze dvou hlavních kritérií pro využití služeb Státní část eGovernment Cloudu (také jako SeGC) nebo Komerční část eGovernment cloudu (také jako KeGC) je úroveň bezpečnostních dopadů daného IS. SeGC zajistí maximální úroveň bezpečnosti a je určen pro provoz služeb eGC bezpečnostní úrovně 4 (Kritická). KeGC je určen pro provoz služeb eGC bezpečnostních úrovní 1-3 (Nízká, Střední, Vysoká) a v maximální míře umožňuje využití tržních mechanismů pro zajištění optimálních cen. 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. K oběma způsobům stanovení bezpečnosti a ekonomické náročnosti vznikly metodické pomůcky dostupné na:

Správce eGC zveřejní dynamický nákupní systém (také jako DNS) pro nákup eGC služeb vedených v jeho katalogu. Portál pro objednávání a správu služeb nebude spuštěn spolu s DNS, ale jeho spuštění se dá očekávat v první polovině roku 2020.

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í.

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 infrastrukturu od samotné technologické 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.

V následující fázi budování eGC, dlouhé zhruba dva roky, bude umísťování IS do eGC (využívání služeb eGC) dobrovolné. Dlouhodobě bude uplatněn princip cloud-first – povinné umístění IS do eGC, pokud kalkulace TCO neprokáže nákladově efektivnější provoz onpremise.

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

Konkrétní povinnosti stanoví Řídící orgán eGovernment Cloudu. 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

Pravidla pro Národní datová centra

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci národních datových center je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu k národním datovým centrům popíše úřad do své informační koncepce.

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Pravidla pro komunikační infrastrukturu veřejné správy

Popis architektury úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu je popsán v části Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury.

Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí v rámci komunikační infrastruktury veřejné správy je popsán na samostatné stránce zde nebo v rámci části Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR.

Využití a popis k přístupu ke komunikační infrastruktuře veřejné správy popíše úřad do své informační koncepce.

Zákon 365/2000 sb. v aktuálním znění, zavedl povinnost publikovat služby ISVS jednotlivým uživatelům prostřednictvím Centrálního místa služeb (také jako CMS). V kombinaci s komunikační infrastrukturou veřejné správy (také jako KIVS) zavádí pro jednotlivé orgány veřejné správy bezpečnou, od internetu oddělenou, komunikační infrastrukturu poskytující pro jednotlivé orgány veřejné správy:

  • Bezpečný a spolehlivý přístup k aplikačním službám jednotlivých ISVS
  • Bezpečnou a spolehlivou publikaci aplikačních služeb jednotlivých ISVS
  • Bezpečný přístup do internetu
  • Bezpečný přístup k poštovním službám v internetu
  • Zabezpečuje bezpečné síťové prostředí pro zajištění interoperability v rámci EU
  • Umožňuje bezpečný přístup k aplikačním službám ISVS určeným pro koncové klienty VS ze sítě internet

Cílem je:

  • Publikovat bezpečným způsobem přes CMS/KIVS všechny aplikační služby centralizovaných ISVS se současným zajištěním bezpečného přístupu jednotlivých OVS k těmto službám při výkonu jejich působnosti.
  • Umožnit bezpečný přístup k aplikačním službám ISVS určeným pro koncové klienty VS ze sítě internet
  • Zabezpečit bezpečné síťové prostředí pro zajištění interoperability v rámci EU

Centrální místo služeb, jakožto součást komunikační infrastruktury veřejné správy, je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů státní správy ke službám (aplikacím), které poskytují informační systémy jiných subjektů státní správy s definovanou bezpečností a SLA parametry, tj. přístup ke službám eGovernmentu.

CMS tak můžeme nazvat privátní sítí pro výkon veřejné správy na území státu.

Připojení k CMS

CMS jako privátní síť veřejné správy využívá dedikovaných resp. pronajatých síťových prostředků pro bezpečné propojení úředníků orgánů veřejné správy (OVS) pracujících v agendách veřejné správy s jejich vzdálenými agendovými informačními systémy, pro bezpečné síťové propojení agendových systémů navzájem a pro bezpečný přístup jednotlivých OVS do Internetu.

Připojení k CMS je možné realizovat prostřednictvím:

  1. Neveřejného KIVS operátora (Krajské sítě, Metropolitní sítě, ITS Ministerstva vnitra a další)
  2. Veřejného KIVS operátora (Soutěž KIVS operátora přes centrálního zadavatele MVČR)
  3. IPsec VPN
  4. SSL VPN

Pro OVS jsou přípustné pouze první 2 varianty - Neveřejný a veřejný KIVS operátor, komunikace mezi jednotlivými OVS je tak vedena výhradně prostřednictvím KIVS/CMS, tzn. jednotlivé OVS mají povinnost přistupovat k informačním systémům veřejné správy (ISVS) pouze prostřednictvím KIVS/CMS.

IPsec a jeho úskalí

Ačkoliv jsou pro OVS přípustná jen připojení pomocí KIVS, existují úřady využívající připojení IPsec, který se ovšem nehodí pro kritické služby a funkce úřadování. Nevhodné je toto připojení např. pro systém CDBP (systém sběru žádostí o vydání občanského průkazu nebo cestovního dokladu občana České republiky), kdy mohou nastat následující rizika:

  1. Spojení realizovaná prostřednictvím kryptografických prostředků přes veřejný internet nejsou vhodná jako primární způsob čerpání služeb, které mají mít garantovanou funkčnost a dostupnost. Systém CDBP je koncepčně založen na předpokladu provozu na vyhrazené síti, která je zcela oddělena od běžného internetového provozu a tomu odpovídá i úroveň jeho zabezpečení.
  2. V rámci spojení realizovaných prostřednictvím veřejného internetu není možné dostatečným způsobem garantovat následující:
    • požadavek na dostupnost, protože internet není zaručeně garantované přenosové prostředí s definovanými SLA,
    • požadavek na propustnost, protože systém CDBP využívá na ORP "těžkého" klienta se vzdálenou správou; nezbytná je tedy komunikace oběma směry (centrum systému CDBP – ORP a ORP – centrum systému CDBP) pro instalací nových verzí aplikace pomocí "balíčků" o velikosti cca 500 MB/PC a pro stahováním logů z PC o velikosti cca 100 MB/PC,
    • požadavek na fungování protokolu WoL, který umožňuje dálkové „probouzení“ jednotlivých pracovních stanic systému CDBP bez zásahu obsluhy, je nezbytný z důvodů distribuce nových verzí SW, stahování logů či jiných činností souvisejících s provozem Systému CDBP.
  3. Na základě výše uvedeného reálně hrozí, v případě využití IPsec, riziko výpadků spojení při pořizování žádostí o občanské průkazy a cestovní pasy, což může vést ke zpomalení nebo úplné nedostupnosti pracovišť systému CDBP. V případě, že by v důsledku užívání IPsec, nebylo možné dálkově nainstalovat na koncová pracoviště systému CDBP aktualizace, bude nezbytné, aby instalaci provedl technik při výjezdu, který by úřad musel uhradit.

CMS, popis zahrnutých služeb

Odbor Hlavního architekta eGovernmentu a Ministerstvo vnitra v rámci svých kompetencí požaduje od jednotlivých správců ISVS, aby služby ISVS publikovaly v rámci Centrálního místa služeb – CMS (služba CMS2 -02, CMS2 -04).

Jednotliví uživatelé ISVS na úrovní státní správy a samosprávy služby těchto systémů konzumují, resp. k ISVS přistupují výhradně prostřednictvím CMS (služba CMS2 -03).

Služba CMS2 – 02 – Zveřejnění aplikace

Název parametru Vysvětlení
Kód služby CMS2-02
Název služby Zveřejnění aplikace
Popis služby Služba vytvoří prostředí pro publikaci aplikační služby informačního systému OVM. Varianty služby se liší podle cílového prostředí. Možné varianty jsou: 1. do sítě Internet 2. do sítě CMS 3. do sítě TESTA-ng 4. do Extranetu

Aplikační služba může být umístěna v infrastruktuře orgánu nebo v infrastruktuře Národního datového centra (NDC). Aplikační služba může být zveřejněna do více prostředí současně. Aplikační služba je zveřejněna na definovaných protokolech a portech.

Při zveřejnění aplikace do sítě Internet jsou aplikaci přiděleny veřejné IP adresy z prostoru CMS. Přístup ke zveřejněné službě může být omezen na definované zdrojové IP adresy.

Při zveřejnění aplikace do sítě CMS jsou aplikaci přiděleny privátní IP adresy z prostoru CMS (Konsolidované IP adresy). Službu je možné zveřejnit pro všechny ostatní subjekty připojené do sítě CMS (Veřejná služba) nebo pro definované subjekty a skupiny subjektů (Schvalovaná služba). O přístup ke Schvalované službě musí přistupující subjekty žádat prostřednictvím služby CMS203-1.

Při zveřejnění aplikace do sítě TESTA-ng (síť EU) jsou aplikaci přiděleny IP adresy z prostoru pro ČR v síti TESTA-ng. Přístup ke zveřejněné službě je omezen na definované zdrojové IP adresy. Zveřejnění aplikace musí být provozováno v souladu s provozními a bezpečnostními požadavky EU pro síť TESTA-ng.

Při zveřejnění aplikace do Extranetu jsou aplikaci přiděleny privátní IP adresy z prostoru CMS (Konsolidované IP adresy). Aplikační služba je zveřejněna do existujícího extranetu (extranet vytváří Správce CMS). Přístup k aplikaci v extranetu je umožněn všem uživatelům, kteří mají do daného extranetu přístup.

Služba CMS2 – 03 – Přístup k aplikaci

Název parametru Vysvětlení
Kód služby CMS2-03
Název služby Přístup k aplikaci
Popis služby Služba umožňuje zřizovat a rušit přístupy k aplikačním službám. Varianty služby se liší podle cílového prostředí. Možné varianty představují přístup: 1. k aplikaci v síti CMS 2. k aplikaci v síti TESTA-ng 3. k aplikaci v síti Internet

Služba umožňuje zřizovat, měnit a rušit přístupy subjektu k nabízené aplikační službě. Jednou žádostí lze zřídit přístup právě k jedné aplikační službě. Připojení je povoleno z definovaných IP adres v síti subjektu.

Přístup k aplikaci v síti CMS umožní subjektu připojení k aplikační službě zveřejněné jiným subjektem prostřednictvím služby CMS2-02-2 v síti CMS. Zřízení přístupu je podmíněno souhlasem vlastníka zveřejněné aplikační služby, které probíhá prostřednictvím portálu CMS.

Přístup k aplikaci v síti TESTA-ng umožní subjektu připojení k aplikační službě zveřejněné jiným státem Evropské unie v síti TESTA-ng. Připojení je povoleno na definovaných protokolech a portech. Přístup k aplikaci musí být provozován v souladu s provozními a bezpečnostními požadavky EU pro síť TESTA-ng.

Přístup k aplikaci v síti Internet umožní subjektu připojení k aplikační službě zveřejněné v síti Internet na definovaných protokolech a portech. Cílovou aplikační službu v síti Internet je nutné definovat konkrétními IP adresami, protokoly a porty.

Služba CMS2 – 04 – Publikace AIS na eGSB/ISSS

Název parametru Vysvětlení
Kód služby CMS2-04
Název služby Publikace AIS na eGSB/ISSS
Popis služby Služba zajišťuje zpřístupnění publikačního agendového informačního systému (AIS) v rámci CMS a povolení síťové komunikace s rozhraním eGon Service Bus / Informační systém sdílené služby

Služba zajistí provozovateli publikačního agendového informačního systému (AIS) síťovou konektivitu mezi eGSB/ISSS (eGON Service Bus / Informační systém sdílené služby, tj. sdílená služba obecného rozhraní) a publikačním AIS na definovaných protokolech a portech. V rámci publikace jsou přiděleny privátní IP adresy z prostoru CMS (Konsolidované IP adresy).

Ve výchozím stavu je komunikace mezi eGSB/ISSS a publikačním AIS synchronní, volitelně lze zprovoznit komunikaci asynchronní.

Právní aspekty

S výjimkou tzv. provozních informačních systémů, které jsou uvedeny v § 1 odst. 4 písm. a) až d) zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), je § 6g odst. 3 tohoto zákona správcům ISVS uložena povinnost poskytovat služby informačních systémů veřejné správy prostřednictvím CMS. Organům veřejné správy je prostřednictvím § 6g odst. 4 ZoISVS uložena povinnost využívat sítě elektronických komunikací CMS.¨

Protože skrze CMS se publikují služby tzv. referenčního rozhraní, definovaného v § 2 písm. j) ZoISVS, má vztah k CMS i povinnost uložená v § 5 odst. písm. d) ZoISVS, tj. povinnost správců ISVS zajistit, aby vazby jimi spravovaného ISVS na ISVS jiného správce byly uskutečňovány prostřednictvím CMS.

S ohledem na výše popsané vlastnosti CMS, jakož i s ohledem na výše popsané právní aspekty, lze také dodat, že využívání, popř. nevyužívání CMS je relevantním faktorem pro posuzování plnění souvisejících právních povinností, a to zejména povinností v oblasti kybernetické bezpečnosti nebo ochrany osobních údajů, jakož i povinnosti řádného a hospodárného nakládání s veřejnými finančními prostředky a povinnosti k předcházení vzniku škod.

Modely Národního architektonického plánu

Název souboru Popis souboru Typ souboru Odkaz na soubor
Povinné architektonické vzory Povinné architektonické vzory ArchiMate odkaz
Povinné architektonické vzory Povinné architektonické vzoryXMLodkaz
Agendový informační portálAgendový informační portálArchiMateodkaz
Agendový informační portálAgendový informační portálXMLodkaz
DCeGOVDCeGOVArchiMateodkaz
DCeGOVDCeGOVXMLodkaz
MetodikaMetodikaArchiMateodkaz
MetodikaMetodikaXMLodkaz
CMS publikace služebCMS publikace služebArchiMateodkaz
CMS publikace služebCMS publikace služebXMLodkaz
Přehled prvků ArchiMate pro VSPřehled prvků ArchiMate pro VSArchiMateodkaz
Přehled prvků ArchiMate pro VSPřehled prvků ArchiMate pro VSXMLodkaz
Veřejný pseudonymVeřejný pseudonymArchiMateodkaz
Veřejný pseudonymVeřejný pseudonymXMLodkaz
Agenda A121 - živnostenský rejstříkAgenda A121 - živnostenský rejstříkArchiMateodkaz
Agenda A121 - živnostenský rejstříkAgenda A121 - živnostenský rejstříkXMLodkaz
Referenční modely byznys architekturyReferenční modely byznys architekturyArchiMateodkaz
Referenční modely byznys architekturyReferenční modely byznys architekturyXMLodkaz
Referenční modely aplikační architekturyReferenční modely aplikační architekturyArchiMateodkaz
Referenční modely aplikační architekturyReferenční modely aplikační architekturyXMLodkaz

Centrální úložiště modelů

NAP v současné verzi nemá k této problematice návody, rady, postupy či závazná nařízení. Bude řešeno v dalších verzích.

Pravidla pro lokální úložiště modelů a modelovací nástroje

NAP v současné verzi nemá k této problematice návody, rady, postupy či závazná nařízení. Bude řešeno v dalších verzích.

Vzájemná výměna modelů

Vzájemnou výměnu modelů musí úřad zajistit souladem svého architektonického nástroje se standardem The Open Group ArchiMate model exchange file format. Tento formát bude vyžadován jako povinný ve všech částech NAP či IKČR.

Výpis podstatných prvků architektury eGovernmentu

Následující tabulka slouží pouze jako příklad budoucího zveřejnění prvků s jedinečným centrálním GUID, který bude pro tyto prvky povinný ve všech modelech architektur jednotlivých úřadů.

Název prvku Popis Typ prvku GUID
Centrála CzechPOINT Centrální systém obsluhující všechny služby CzechPOINT Aplikační komponenta 123
CzechPOINT@office Rozhraní určené pro úředníky zprostředkující předem definované služby Aplikační rozhraní 456
CzechPOINT Rozhraní určené pro asistované služby veřejné správy. Je využíváno asistentem na žádost klienta Aplikační rozhraní 789
eSSL Systém elektronické spisové služby Aplikační komponenta 123
Správa dokumentů Funkce, kterou vykováná původce Byznys funkce 456
Určený původce Osoba, která je zákonem povinná a zodpovídá ze správu dokumentů ve spisové službě Aktér 789
1)
dle platného a účinného znění zákona č. 111/2009 Sb., jsou v ROB stále jen elektronicky čitelné identifikační doklady. Změna by měla nastat se sněmovním tiskem 756
Pokud byste byli zalogování, mohli byste zanechat komentář.