- Česky (cs)
- English (en)
NAP: Celky podle vrstev a využití
Základní principy (byznysová vrstva)
Systémy a služby spojené s právním řádem a legislativou
Popis Systémů a služeb spojených s právním řádem a legislativou
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 vnitra | Elektronická 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ů |
eLegislativa | Ministerstvo vnitra | Informač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 vnitra | V 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ách | Slouží 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.
Pravidla Systémů a služeb spojených s právním řádem a legislativou
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 architektury se očekávají následující změny na centrální i lokální úrovni
- Po uvedení systému e-Sbírka do ostrého provozu (předpoklad k 1. 1. 2022) přehodnotí úřady politiku pořizování komerčních právních informačních systémů, zejména objem a rozsah potřebných licencí pro výkon své působnosti s přihlédnutím k individuální povaze pracovní činnosti konkrétních zaměstnanců, kteří vyžívají tyto systémy ke své práci. Případný poptávaný rozsah licencí komerčních právních informačních systémů pak při přihlédnutí k smluvním podmínkám dodávek kontrahovaných v této oblasti a potřebám konkrétních pracovníků následně omezí na uspokojení pouze těch potřeb podmiňujících výkon své působnosti, které nelze využitím systému e-Sbírka pokrýt.
- Informační systém eSbírka a eLegislativa a ODoK musí být funkčně propojeny tak, aby byly naplněny předpoklady fungování elektronického legislativního procesu podle zákona č. 222/2016 Sb., o Sbírce zákonů a mezinárodních smluv a o tvorbě právních předpisů vyhlašovaných ve Sbírce zákonů a mezinárodních smluv (zákon o Sbírce zákonů a mezinárodních smluv), ve znění pozdějších předpisů.
- Od okamžiku spuštění informačního systému e-Sbírka a e-Legislativa budou všechny úřady povinny ve svých systémech a nově vytvářených materiálech obohacovat právní citace právních předpisů obsažených v e-Sbírce typu "§1 zákona č. 100/2000 Sb." technicky o odkazy do systému e-Sbírka, které budou vytvářet pomocí funkcionality pro tvorbu citací obsažené v e-Sbírce.
systemy_sluzby_spojene_pravnim_radem_legislativou
Agendový model veřejné správy
Popis Agendového modelu veřejné správy
Agendový model je základem byznys architektury veřejné správy a základem řízení výkonu digitálních služeb veřejné správy. Všechny agendy veřejné správy jsou zapsány spolu s legislativním ukotvením v Registru práv a povinností včetně definice OVM v agendách působících. V souladu s touto registrací pak OVM musejí vykonávat svoje činnosti a poskytovat svoje služby. Registr práv a povinností dále definuje údaje v agendách vedené a pravidla pro jejich využívání jinými agendami resp. agendovými informačními systémy tyto agendy podporujícími.
Agendový model výkonu veřejné správy
Základ agendového modelu výkonu veřejné správy byl vytvořen při implementaci základních registrů ve veřejné správě. Agendový model definuje působnost a činnosti OVS v jednotlivých agendách – souhrn všech činností ve všech agendách, ve kterých OVS působí, definuje působnost OVS. Orgány veřejné správy mají veškeré své veřejnoprávní činnosti definovány popsáním působnosti v jednotlivých agendách.
Agendy veřejné správy
Agendy veřejné správy jsou nejen právní rámce pro fungování orgánů veřejné moci, ale i základní rámce pro realizaci procesů jako činností a pro evidenci a spravování a využívání údajů v rámci principu propojeného datového fondu.
Existuje následující obecný rozpad toho, co je evidováno k agendě v RPP a co to obecně znamená:
Agenda je soubor činností definovaných zákonem, či zákony (příklad je agenda občanských průkazů, státní sociální podpory, evidence řidičů apod.)
- 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:
- 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.
- 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.
- 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.
- 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).
- 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ů.
- 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.
- Údaje v agendě: Jsou ohlášeny všechny propojované a vedené údaje, včetně jejich kontextů a včetně technických údajů o nich.
- Úkony na žádost: Součástí agendy je i seznam a forma úkonů na žádost a určení toho, kdo smí takovou žádost podat
- Formuláře: součástí povinností ohlášení agendy je i předání elektronických formulářů či odkazů na ně ministerstvu vnitra.
Klíčové role OVS v agendovém modelu
Existují následující klíčové role, o kterých se hovoří i jinde v rámci architektonických dokumentů:
Klíčové role OVS v agendovém modelu veřejné správy | Role | Popis/význam hlavní činnosti |
---|---|---|
Ohlašovatel agendy | OVM, který je zodpovědný za legislativní rámec agendy, a tedy určuje i základní parametry jejího výkonu | Je gestorem právních předpisů; koordinuje výkon agendy; metodicky řídí výkon agendy; ohlašuje agendu v RPP a její podrobnosti; stanovuje působnost OVM; poskytuje buď centralizovaný AIS, nebo podmínky a standardy pro decentralizované řešení; ohlašuje a spravuje údaje v RPP, včetně údajů v rejstřících OVM a SPUU; v případě centralizovaného AIS poskytuje údaje přes referenční rozhraní ISVS |
Orgán veřejné moci působící v agendě | OVM, který působí v dané agendě. To znamená, že vykonává fakticky nějakou činnost v rámci dané agendy a k tomu využívá buď centrálně poskytnutý AIS, nebo svůj vlastní | Přihlašuje se k působnosti; vykonává jemu svěřené činnosti úředníky v jejich činnostních rolích; zapisuje do RPP údaje o své působnosti; využívá centralizovaný AIS nebo spravuje vlastní; eviduje a spravuje údaje v agendě; vykonává případně funkce editora údajů |
Soukromoprávní uživatel údajů | Subjekt, který má na základě zákona oprávnění k přístupu k údajům v základních registrech či AISech a přistupuje k nim prostřednictvím AIS spravovaného k tomu určeným OVM | Využívá údaje podle oprávnění |
Správce centralizovaného AIS pro výkon agendy | OVM, který na základě zákona spravuje centralizovaný AIS a poskytuje ho OVM působícím v agendě | Spravuje centralizovaný AIS; zpřístupňuje AIS uživatelům působících OVM; realizuje využívání referenčních údajů ze základních registrů do centralizovaného AIS; poskytuje podporu uživatelům; řeší integrační vazby AIS na další systémy |
Správce vlastního AIS, pokud není k dispozici centralizovaný AIS | Jednotlivé OVM, které pro podporu agendy využívají svůj vlastní agendový IS, protože není k dispozici sdílené centralizované řešení | Spravuje svůj vlastní AIS; zapisuje údaje o svém AIS do RPP; řeší vazby na základní registry; řeší vazby na další ISVS; řeší vazby na další svoje informační systémy; spravuje a udržuje datový fond ve svém AISu |
Orgán veřejné moci spravující AIS pro přístup soukromoprávních uživatelů | OVM, který na základě zákona vytváří a provozuje AIS, jehož prostřednictvím mohou soukromoprávní uživatelé přistupovat k údajům ze základních registrů či jiných AISů | Spravuje AIS pro SPÚ; zpřístupňuje funkce AISu soukromoprávním uživatelům; realizuje dohled nad oprávněním k využívání údajů; poskytuje soukromoprávním uživatelům údaje; zajišťuje realizaci reklamací údajů od SPÚ k editorům údajů |
Pohled na ohlašovatele a vykonavatele agendy
Pravidla Agendového modelu veřejné správy
Základní povinnosti ohlašovatele agendy
Ohlašovatel agendy je podle zákona č. 111/2009 Sb., o základních registrech zodpovědný za řádné ohlášení agendy a za aktualizace agendy, a především za správnost a pravdivost údajů uvedených v agendě. Zjistí-li kdokoliv nesoulad reality s údaji, měl by to jako u dalších referenčních údajů ohlásit ohlašovateli, a ten musí agendu upravit do souladu se skutečností. To se netýká jen základních informací, ale i všech dalších referenčních a nereferenčních údajů, jako jsou činnosti, působnosti OVM, údaje v agendě, agendové informační systémy apod.
Základními povinnostmi ohlašovatele jsou:
- Tam, kde je gestorem legislativy, dodržovat veškeré principy pro legislativu, včetně zásad Digitálně přívětivé legislativy
- Ohlásit agendu
- Ohlásit každou její změnu
- Ohlásit působnost všech OVM a definovat výkon jim svěřených činností
- Zajistit využívání údajů ze základních registrů a související oprávnění pro jejich využívání pro podporu výkonu agendy
- Ohlásit agendové informační systémy, které spravuje a které jsou poskytovány OVM působícím v agendě
- Ohlásit údaje v agendě vedených, čerpaných i poskytovaných
- K centralizovaným agendovým informační systémům vydávat provozní řád
- Metodicky řídit výkon agendy u OVM, který v agendě působí
- Spravovat, tzn. ohlašovat a udržovat aktuální, údaje v rejstříku OVM/SPUU. U SPUU se jedná o všechny subjekty, které jsou povinné dle právních předpisů spadající do agendy, jejichž je OVM ohlašovatel. Ohlašovat může ustanovit jiné OVM, které bude tyto úkony činit.
Základní povinnosti OVM působícího v agendě
V rámci agendy veřejné správy mohou veřejnoprávní činnosti vykonávat pouze ty orgány veřejné moci, které jsou v rámci ohlášení agendy vyznačeny jako orgány veřejné moci vykonávající působnost, a to v rámci konkrétních činností. To znamená, že po aplikaci principu referenčních údajů v Registru práv a povinností lze konstatovat, že pokud v rámci dané agendy vykonává veřejnoprávní činnost orgán veřejné moci, který nemá vyznačenou působnost, jedná se o porušení zákona a ohlašovatel agendy musí neprodleně toto napravit. To se týká nejen samotného seznamu působících orgánů veřejné moci, ale také přiřazení jejich činností. Výkon činnosti je byznysovou vazbou a odborně jej nazýváme "činnostní rolí".
Základními povinnostmi orgánů veřejné moci působících v agendě tedy jsou:
- Vykonávat činnosti dle ohlášení agendy
- Pokud OVM zjistí nesoulad skutečnosti a údajů v ohlášení agendy, je povinen požadovat po ohlašovateli nápravu.
- Pokud sám spravuje agendový informační systém pro výkon agendy (není poskytován centrálně), ohlásit tento systém do RPP jako ISVS.
- Pokud existuje centralizovaný agendový informační systém, tak tento využívat.
- Přistupovat k údajům v základních registrech a dalších ISVS výhradně na základě oprávnění ohlášeného v agendě.
- Spravovat jen ty údaje, které jsou ohlášeny v dané agendě.
- Pokud zjistí nesoulad referenčních údajů v jednotlivých základních registrech se skutečností, zahájit proces reklamace u příslušného editora.
Propojený datový fond
Popis propojeného datového fondu
Zde uvedené informace k propojenému datovému fondu (PPDF) a všech jeho dílčích oblastí (ISZR, eGSB/ISSS, atd.) vycházejí z Globální architektury propojeného datového fondu, který je přílohou samotného NAP v rozšiřující znalostní bázi.
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
- Podpora reklamace chybných údajů
Pohled na propojený datový fond
Pravidla propojeného datového fondu
Ú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í uživatel údajů (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ů či jiných AIS. Může tak činit přímo prostřednictvím svého soukromoprávního systému pro využívání údajů (také jako SSVU) za splnění zákonných povinností, nebo přes agendový informační systém orgánu veřejné moci, který slouží pro výkon stejné agendy a jsou zajištěny všechny zákonné požadavky. Poslední možností pro SPUU je využívat formuláře Czech POINT. V zákoně č. 111/2009 Sb. - Zákon o základních registrech, je 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.
- Informace ohledně ZR jsou k dispozici na stránkách: https://www.szrcr.cz/cs/sluzby/spravci-a-vyvojari
- Informace, jakým způsobem připojit svůj AIS nebo komunikační sběrnici do ISZR jsou k dispozici na stránkách: https://pruvodcepripojenim.gov.cz/
- Informace, jakým způsobem využívat notifikace ze ZR je k dispozici na stránkách: https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/Spra%CC%81vny%CC%81_postup_pra%CC%81ce_s_notifikacemi_a_udrz%CC%8Covani_datoveho_kmene_nava%CC%81zane%CC%81ho_na_ROB_4.2023.pdf
- Informace k připojování ke kompozitním službám AISEO a AISC: https://www.szrcr.cz/cs/sluzby/spravci-a-vyvojari/kompozitn%C3%AD-slu%C5%BEby-aiseo,-aiseop,-aiscd-a-aisc#Manual
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.
Úplné elektronické podání
Popis úplného elektronického podání
Úplné elektronické podání (také jako "ÚEP") je možné popsat tak, že klient/občan, ale i zástupce právnické osoby, má možnost vyřídit všechnu svou potřebnou agendu životní situace, prostřednictvím elektronické interakce samoobslužně kdykoli a odkudkoli či asistovaně z kteréhokoli univerzálního kontaktního místa VS, bez nutnosti osobní návštěvy na příslušných úřadech, a následně možnost mít přehled o stavu a vývoji všech svých řešených životních událostí.
Současně pojem ÚEP představuje pokročilou variantu elektronického podání (elektronické formy úkonu klienta, občana a/nebo organizace vůči veřejné správě ČR), která splňuje sadu požadovaných vlastností, daných primárně tzv. architektonickými principy eGovernmentu a dále vlastnosti předpokládané pro podání vůči veřejné správě právními předpisy, zejm. správním řádem a agendovými zákony.
Elektronické podání klienta vůči veřejné správě je považováno za úplné, pokud splňuje všechny architektonické principy eGovernmentu a další náležitosti, zejména pak:
- Podporuje princip Digital by Default tím, že je navrženo jako vnitřně plně digitální (nikdy se nemusí tisknout nebo osobně řešit), s tím, že ale podporuje asistovanými formami i tzv. elektronicky handicapované.
- Podporuje princip Whole-of-Government tím, že je dostupné rovnocenným způsobem ve všech elektronických kanálech eGovernmentu (samoobslužných i asistovaných), s upřednostněním univerzálních kontaktních míst (CzechPOINT a PO v PVS).
- Podporuje princip Once only tím, že pro předvyplnění formuláře i pro navigaci a volbu služby jsou využity všechny údaje o klientovi, které veřejná správa má a ze zákona je v dané situaci smí použít.
- Podporuje principy Interoperability by Default a Cross-border by default tím, že umožňuje elektronicky obsloužit všechny klienty, rezidenty ČR a EU, pro které je úkon relevantní, a to i vzdáleně ze zahraničí.
- je po podání automatizovaně strojově zpracováno, převedeno do transakčního záznamu agendového informačního systému.
- Podporuje princip Inclusion and Accessibility tím, že podporuje asistovanými formami i tzv. elektronicky (nebo jinak) handicapované.
- Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.
Všechny obslužné kanály veřejné správy musí být cílově vzájemně integrovány tak, aby mezi nimi bylo možno libovolně přecházet i v průběhu vyřizování podání a aby všechny informace byly zachovány, přenášely se do nich (mezi nimi).
Pravidla úplného elektronického podání
Úřad musí respektovat všechny návazné funkční celky jako např. propojený datový fond, portály veřejné správy či komunikační infrastrukturu veřejné správy a procesně zajistit zpracování podání tak, aby probíhalo elektronicky po celou dobu jeho životního cyklu.
Úřad pro splnění požadavků kladených na úplné elektronické podání musí splnit svými obslužnými kanály (např. portál):
- Využití Jednotného identitního prostor veřejné správy pro úřední osoby a Elektronickou identifikaci pro klienty veřejné správy.
- Předvyplnění podání všemi státu známými údaji klientovi po prokázání elektronickou identitou. Zajištění tohoto požadavku se splní čerpáním údajů z Propojeného datového fondu.
- Má služby svých agend v rámci ÚEP a jejich IT aplikace navrženy tak, aby služby bylo možno v obslužných kanálech kombinovat pro efektivním řešení životních událostí.
- Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.
- Postupně všechna existující práva a povinnosti ze vztahu k VS budou doprovázena transakční službou (nejenom popisem návodu) v Portálu občana, a to v těch všech případech, kdy elektronická transakční služba bude proveditelná a bude odpovídat oprávněným zájmům klientů a současně i úřadů.
- Elektronické podání formou ÚEP lze uskutečnit i papírově (off-line), tzn. půjde stáhnout předvyplněný formulář, ručně vyplnit, zaslat datovou schránkou nebo elektronicky podepsané doručit jakkoli jinak (i mailem, vložením do portálu), případně vložit do elektronické aplikace úřadu.
- V případě menší četnosti podání stačí jeden z obou kanálů (on-line nebo off-line), musí však umožňovat dobrou (personalizovanou) navigaci ke službě a k jejímu předvyplnění.
- Stejnou službu lze získat s pomocí služby úředníka na kterémkoli fyzickém kontaktním místě asistovanou formou. Pro typové a jednoduché podání pro řešení typových životních situací to takto bude možné na Univerzálních asistovaných kontaktních místech.
- Zůstanou zachovány tradiční kanály pro příjem listinných podání osobně, diktátem do protokolu nebo poštou – úřední přepážky a podatelny. Jejich úkolem ale bude obdržené vstupy neprodleně plně digitalizovat, aby celé další následné zpracování bylo jednotně plně elektronické.
- Nedílnou součástí řady podání je splnění finanční povinnosti (poplatku, daně). Platební brána tedy musí být součástí obslužného rozhraní. Pro agendy v samostatné působnosti je platební brána plně v zodpovědnosti koncového úřadu, pro agendy v přenesené působnosti musí o způsobu rozhodnout správce agendy.
- Elektronické samoobslužné služby pro klienty/občany i pro právnické osoby musí být doplněny interaktivním podpůrným a poradenským kanálem (service-desk, call-me-back, apod.).
- Podání nemusí vždy činit ta osoba, která je přihlášena elektronickou identitou, ale může se jednat o osobu zastupující jinou osobu. Úřad tedy musí zajisti správu mandátů.
- Pro individuální přizpůsobení uživatelského rozhraní musí úřad využívat tzv. klientské profily. Každý jedinečný a jednoznačně identifikovaný klient má profil jenom jeden. V tomto profilu jsou uchovávány osobní i agendové údaje ve shodě se pravidly správy údajů Právní aspekty pro pseudonymizaci.
- Podání zadané či zpracované v rámci řešení pro ÚeP musí být vždy přijímáno na podatelně a evidováno v systému eSSL nebo samostatné evidenci dokumentů v souladu se zákonem o archivnictví a spisové službě. Jejich přijetí musí být potvrzeno příslušnou odpovědní zprávou.
Elektronické úkony a doručování
Popis Informačního systému datových schránek
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.
Pravidla Informačního systému datových schránek
Úř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.
Univerzální kontaktní místo veřejné správy
Popis Univerzálního kontaktního místa
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 a Digitální a informační agentura provozuje 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
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 služba specializovaná, nemělo by to bránit v zavedení její samoobslužné varianty v univerzálním kontaktním místě.
Pravidla pro Univerzální kontaktní místo
Úř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:
- Poskytování samoobslužných služeb pro klienta pod zaručenou elektronickou identitou
- Všechny publikované samoobslužné služby jednotlivých úřadů musí mít možnost pracovat s klientem, který se prokazuje svoji zaručenou elektronickou identitou. Technicky to znamená soulad s pravidly a principy Národního identitního prostoru
- Federace pod Portál občana
- Služby musí být federovány pod Portál občana / Portál veřejné správy v souladu s Národním identitním prostorem a plnit pravidla portálů veřejné správy a soukromoprávních uživatelů údajů
- Interaktivní uživatelské rozhraní
- Formuláře a další služby pro klienta veřejné správy používající zaručenou elektronickou identitu a principy úplného elektronického podání.
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 podání nároku v insolvenčním řízení). V Czech POINT mají být především takové služby, u kterých:
- převažuje listinný vstup nebo výstup či vidimace listin a legalizace podpisu (mělo by se minimalizovat na nejnižší možnou míru),
- je skutečně nezbytná prezenční kontrola identity,
- je účelný přesun výkonu služby co nejblíže klientovi a existuje poptávka po asistované podobě takové služby.
- Je vhodné, aby kompletní odbavení klienta na KMVS pro daný úkon nepřekročilo deset minut.“
Při využívání systému CzechPOINT jako asistovaného univerzálního kontaktního místa je zakázáno požadovat a udržovat editační (zapisovací) formuláře pro informační systémy veřejné správy, které poskytují své služby pomocí tenkého klienta. Není tedy možné například požadovat editační formulář v systému CzechPOINT pro systém řidičských oprávnění, protože systém řidičských oprávnění poskytuje své vlastní rozhraní dostupné ve formě tenkého klienta.
Systém správy dokumentů
Popis Systému správy dokumentů
Obecně o správě dokumentů
Od 1.7.2024 vyšla v platnost novela zákona č. 499/2004 Sb., která výrazně změnila práva a povinnosti určených původců. Důležité změny jsou obsaženy zejména v § 3a a § 69a.
V § 3a se stanovuje regulatorní minimum pro správu informací v informačních systémech odlišných od elektronických systémů spisové služby. Správce těchto systémů musí zajistit naplnění pravidel podle § 3 odst. 5 a pro výběr archiválií mimo skartační řízení (zde s výjimkou informací, na něž byl vydán trvalý skartační souhlas). Zároveň se však dává jasně najevo, že systémy, jichž se ustanovení týkají, nepodléhají pravidlům vztahujícím se na elektronické systémy spisových služeb. Logicky tedy nepodléhají ani atestacím. Postupy, výstupní datové formáty a rozsah a podobu metadat pro účely výběru archiválií podle navrhovaného §3a odst. 1 pak stanoví Národní archiv a zveřejní je na svých internetových stránkách. Tímto ustanovením se zajistí flexibilita pro Národní archiv, kdy s ohledem nejen na vývoj informačních technologií, ale i poznatků z praxe bude Národní archiv mít možnost zajištovat efektivní výběr archiválií s minimalizací požadavků na dotčené informační systémy. Změna též zavádí významnou úsporu v oblasti rozvoje e-governmentu, neboť u informačních systémů, kde bude pro všechny jimi spravované informace vystaven trvalý skartační souhlas, nebude vůbec nutná implementace řešení pro výběr archiválií.
Pokud existují, resp. budou existovat informační systémy, které nejsou elektronickými systémy spisové služby a na základě toho se na ně nebudou vztahovat požadavky stanovené zákonem č. 499/2004 Sb., na elektronické systémy spisové služby, bude to tím spíše (per arg. a maiori ad minus) platit pro požadavky, které jsou na elektronické systémy spisové služby stanoveny prováděcí vyhláškou, která se musí pohybovat v mezích zákona a je od zákona odvozena (čl. 79 odst. 3 Ústavy).
Pokud je v § 70 odst. 2 zákona stanoveno, že národní standard pro elektronické systémy spisové služby, který ministerstvo vnitra zveřejní ve svém věstníku a způsobem umožňujícím dálkový přístup, stanoví požadavky na elektronické systémy spisové služby, nemůže z prováděcí vyhlášky v rozporu s tím vyplývat, resp. nelze prováděcí vyhlášku vykládat v tom smyslu, že by se národní standard pro elektronické systémy spisové služ-by mohl či měl vztahovat na informační systém, který není elektronickým systémem spi-sové služby ve smyslu nově doplňovaného § 3a zákona.
Zákon č. 499/2004 Sb., o archivnictví a spisové službě popisuje především to, jak se mají původci (povinné osoby ze zákona) chovat při správě archiválií a dokumentů. Přičemž:
- dokumentem se myslí každá písemná, obrazová, zvuková nebo jiná zaznamenaná informace, ať již v podobě analogové či digitální, která byla vytvořena původcem nebo byla původci doručena a
- archiválií takový dokument, který byl vzhledem k době vzniku, obsahu, původu, vnějším znakům a trvalé hodnotě dané politickým, hospodářským, právním, historickým, kulturním, vědeckým nebo informačním významem vybrán ve veřejném zájmu k trvalému uchování a byl vzat do evidence archiválií; archiváliemi jsou i pečetidla, razítka a jiné hmotné předměty související s archivním fondem či s archivní sbírkou, které byly vzhledem k době vzniku, obsahu, původu, vnějším znakům a trvalé hodnotě dané politickým, hospodářským, právním, historickým, kulturním, vědeckým nebo informačním významem vybrány a vzaty do evidence.
Platilo, že původce mohl zpracovávat dokumenty jak ve spisové službě, přičemž se stále zpřesňovalo kdy se povinnost vést spisovou službu v elektronické podobě, tak i dalších druzích informačních systémů - např. Samostatné evidenci dokumentů. V aktuálně platné verzi zákona se předpokládá vedení dokumentů pouze v elektronickém systému spisové služby (dále jen "eSSL") a systémech, které nejsou eSSL. Základní přehled rozdílů v povinnostech je uveden v následující tabulce:
Povinnost či právo | eSSL | Informační systém |
---|---|---|
Dodržovat povinnosti zákona č. 499/2004 Sb. pro eSSL | ANO | NE |
Dodržovat povinnosti vyhlášky č. 259/2012 Sb. | ANO | NE |
Dodržovat Národní standard pro elektronické systémy spisové služby | ANO | NE |
Povinně doplňovat metadata dle vzorů DIA do dokumentů | ANO | ANO |
Povinnost vydávat archiválie | ANO | ANO |
Právo požádat si o trvalý skartační souhlas | ANO | ANO |
Obecně o spisové službě
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í“.
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 o změně některých zákonů, ve znění pozdějších předpisů (dále též „Zákon“) a prováděcí vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby. Národní standard pro eSSL (dále též „NSESSS“) vydaný Ministerstvem vnitra a publikovaný ve Věstníku Ministerstva vnitra pak stanovuje podrobné technické požadavky na aplikační a byznysové funkce eSSL. Novelizací Zákona z roku 2021 byla zavedena povinnost atestací pro eSSL (blíže v podkapitole týkající se atestací), ovšem platnost této novely byla několikrát odložena, resp. došlo k odsunu termínů, kdy tato povinnost začne platit. Aktuálně (březen 2024) je ve sněmovně před schválením další novela, která stanovuje tyto termíny:
- Od 1. ledna 2025 již nebude možné nabízet a dodávat veřejnoprávním původcům neatestované eSSL
- Od 1. ledna 2027 již bude muset většina veřejnoprávních původců využívat výlučně atestované eSSL
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). Pojem elektronický dokument je v tomto kontextu shodný s pojmem digitální dokument.
Zákon zavádí pojem „výstupní datové formáty dokumentů“, tj. formáty, ve kterých musí původce ukládat příslušné typy digitálních dokumentů. Definice výstupních datových formátů je uvedena v § 23 vyhlášky č. 259/2012 Sb. Výstupní datové formáty jsou aktuálně definovány pro nejčastější typy digitálních dokumentů.
Zákon ě 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 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.
Shrneme-li základní požadavky, pak původci musí:
- Vykonávat spisovou službu tak, že eviduje dokumenty v eSSL.
- Zajistit soulad eSSL s požadavky NSESSS.
- Mít alespoň jeden eSSL.
- Zajistit integraci mezi informačními systémy a eSSL dle požadavků NSESSS.
- 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.
- Řádně uchovávat a spravovat digitální dokumenty a jejich komponenty v eSSL.
- 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 v souladu s požadavky NSESSS.
- 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 se Zákonem, vyhláškou č. 259/2012 Sb, a NSESSS
- 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
- Uchovávat dokumenty a umožnit výběr archiválií, vybrané archiválie v analogové podobě předávat k uložení příslušnému archivu a archiválie v digitální podobě předávat k uložení 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.
Výběr a dlouhodobá archivace digitálních dat
Výběr a dlouhodobá archivace digitálních dat (dokumentů) probíhá dle zákona o archivnictví č. 499/2004 Sb., kde je dokument definován v § 2 písm. e) jako „každá písemná, obrazová, zvuková nebo jiná zaznamenaná informace, která byla původcem vytvořena nebo byla původci doručena“.
Povinnost uchovávat dokumenty a umožnit výběr archiválií má naprostá většina právnických osob působících v ČR. Tyto subjekty označuje Zákon jako původce dokumentů (viz § 3 Zákona). Novela Zákona platná k 1.7.2024 zavádí navíc § 3a, dle kterého veřejnoprávní původci musí evidovat dokumenty a umožnit jejich výběr (export dle standardu stanoveným Národním archivem) nejen ze systémů eSSL, ale i z dalších informačních systémů, které využívají. De facto se tedy jedná o zavedení standardu Archiving by Design.
Archivně relevantní informace se vyskytují také řadě dalších prostředí, ať jsou to databáze, specializované IS (např. GIS, CAD, BIM), webové stránky či sociální sítě, ze kterých se také provádí výběr a jsou trvale ukládány v prostředí digitálního archivu.
Problematiku výběru dokumentů (informací) trvalé hodnoty, tedy archiválií, a jejich exportu do digitálního archivu řeší také vyhláška č. 360/2023 Sb., o dlouhodobém řízení ISVS. Již při vzniku systémů je třeba pamatovat na možnost exportu dat z nich a to jak pro účely migrace dat do jiného systému nebo pro archivní účely. Archiváři by měli mít možnost již při vzniku systému definovat archivně cenné informace, podobu jejich výstupu a proces přenosu do digitálního archivu (Archiving by Design).
Řídící dokumenty
V rámci výkonu spisové služby jsou řídícími dokumenty zejména:
- Legislativa
- Zákon č. 499/2004 Sb., o archivnictví a spisové službě
- Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby
- Národní standard pro elektronické systémy spisové služby
- Technické a architektonické požadavky
- Národní architektonický plán
- Vnitřní řídící dokumenty úřadu
- Spisový řád (jehož součástí je spisový a skartační plán a podpisový řád)
- Informační koncepce úřadu
- Dokumentace k elektronickému systému spisové služby
- Provozní dokumentace k eSSL dle vyhlášky č. 360/2023 Sb., o dlouhodobém řízení ISVS
- Dokumentace k integracím eSSL a jiných informačních systémů
- 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 (např. INFORMAČNÍ LIST pro otázky elektronické spisové služby a dokumentů v digitální podobě).
Pohled na systém správy dokumentů
Pravidla Systému správy dokumentů
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 eSSL a u ostatní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 eSSL 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 NSESSS) 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 (eSSL je spisovnou pro dokumenty v digitální podobě)
- 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 (systémy, které dokumenty nespravují)
Hovoříme-li o integraci informačních systémů s eSSL 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:
- 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
- Metadata o dokumentu jsou spravována:
- eSSL, nebo
- informačním systémem
- Se soubory v úložišti jsou oprávněny pracovat:
- eSSL, nebo
- informační systém
- Ve Jmenném rejstříku se vede evidence údajů o subjektech, jejichž se týkají dokumenty evidované ve spisové službě
Atestace eSSL
Novelou Zákona z roku 2021 (§ 69b-d) bylo stanoveno, že veřejnoprávní původci budou postupně muset přejít a využívat výhradně systémy eSSL, které jsou atestované. Atestace budou prováděny atestačním střediskem, které určí Ministerstvo vnitra (v současnosti je určena agentura ČAS), případně pokud není určeno, tak samotným ministerstvem. Proces atestace není pouze formální, ale spočívá v tom, že atestační středisko provede funkční testy dle stanovených atestačních scénářů . Atestační scénáře jsou veřejně dostupné na stránkách agentury ČAS . V případě, že eSSL splňuje podmínky stanovené Zákonem, vyhláškou a NSESSS, tak středisko vydá vystaví žadateli písemný atest (platný 2 roky), který je následně zveřejněn, jak na stránkách střediska, tak i ve Věstníku MV. Novelizace z roku 2024 přináší několik zásadních změn:
- Posun lhůt
- Od 1. ledna 2025 zákaz nabídky a dodávky neatestovaných eSSL veřejnoprávním původcům
- Od 1. ledna 2027 bude muset většina veřejnoprávních původců již využívat výhradně atestovaný eSSL
- Vyjmutí malých obcí a škol z povinnosti mít atestovaný eSSL
- Vyjmutí a úprava povinností IS bezpečnostních složek v oblasti atestace eSSL
- Veřejnoprávní původci, resp. jejich IS (nejenom eSSL), budou muset umět dokumenty opatřovat strojově čitelnými metadaty
- Reatestace zůstává 1x za 2 roky a pokud se v tomto období změní legislativa či technické podmínky (např. uvolnění nového releasu, ovšem bez zásadních změn), tak je možné daný eSSL využívat až do konce platnosti původního atestu a reatestovat ho až v další dvouroční lhůtě
- MV může v případě pochybností (např. na základě kontroly) zažádat středisko o reatest
Vazby na architekturu informačního systému veřejné správy
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. Splnění povinností je tedy možné pouze pomocí eSSL splňující požadavky NSESSS.
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í 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 eSSL. 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ů NSESSS 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, kteří 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 zapisují 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.
Výběr a dlouhodobá archivace digitálních dat
Výběr archiválií z dokumentů provádí příslušný archiv podle své působnosti a to nejpozději po uplynutí uschovacích (skartačních) lhůt s tím, že ideální je označit podstatná data za archiválie mnohem dříve. Kritériem výběru je trvalá hodnota dokumentu daná mj. jeho hospodářským, právním, politickým, informačním, historickým, kulturním nebo vědeckým významem. Veškeré archiválie jsou evidovány jako součást národního archivního dědictví. Úkolem archivů je dále trvalé uložení archiválií a jejich ochrana, archivní zpracování a zpřístupnění.
Digitální archiválie lze uchovávat pouze v akreditovaném digitálním archivu metodika. Od roku 2015 je zatím jedinou infrastrukturou tohoto typu Národní digitální archiv (NDA) provozovaný Národním archivem. Ten na Národním archivním portále (NArP) mj. nabízí nástroje pro skartační řízení a přejímku digitálních archiválií.
Výstupní formáty dle pravidel stanovených vyhláškou č. 259/2012 Sb. pokrývají nejběžnější typy dokumentů . U původců se však mohou vyskytovat i jiné typy dokumentů, u kterých není výstupní formát vyhláškou určen. Mimo jiné i proto, že na jeho stanovení není všeobecná shoda. Z hlediska dlouhodobé archivace i potřeb veřejné správy by však bylo přínosné, kdyby existoval registr formátů shrnující vhodnost používání určitého formátu. Proto také vznikl Národní standard formátů pro archivaci, který určuje, jaký formát je pro různé typy dokumentů (dokument tak, jak jej definuje zákon o archivnictví) vhodný k archivaci.
Důležitým zdrojem pro výběr archiválií jsou dokumenty spravované v eSSL. Archivy provádějí dohled nad vedením eSSL a následně dokumenty vybírají ve skartačním řízení k trvalému uložení. Dalšími zdroji dokumentů pro výběr archiválií jsou informační systémy, které spravují dokumenty.
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ů v systému spisové služby. 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 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í protokol1).
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 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 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.
Dalším možným řešení je předávání transakčních protokolů do archivu v krátké lhůtě.
Přístupnost informací
Popis Přístupnosti informací
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:
- Přístupnost služeb veřejné správy
- 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
- 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í.
Pravidla Přístupnosti informací
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í:
- Obecná úroveň
- Mezinárodní přímo aplikovatelná Úmluva o právech osob se zdravotním postižením
- Zákon č. 198/2009 Sb., o rovném zacházení a o právních prostředcích ochrany před diskriminací
- Úroveň základních služeb
- Procesně-správní předpisy, jako je Zákon č. 500/2004 Sb., Správní řád, apod.
- Zákon č. 155/1998 Sb., o komunikačních systémech neslyšících a hluchoslepých osob
- 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)
- Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů
- Úroveň internetových stránek a mobilních aplikací
- Zákon č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací subjektů veřejného sektoru
- 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ší)
- Částečně legislativa ohledně spisové služby
- Úroveň realizace veřejných zakázek
- 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:
- OZP musí mít možnost využívat všechny služby veřejné správy jako kdokoliv jiný
- OZP musí mít možnost plnohodnotně využívat elektronické služby stát i elektronické služby subjektů veřejného sektoru
- 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.
- 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
- 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 na portálu W3C.
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.
Elektronická fakturace
Popis elektronické fakturace
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.
Pravidla elektronické fakturace
Povinnost akceptovat elektrickou fakturu (de standardů níže) se dle zákona č. 134/2016, o zadávání veřejných zakázek, ve znění pozdějších předpisů týká všech orgánů veřejné moci, kteří přijímají platbu plnění veřejné zakázky. Tato povinnost platí od 1. 1. 2019 pro ústřední orgány moci a od 1.4.2020 pro uzemní samosprávu §279 (5) b) zákona č. 134/2016, o zadávání veřejných zakázek, ve znění pozdějších předpisů. Všechny povinné orgány veřejné moci 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ázky. 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 [https://www.zakonyprolidi.cz/cs/2016-134|zákona č. 134/2016, o zadávání veřejných zakázek, ve znění pozdějších předpisů]]. 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šší
Sdílené služby (aplikační a integrační vrstva)
Základní registry a referenční údaje
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,
Referenčními údaji o fyzických osobách jsou2):
- 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 platnosti,
- 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 Digitální a informační agentura. 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 osoby | Agenda | Editor 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í společ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í organizace | PO | A120 | Místně příslušný rejstříkový soud |
U nereferenčních údajů je editorem Digitální a informační agentura.
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, evidenční jednotky 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í 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í 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í.
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, způsobu využití a měsíci a roku dokončení stavebního objektu,
- technickoekonomické atributy stavebního objektu s číslem popisným nebo evidenčním,
- ú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ě.
Účelově územní prvek
Účelově územní prvky (ÚÚP) lze v RUIAN definovat jen na základě zákonného zmocnění, které explicitně označí konkrétní prvky/elementy za účelově územní prvky a určí, jakým informačním systémem veřejné správy bude docházet k jejich editování (zápisu do RUIAN). Platí totiž zásada všech základních registrů, kdy údaje v základním registru jsou vždy ty poslední platné a jejich historie je vedena v editorském informačním systému.
ÚÚP by se do RUIAN měly zapisovat pouze v případě, že je jejich evidence účelná z důvodu užití u více orgánů veřejné správy a jejich procesech či agendách. Tento požadavek je nutné zohlednit při přípravě právních předpisů.
Příklad ÚÚP v zákoně o ochraně a využití nerostného bohatství (horní zákon)
Důvodová zpráva
Zveřejňování informací o chráněných ložiskových územích
Úpravou dochází k naplnění § 1 odst. 2 písm. a) zákona č. 256/2013 Sb., o katastru nemovitostí (katastrální zákon). Katastr nemovitostí je zdrojem informací, které slouží mimo jiné i k ochraně nerostného bohatství státu. Chráněné ložiskové území je základním prvkem ochrany nerostného bohatství státu. Informace o chráněném ložiskovém území je ve vzájemné synergii s informací o dobývacím prostoru. Je tedy zcela logické, že informace o stanoveném dobývacím prostoru a chráněném ložiskovém území je orgány státní správy poskytována veřejnosti zcela shodným způsobem.
Smyslem ustanovení je, aby chráněná ložisková území byla zapisována do RÚIAN jako tzv. účelové územní prvky (§ 31 odst. 2 zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů). Zavedením chráněných ložiskových území do RÚIAN bude vytvořena přidaná hodnota spočívající jednak v jejich zpřístupnění pro celou veřejnou správu i další uživatele, jednak ve vytvoření vazeb na další územní prvky, zejména parcely katastru nemovitostí. V souladu s principy využívání referenčních údajů vedených v základních registrech bude možné tyto údaje automatizovaně přebírat jinými informačními systémy. Vedením chráněných ložiskových území jako účelových územních prvků dojde také ke snížení administrativní zátěže na straně katastrálních úřadů i Ministerstva životního prostředí, neboť odpadne dosavadní povinnost předávat podklady o chráněných ložiskových územích příslušnému katastrálnímu úřadu a katastrálnímu úřadu odpadne povinnost tyto údaje zapisovat do katastru nemovitostí. Tyto údaje budou přebírány do Informačního systému katastru nemovitostí (dále též „ISKN“) automaticky z RÚIAN, kam budou zapisovány prostřednictvím informačního systému České geologické služby, tj. organizace zřízené pro výkon státní geologické služby ve smyslu § 17 zákona č. 62/1988 Sb., o geologických pracích, ve znění pozdějších předpisů.
Zveřejňování informací o dobývacích prostorech
Správní praxe orgánů státní báňské správy ukazuje, že současný způsob zveřejňování informací o stanovených dobývacích prostorech není pro veřejnost dostatečně komfortní. Přestože jsou tyto údaje v současnosti zveřejňovány způsobem umožňujícím dálkový přístup, absence jejich provázanosti s mapovými podklady činí jejich reálné využití ze strany veřejnosti značně komplikovaným.
Smyslem ustanovení je, aby dobývací prostory byly zapisovány do RÚIAN jako tzv. účelové územní prvky (§ 31 odst. 2 zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů). Zavedením dobývacích prostorů do RÚIAN bude vytvořena přidaná hodnota spočívající jednak v jejich zpřístupnění pro celou veřejnou správu i další uživatele, jednak ve vytvoření vazeb na další územní prvky, zejména parcely katastru nemovitostí. V souladu s principy využívání referenčních údajů vedených v základních registrech bude možné tyto údaje automatizovaně přebírat jinými informačními systémy. Vedením dobývacích prostorů jako účelových územních prvků dojde také ke snížení administrativní zátěže na straně katastrálních úřadů i obvodních báňských úřadů, neboť odpadne dosavadní povinnost předávat podklady o dobývacích prostorech příslušnému katastrálnímu úřadu a katastrálnímu úřadu odpadne povinnost tyto údaje zapisovat do katastru nemovitostí. Tyto údaje budou přebírány do Informačního systému katastru nemovitostí (ISKN) automaticky z RÚIAN, kam budou zapisovány prostřednictvím agendového informačního systému ve správě Českého báňského úřadu. Editorem tohoto nového účelového územního prvku bude Český báňský úřad.
Legislativní znění
§ 29 Evidence
- (1) V základním registru územní identifikace, adres a nemovitostí se jako účelové územní prvky29) vedou chráněná ložisková území. O chráněném ložiskovém území se vedou
- a) identifikační údaje, kterými jsou kód, název a identifikační číslo chráněného ložiskového území, pod kterým je veden v evidenci chráněných ložiskových území,
- b) lokalizační údaje, kterými jsou hranice chráněného ložiskového území30),
- c) údaje o vazbách na ostatní územní prvky,
- d) další údaje, kterými jsou
- 1. plocha chráněného ložiskového území,
- 2. nerosty ložiska,
- 3. datum nabytí právní moci rozhodnutí o stanovení chráněného ložiskového území a o jeho změně.
- Editorem údajů je Ministerstvo životního prostředí.
- (2) V základním registru územní identifikace, adres a nemovitostí se dále vedou jako účelové územní prvky29) dobývací prostory. O dobývacím prostoru se vedou
- a) identifikační údaje, kterými jsou kód, název a číslo dobývacího prostoru, pod kterým je veden v souhrnné evidenci dobývacích prostorů,
- b) lokalizační údaje, kterými jsou hranice dobývacího prostoru (§ 26 odst. 1),
- c) údaje o vazbách na ostatní územní prvky,
- d) další údaje, kterými jsou
- 1. plocha dobývacího prostoru na povrchu,
- 2. nerosty ložiska,
- 3. datum nabytí právní moci rozhodnutí o stanovení dobývacího prostoru a o jeho změně.
- Editorem údajů je Český báňský úřad.
- (3) Registr územní identifikace, adres a nemovitostí zprostředkovává z agendového informačního systému Českého báňského úřadu údaje o držiteli dobývacího prostoru pro účely plnění povinností podle § 62 odst. 1 věty první zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.
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.
Zápis/editace údajů do RPP probíhá primárně prostřednictvím takzvaným AIS Působnostní. Návody na práci AIS Působnostní jsou zveřejněny na samostatné stránce ve znalostní bázi.
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. |
Integrace informačních systémů
Popis Integrace informačních systémů
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ě:
- Integrace uvnitř jednoho ISVS mezi více komponentami
- 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í
- Integrace na systémy jiného správce (externí integrace)
Integrace na systémy jiného správce s pomocí eGSB / ISSS
Pravidla Integrace informačních systémů
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.
Vnitřní výměna údajů o subjektech
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.
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.
Vnější výměna údajů o subjektech
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í.
Portály veřejné správy a soukromoprávních uživatelů údajů
Popis Portálů veřejné správy a soukromoprávních uživatelů údajů
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.
Centrální (federující) portály
Centrálními (federujícími) portály jsou myšleny portály, které sdružují informace z dílčích portálů, zprostředkovávají interakci s portály nižší úrovně – federovanými portály (agendové a území). Na rozdíl od portálů nižší úrovně je centrálních (federujících) portálů spočetně méně a slouží především klientům pro snadné vyřízení jeho potřeb na jenom místě. V současné době jsou takovýmito portály pouze Portál veřejné správy a Portál občana (PO a PVS).
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 či systémů pro jiné orgány veřejné správy a klienty veřejné správy. Typicky jde tedy o portál správce agendy, ve kterém lze řešit služby agendy bez ohledu na místní příslušnost. Platí, že služby pro klienta musí být součástí federace a jejich služby přístupné v centrálních (federujících) portálech.
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áří. Platí, že služby pro klienta musí být součástí federace a jejich služby přístupné v centrálních (federujících) portálech.
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
Obyčejný portál
Obyčejným portálem se v tomto smyslu myslí všechny druhy portálů dle jejich zaměření, jak je uvedeno výše, avšak tento diagram zobrazuje práci s daty. Obyčejný portál se chová jako jednotné rozhraní sloužící pro vyřízení služby, avšak její faktické vyřízení probíhá v agendovém informačním systému. Portál si obstarává veškeré údaje a další informace, které klientovi poskytuje, prostřednictvím agendového informačního systému a veškeré dokumenty, které při vyřizování služby vzniknou se musí dostat do spisové služby.
Portál jako Agendový informační systém
Portálem jako Agendovým informačním systémem se v tomto smyslu myslí všechny druhy portálů dle jejich zaměření, jak je uvedeno výše, avšak tento diagram zobrazuje práci s daty. Portál jako Agendový informační systém se chová jako samostatný agendový informační systém, tedy kromě samotného rozhraní pro příjem a vyřízení služby obsahuje i veškerou logiku a podporuje procesy pro její vyřízení. Portál si obstarává veškeré údaje a další informace, které klientovi poskytuje, prostřednictvím přímého napojení na informační systém základních registrů, eGSB/ISSS nebo AIS, které spravuje stejný správce jako portál. Nadále platí, že veškeré dokumenty, které při vyřizování služby vzniknou se musí dostat do spisové služby.
Pravidla Portálů veřejné správy a soukromoprávních uživatelů údajů
Úř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 ačkoliv se nejedná o jeden rozhodný moment (celková doba je 6 měsíců) a je možné podávat i dodatečná daňová přiznání, není nutné klást na infrastrukturu stejné nároky po dobu celého roku, nebo
- žádosti o různé dotace (například tzv. "kotlíkové") se podávají do určitého data, dá se předpokládat jisté vytížení od okamžiku spuštění až do ukončení, kdy budou vysoké nároky na infrastrukturu (se vzrůstajícím trendem) a po uplynutí termínu, kdy budou minimální.
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. Níže uvedená pravidla pro centrální, agendové i místní portály jsou výtažkem ze studií zabývajícími se pravidly a federací portálů Boston Consulting Group - Gov.cz a NAKIT + PwC - Zpracování pravidel pro federaci portálů veřejné správy a definování cílového stavu.
Centrální (federující) portály
- Centrální (federující) portály musí být schopny zpřístupnit informace a služby všech portálů, které splní požadavky kladené federací
- Centrální (federující) portály si kromě uživatelského profilu neuchovávají žádné informace o subjektu práva – identifikovaném a autentizovaném uživateli
Pravidla pro Portál občana a Portál veřejné správy jsou popsána 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 či systémů pro jiné orgány veřejné správy a klienty veřejné správy. Typicky jde tedy o portál správce agendy, ve kterém lze řešit služby agendy bez ohledu na místní příslušnost.
Takový portál musí splnit několik podmínek:
- Musí být registrovaný jako informační systém veřejné správy v rejstříku informačních systémů veřejné správy
- Spravuje ho orgán veřejné správy, který vykonává jednu nebo více agend dle seznamu agend veřejné správy
- Musí být součástí federace portálů veřejné správy a poskytovat informace a služby do centrálních (federujících) portálů jako je např. Portálu občana
- Musí být součástí federace národního identitního schématu, tedy využívat služby Národní identitní autority a jeho správce musí být ohlášen jako kvalifikovaný poskytovatel služeb
- Musí k identifikovanému a autentizovanému uživateli být schopen propojit údaje své agendy a údaje z propojeného datového fondu a veřejného datového fondu
- Musí být v souladu s grafickým manuálem MVČR
- Musí být schopen poskytnout identifikovanému a autentizovanému uživateli možnost udělit mandát/oprávnění k zastupování pro jednotlivé služby, propsat do mandátního registru a nastavené mandáty zobrazovat, přijímat a rušit.
- Musí umožnit učinit podání (učinit úkon) ke službě z katalogu služeb VS pomocí následujících kanálů:
- Elektronicky podepsaným dokumentem ve formě uznávaného podpisu
- Musí být schopen poskytnout náhled na jednotlivá podání vůči úkonům a služeb identifikovanému a autentizovanému uživateli a to jak tomu, který podání učinil, tak tomu, který je k tomu zmocněn
- Musí být schopen poskytnout úhradu poplatku pomocí platební brány
- Veškeré funkcionality, které se vyvinuly na míru, musí být poskytnuty jako otevřený zdrojový kód
- Musí být připraven zvládnout provozní zátěž ve špičkách zájmu o využití jednotlivých služeb (např. pomocí asynchronní architektury, využitím cloud computingu, atd.)
- Pokud portál přímo čerpá nebo poskytuje služby informačním systémům veřejné správy jiných správců, je toto propojení realizováno výhradně prostřednictvím služeb KIVS/CMS.
Postup činností práce s klientem, jeho identifikací a výběrem služeb
- Po zvolení služby klientem, OVS zajistí překlad identity (BSI-AIFO agendy vybrané služby) pomocí eGON služeb ISZR
- OVS se doptá na oprávněné údaje pro potřeby služby dle oprávnění vybrané agendy
- OVS dá klientovi vybrat, do jaké role chce obsadit dle agendy, ve které je služba poskytována (tzv. mandát)
- Po dokončení služby si OVS nepamatuje AIFO ani jiné údaje použité pro službu, pokud to nevyžaduje samotná agenda
- OVS si pamatuje BSI pro klientský profil na portále
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áří.
Takový portál musí splnit několik podmínek:
- Musí být pro každou samosprávu jeden. Je na něm dostupné vše, v čem má samospráva působnost, tedy včetně přenesené působnosti.
- Musí být registrovaný jako informační systém veřejné správy v systému o informačních systémech veřejné správy
- Musí být součástí federace portálů veřejné správy a poskytovat informace a služby do centrálních (federujících) portálů jako je např. Portálu občana
- Musí být součástí federace národního identitního schématu, tedy využívat služby Národní identitní autority a jeho správce musí být ohlášen jako kvalifikovaný poskytovatel služeb
- Musí k identifikovanému a autentizovanému uživateli být schopen propojit údaje své agendy a údaje z propojeného datového fondu a veřejného datového fondu
- Musí být v souladu s grafickým manuálem MVČR
- Musí být schopen poskytnout identifikovanému a autentizovanému uživateli možnost udělit mandát/oprávnění k zastupování pro jednotlivé služby, propsat do mandátního registru a nastavené mandáty zobrazovat, přijímat a rušit.
- Musí umožnit učinit podání (učinit úkon) ke službě z katalogu služeb VS pomocí následujících kanálů:
- Elektronicky podepsaným dokumentem ve formě uznávaného podpisu
- Musí být schopen poskytnout náhled na jednotlivá podání vůči úkonům a služeb identifikovanému a autentizovanému uživateli a to jak tomu, který podání učinil, tak tomu, který je k tomu zmocněn
- Musí být schopen poskytnout úhradu poplatku pomocí platební brány
- Veškeré funkcionality, které se vyvinuly na míru, musí být poskytnuty jako otevřený zdrojový kód
- Musí být připraven zvládnout provozní zátěž ve špičkách zájmu o využití jednotlivých služeb (např. pomocí asynchronní architektury, využitím cloud computingu, atd.)
- Pokud portál přímo čerpá nebo poskytuje služby informačním systémům veřejné správy jiných správců, je toto propojení realizováno výhradně prostřednictvím služeb KIVS/CMS.
Příklad postupu činností v portálu území ve vztahu ke klientovi:
- Po zvolení služby klientem, OVS zajistí překlad identity (BSI-AIFO agendy vybrané služby) pomocí eGON služeb ISZR
- OVS se doptá na oprávněné údaje pro potřeby služby
- OVS rozlišuje mezi samostatnou a přenesenou působností
- Samostatná působnost je soubor více agend, nelze celou samostatnou působnost konat jako jednu agendu
- OVS dá klientovi vybrat, do jaké role chce obsadit dle agendy, ve které je služba poskytována (tzv. mandát)
- Po dokončení služby si OVS nepamatuje AIFO ani jiné údaje použité pro službu, pokud to nevyžaduje samotná agenda
- OVS si pamatuje BSI pro klientský profil na portále
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:
- 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
- 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.
- 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)
- 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ánky
- 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
- Musí umět přijímat a zpracovávat data pomocí standardů SAML2 nebo WS-Federation
Postup činností práce s klientem, jeho identifikací a výběrem služeb
- Portál SPUU nemusí být ISVS
- Klienti se připojující přes NIA jsou identifikováni pomocí BSI do doby, než si klient zvolí veřejnoprávní službu
- Pro potřeby doptání se dalších údajů, musí využít ISVS (možno i jiného OVS vykonávající danou agendu), kterému předá BSI uživatele. Předávání údajů mezi SPUU a OVS musí být legislativně podchyceno
- SPUU dá klientovi vybrat, do jaké role chce obsadit
- Po dokončení služby si SPUU nepamatuje údaje použité pro službu, pokud to nevyžaduje specifické zmocnění
- SPUU si pamatuje BSI pro klientský profil na portále
- Soukromoprávní služby se řídí vlastními specifickými pravidly!
Elektronická identifikace pro klienty veřejné správy
Popis identifikace klientů veřejné správy
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ě.
Pohled na identifikaci a identifikátory klientů VS
Pravidla pro identifikace klientů veřejné správy
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:
- Střední úroveň
- Zjištění, zda nejde o padělaný občanský průkaz
- Zjištění, zda je předložený občanský průkaz platný
- Kontrola fotografie a údajů na občanském průkaze proti klientovi, který jej předložil
- Vysoká úroveň
- Zjištění, zda nejde o padělaný občanský průkaz
- Zjištění, zda je předložený občanský průkaz platný
- Kontrola fotografie a údajů na občanském průkaze proti klientovi, který jej předložil
- Vyžádání si aktuálních údajů, včetně fotografie, o klientovi, který jej předložil a jejich kontrola
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í:
- Znalost typů mandátů při jednání s veřejnou správou
- Jednoznačnou identifikaci a autentizaci klienta veřejné správy
- Systém veřejné správy schopný komunikovat a získávat údaje z propojeného datového fondu
- 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, osvojitel, poručík, pěstoun - dědic, exekutor, - zastupující osoba pro osoby neschopné jednat nebo nemající zákonného zástupce |
|
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. |
Příklady mandátů pro fyzické osoby vyplývající z některých vyhlášek a nařízení měst a obcí:
- Pro přihlášení k platbě poplatku za odvoz komunálního odpadu
- Pro přihlášení k platbě poplatku:
- ubytovacího,
- ze psa,
- za zábor a užívání veřejného prostranství.
- Pro převody, koupě, prodej, nabytí městského majetku, (provozovny v budovách v majetku města)
- Pro užívání, podnájem, zrušení užívání bytového fondu města
- Mandát pro jednání s knihovnou – výpůjčky registrovaného čtenáře
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.
- 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:
-
- pro zajištění ověření, zda je fyzická osoba statutárním zástupcem
-
- 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
-
- 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ě.
Jednotný identitní prostor veřejné správy
Jednotný identitní prostor - v současném provedení systému JIP/KAAS bude postupně nahrazen systémem CAAIS (Centrální autentizační a autorizační informační systém), jehož popis API je k dispozici zde
Popis Jednotného identitního prostoru veřejné správy
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 Digitální a informační agentura. 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í.
Využití systému JIP/KAAS je možné i s pomocí prostředků národního identitního prostoru. 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ům. 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ů.
Procesy založení a zjištění lokálního administrátora
Pro zjištění informací o lokálním administrátorovi subjektu a zároveň i pro registraci nového, slouží formulář pro správu lokálních administrátorů. Najdete jej na stránce Czech POINT – ke stažení https://www.czechpoint.cz/data/formulare/files/sprava_lokalnich_administratoru.zfo. Formulář je ve formátu ZFO, pro jeho otevření a vyplnění je zapotřebí mít nainstalovaný program „Software602 Form Filler“, který je zdarma ke stažení na https://www.602.cz/form-filler.
Formulář je tříkrokový:
- Otevřete formulář prostřednictvím programu Software602 Form Filler a v rámci prvního kroku pouze zaškrtněte políčko „Žádám o zaslání aktuálního seznamu lokálních administrátorů“. Formulář odešlete buď přímo z formuláře (formulář vás vyzve k zadání údajů o datové schránce vašeho subjektu) nebo jej uložte na lokální disk a odešlete jako přílohu z datové schránky vašeho subjektu, případně prostřednictvím spisové služby. Formulář pošlete ve formátu ZFO do tzv. „další datové schránky“ Digitální a informační agentury – Automat SOVM (vu33nsr). Průvodní dopis není zapotřebí, ale není na překážku.
- Systém vaši žádost automaticky zpracuje a pošle odpověď do datové schránky vašeho subjektu (spisové služby). Odpověď má podobu předvyplněného formuláře ZFO. Ve formuláři bude uveden seznam všech lokálních administrátorů registrovaných pod vaším subjektem. V rámci tohoto formuláře proveďte editaci již existujících lokálních administrátorů (včetně možnosti deaktivace účtu) nebo požádejte o zřízení nového účtu. Upravený formulář opět odešlete ke zpracování do DS DIA buď přímo z programu, nebo prostřednictvím datové schránky.
- V rámci posledního kroku obdržíte do datové schránky odpověď s výsledkem zpracování vaší žádosti. V případě založení nového účtu budou k odpovědi připojeny pokyny pro lokálního administrátora k vyzvednutí přihlašovacích údajů k účtu.
POZOR_ Jakmile pošlete formulář se žádostí o informace/registraci nového lokálního administrátora, pokračujte prosím v provedení i zbývajících kroků, i když jste s aktuálním nastavením lokálního administrátora spokojení a nechcete ho měnit
Pohledy na jednotný identitní prostor
Pravidla Jednotného identitního prostoru veřejné správy
Úř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.
Uživatelé ISVS a způsob jejich autentizace
1. Klient veřejné správy Uživatel, který se do AIS přihlašuje z důvodu, aby veřejnou správu požádal o nějaký úkon. Povinnost autentizace: NIA (jakýkoliv identifikační prostředek např. bankovní identita, NIA ID, Mobilní klíč egovernmentu atd.)
2. Zaměstnanec veřejné správy Uživatel, který se do AIS přihlašuje z důvodu, aby úkon o který klient žádá řešil. Povinnost autentizace: JIP/KAAS (přes NIA nebo jméno a heslo a druhý faktor: Aplikace, SMS, certifikát), CAAIS (přes NIA nebo CAAIS IdP: jméno + heslo + certifikát)
3. Správce AIS Uživatel, který se do AIS přihlašuje z důvodu řízení a participace na správě, údržbě, řešení vad a změn a výkonu podpory. Povinnost autentizace: Jakýkoliv přístup s druhým faktorem. Např. i Proprietární software + druhý faktor
4. Dodavatel (provozovatel a poskytovatel) AIS Uživatel, který se do AIS přihlašuje z důvodu jeho správy, údržby, řešení vad a změn a výkonu podpory. Povinnost autentizace: Jakýkoliv přístup s druhým faktorem. Např. i Proprietární software + druhý faktor
Jednotné obslužné kanály a uživatelská rozhraní úředníků
Popis Jednotných obslužných kanálů úředníků
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ů
Pravidla Jednotných obslužných kanálů úředníků
NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.
Veřejný datový fond
Popis veřejného datového fondu
Veřejný datový fond (VDF) je definován v Informační koncepci ČR (IKČR) jako dílčí cíl 5.10 a je součástí budovaného eGovernmentu VS Č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 otevřených 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.”
Legislativní ukotvení veřejného datového fondu
VDF není v legislativě jako pojem explicitně zmíněn. Legislativa pouze zavádí pojmy důležité v rámci VDF a pravidla evidence a sdílení údajů ve VDF. VDF je ukotven v zákoně č. 111/2009 Sb., o základních registrech (ZoZR), zákoně č. 106/1999 Sb., o svobodném přístupu k informacím (InfoZ) a zákoně č. 365/2000 Sb. o informačních systémech veřejné správy (ZoISVS).
Základním pojmem je údaj vedený nebo vytvářený v rámci agendy. Podle § 51 odst. 6, písm. k) ZoZR je pro každý údaj vedený nebo vytvářený v rámci agendy v RPP vedena jeho přístupnost veřejnosti a v případě, že údaj není přístupný veřejnosti, číslo a název právního předpisu a označení jeho ustanovení (v budoucnu jako odkaz do eSeL), na jehož základě není údaj přístupný veřejnosti (resp. seznam takových referencí na ustanovení právních předpisů). Pokud tedy neexistují legislativní překážky ke zveřejnění údaje, jedná se o údaj přístupný veřejnosti (dále jen veřejný údaj). Veřejný údaj je speciálním případem údaje.
Způsob poskytnutí údaje zveřejněním upravuje § 4b InfoZ, dle kterého se veřejný údaj poskytuje jako informace ve všech formátech a jazycích, ve kterých byla informace vytvořena; při zveřejnění takové informace v elektronické podobě musí být jeden z těchto formátů otevřený a, je-li to možné, též strojově čitelný. Je-li to možné a vhodné, zveřejní povinný subjekt spolu s informací též metadata, která se k ní vztahují. Formát i metadata by měly co nejvíce splňovat otevřené formální normy.
V případě údajů spravovaných v AIS se z principu jedná o informace vedené ve strukturované podobě ve vnitřních databázích informačních systémů, které jsou spravovány databázovými systémy. Databázový systém má rozhraní pro získání obsahu údajů, prostřednictvím kterého lze obsah údajů ve strukturované podobě získat. Jejich zveřejnění v otevřeném a strojově čitelném formátu je tedy technicky možné vždy. Zároveň je možné zveřejnit spolu s informací i metadata a při volbě formátu zveřejněné informace a reprezentaci metadat plně postupovat podle otevřených formálních norem. Z důvodu dosažení interoperability mezi informačními systémy veřejné správy a také z důvodu dosažení přeshraniční interoperability je nutné při zveřejňování údajů postupovat podle otevřených formálních norem vydávaných MV ČR a při zveřejňování metadat je nutné postupovat dle otevřené formální normy rozhraní katalogů otevřených dat. Jinými slovy, veřejné údaje jsou zveřejňovány v otevřeném a strojově čitelném formátu dle otevřených formálních norem vydávaných MV ČR a jsou katalogizovány v Národním katalogu otevřených dat (NKOD).
Dále je dle § 51 odst. 6, písm. k) ZoZR pro údaj vedený nebo vytvářený v rámci agendy, jehož možné hodnoty jsou vymezeny číselníkem, tento číselník veden v RPP. Podle § 69 odst. 4 ZoZR MV ČR zveřejní otevřenou formální normu pro vytvoření číselníku a podle § 51 odst. 11 ZoZR jsou tyto číselníky veřejně přístupné způsobem umožňujícím dálkový přístup. Číselník pro vymezení možných hodnot údajů pro účely tohoto dokumentu nazýváme veřejný číselník. Ze spojení s § 5a odst. 2 InfoZ pak vyplývá, že veřejný číselník musí být zveřejněn jako otevřená data podle otevřené formální normy vyplývající z § 69 odst. 4 ZoZR.
Z pohledu ZoZR odlišujeme dva možné typy veřejných číselníků. Dle § 50 odst. 2 ZoZR to jsou číselníky ČSÚ. Dle § 54 odst. 1, písm. a) ZoZR to jsou číselníky ohlašovatelů agend. Jinými slovy, možné hodnoty údaje lze vymezit buď číselníkem ČSÚ nebo číselníkem ohlašovatele agendy. Z § 54 odst. 1, písm. a) ZoZR vyplývá, že primárně musí být volen číselník, který již je v RPP veden. Pouze pokud žádný vhodný číselník v RPP veden není, uvádí ohlašovatel agendy svůj vlastní číselník, tj. nový číselník ohlašovatele agendy.
Jak bylo zmíněno na začátku dokumentu, rozlišení údajů na veřejné a neveřejné provádíme z pohledu sdílení údajů. Ať už se jedná o údaje veřejné nebo neveřejné, sdílením se podle § 2 písm. o) ZoISVS rozumí umožnění přístupu k daným datům prostřednictvím referenčního rozhraní.
Podle § 51 odst. 6, písm. k) ZoZR musí ohlašovatel agendy zdůvodnit neveřejnost každého jednotlivého údaje, který není přístupný veřejnosti.
Pro zajištění přístupu k neveřejnému údaji je dle § 54 odst. 1, písm. d) ZoZR nutno projít administrativní procedurou vedoucí k získání kladného stanoviska k využití neveřejného údaje. Je také nutno dle § 51 odst. 6, písm. l,m) ZoZR evidovat údaje zpřístupněné pro výkon agendy a dle § 57 odst. 1 a 2 ZoZR je nutno vést záznamy o využívání neveřejných údajů.
Naproti tomu využívání veřejných údajů je spojeno s nižší administrativní zátěží. Je pouze nutné podle § 54 odst. 1, písm. c) ZoZR při ohlášení agendy uvést, jaké veřejné údaje budou využívány pro výkon agendy.
Principy veřejného datového fondu
Obecným výchozím principem VDF je princip P13 eGovernmentu “Otevřená data jako standard” (Open Data by Default):
“Veřejné údaje evidované orgány veřejné správy ve spravovaných ISVS musí být zveřejňovány jako otevřená data. Pro neveřejné údaje musí být jako otevřená data zveřejňována jejich anonymizovaná podoba, souhrn nebo statistika. V případě, že orgány veřejné správy sdílejí veřejné údaje (včetně anonymizované podoby neveřejných údajů, souhrnů nebo statistik) musí je sdílet jako otevřená data.“
VDF zpřístupňuje veřejné registrované údaje jednotlivým OVM a SPUÚ pro čtení bez omezení přístupu. Navíc jsou všechny údaje přístupné z VDF dostupné ve stejné podobě také prostřednictvím otevřeného přístupu, a to bez výjimky. V obou případech zpřístupnění, tj. prostřednictvím VDF a prostřednictvím otevřeného přístupu, jsou údaje přístupné jako otevřená data dle § 3 odst. 11 InfoZ.
Pro vymezení navazujících pravidel VDF a navržení jeho celkové architektury slouží čtyři základní principy.
- P1 (distribuovanost) - VDF zastřešuje a popisuje skutečné datové zdroje poskytující údaje prostřednictvím referenčního rozhraní a stanovuje pravidla poskytování a čerpání údajů, ale nevynucuje jejich centralizaci na jedno místo.
- P2 (garance) - pro OVM a SPUÚ čerpající údaje z VDF je garantována technická dostupnost a formální správnost (věcná správnost, úplnost, platnost a pravidelná aktualizace) těchto údajů.
- P3 (otevřená data) - údaje přístupné z VDF jsou zpřístupněny jako otevřená data dle § 3 odst. 11 InfoZ bez výjimky.
- P4 (interoperabilita) - údaje jsou z VDF zpřístupněny v podobě, která zajišťuje schopnost různých programových vybavení vzájemně si poskytovat služby a efektivně spolupracovat.
Princip P1 – distribuovanost
VDF zastřešuje skutečné datové zdroje, které nemusí být centralizovány v jednom jediném úložišti. VDF spravuje a organizuje metadata o datových sadách, ve kterých jsou údaje z datových zdrojů zpřístupněny. Mezi tato metadata zejména patří:
- základní charakteristika datové sady (název, popis apod.),
- dokumentace datové sady,
- popis technického zpřístupnění datové sady.
Metadata o datových sadách jsou evidovány v podobě katalogizačních záznamů v NKOD.
Princip P2 – garance
OVM garantuje zpřístupnění veškerých veřejných registrovaných údajů, jejichž je autoritativním zdrojem, prostřednictvím referenčního rozhraní do VDF a na svůj náklad. Údaje dostupné z VDF musí být navíc pro účely čerpání OVM a SPUÚ dostupné, správné, úplné, platné a pravidelně aktualizované s jasně definovanou odpovědností poskytujícího OVM za poskytnutý obsah.
Pro údaje ve VDF platí:
- OVM může do VDF poskytovat pouze údaje, u kterých je autoritativním zdrojem.
- OVM poskytující údaje do VDF garantuje správnost, úplnost, platnost a aktuálnost pro čerpající OVM a SPUÚ.
- Infrastruktura VDF zajišťuje jejich dostupnost.
- Pokud OVM či SPUÚ čerpá údaje z VDF, považuje je za správné, úplné, platné a aktuální a nemusí tyto jejich vlastnosti ověřovat.
- Pokud OVM či SPUÚ využívá údaje dostupné ve VDF, přičemž je nezískal přímo z VDF, ale nějakým jiným způsobem, nemůže tyto údaje považovat za správné, úplné, platné ani aktuální.
- Při změně údajů dostupných ve VDF jsou notifikovány všechny OVM a SPUÚ, které údaje využívají.
Princip P3 – otevřená data
Údaje dostupné ve VDF jsou v totožné podobě také povinně publikovány jako otevřená data dle § 3 odst. 11 InfoZ. VDF tedy chápeme jako prostředek pro přístup jednotlivých OVM a SPUÚ ke garantovaným otevřeným datům.
Princip P4 – interoperabilita
Dva softwarové systémy jsou interoperabilní, pokud jsou schopné si vyměňovat informace a vzájemně si rozumět. V kontextu VDF, jeho širokého využití a velkého počtu informačních systémů je proto nutné zajistit interoperabilitu na úrovni dat reprezentujících vyměňované údaje. Datovou interoperabilitu lze charakterizovat jako:
- technickou – použití standardních webových technologií pro perzistentní (tj. trvalou) identifikaci údajů a jejich výměnu,
- syntaktickou – specifikace a dodržování konkrétních formátů dat, komunikačních protokolů a dalších vlastností systémů, které umožňují přistupovat k datům z různých zdrojů standardním způsobem,
- sémantickou – způsob popisu a mapování datových položek, společné slovníky a jednotná klasifikace pojmů.
Ve VDF je technická, syntaktická a sémantická interoperabilita zajištěna prostřednictvím otevřených formálních norem vydávaných MV ČR pro různé typy dat poskytovaných do VDF.
Začlenění veřejného datového fondu do výkonu veřejné správy
Využití veřejného datového fondu pro doplnění datového kmene agendy
Základem pro výkon agendy je její datový kmen. Kompletace datového kmene agendy pro konkrétní výkon je zajišťována prostřednictvím PPDF a VDF. Výměna neveřejných registrovaných údajů je prováděna prostřednictvím PPDF ve vazbě na konkrétní subjekt práva evidovaný v základních registrech na základě oprávnění evidovaných v RPP. Veřejné registrované údaje jsou vyměňovány prostřednictvím VDF. Výměna prostřednictvím VDF je spojena s jednodušším administrativním procesem a oproti výměně prostřednictvím PPDF umožňuje dávkovou výměnu údajů v podobě celého obsahu datových sad s údaji bez vazby na konkrétní subjekt práva. Je-li to nezbytně nutné, lze veřejné registrované údaje sdílet i prostřednictvím PPDF, ale vždy jen na základě oprávnění a ve vazbě na konkrétní subjekt práva.
Přístup veřejnosti k údajům
K údajům veřejné správy má možnost přístupu ke čtení i veřejnost.
Přístup veřejnosti k veřejným údajům je zajišťován prostřednictvím otevřeného přístupu. Ten je charakteristický tím, že veřejné údaje jsou pro čtení zpřístupněny anonymním uživatelům z veřejného internetu bez jakéhokoliv omezení.
Přístup veřejnosti k neveřejným údajům je realizován prostřednictvím řízeného přístupu. Pro tento přístup ale platí, že je možný pouze na základě definovaných oprávnění konkrétním subjektům práva. Pravidla řízeného přístupu však budou teprve popsána a zde se jim dále nevěnujeme.
Základní struktura veřejného datového fondu
Vnitřní architektura VDF je kromě samotných veřejných registrovaných údajů datového fondu VS ČR tvořena také dílčími nástroji. Dílčí nástroje jsou primárně určeny pro ukládání obsahu datových sad a práci s metadaty datových sad. Dále je tvořen souborem pravidel, postupů a doporučení, které slouží k zabezpečení vyžadovaných vlastností zpřístupněných údajů, k zajištění jejich správné publikace a vytvoření podmínek pro využití publikovaných údajů při výkonu veřejné správy. Architektura VDF je zcela otevřená a připravená pro její další rozšiřování v závislosti na požadavcích na další funkcionality, a také pro podporu sémantické interoperability.
Přístup k údajům prostřednictvím VDF je technicky zajišťován jako
- přístup k datovým souborům s obsahem datových sad ke stažení (povinně)
- přístup ke konkrétní položce datové sady prostřednictvím REST API (volitelně)
- dotazování nad obsahem datové sady prostřednictvím SPARQL API (volitelně)
Přístup je zajištěn pomocí služeb referenčního rozhraní. Pro účely PPDF jsou služby referenčního rozhraní poskytovány prostřednictvím ISZR a ISSS. Oba ale předpokládají přístup k údajům o konkrétním subjektu práva vedeném v ZR a s potřebnými oprávněními. VDF však zavádí dávkový přístup k obsahu jednoho nebo více údajů bez vazby na konkrétní subjekt práva a to ke kompletnímu obsahu nebo k obsahu vázanému na jednu datovou položku. Za tímto účelem musí být referenční rozhraní rozšířeno o nové služby pro:
- čtení publikovaného datového souboru s obsahem datové sady
- čtení publikované položky datové sady
- dotazování nad obsahem datové sady
Tyto nové služby nemohou být z výše uvedených důvodů poskytovány prostřednictvím ISZR ani ISSS a proto je zavedena nová třetí komponenta referenčního rozhraní Informační systém garantovaných otevřených dat (ISGOD). ISGOD zajišťuje jednotlivým OVM a SPUÚ přístup ke garantovaným otevřeným datům ve VDF prostřednictvím referenčního rozhraní.
Do VDF publikují jednotlivé AIS i ZR. Dále tedy v textu hovoříme o publikujícím ISVS, ale vždy je tím myšleno publikující AIS či ZR.
ISGOD je logickým zastřešením několika aplikačních komponent tvořících prostředí VDF. Komponenty jsou popsány v následujících podkapitolách.
Úložiště datových sad
Úložiště datových sad slouží k ukládání obsahu registrovaných veřejných údajů vedených v daném publikujícím ISVS v podobě distribucí datových sad. Pro každý publikující ISVS je vytvořeno úložiště, jehož správcem je správce ISVS. Úložiště datových sad zajišťuje:
- kontrolu souladu nahrávaného obsahu s otevřenými formálními normami
- transformaci obsahu do všech podob daných otevřenými formálními normami s pomocí transformačních skriptů definovaných otevřenými formálními normami
- zpřístupnění těchto podob jako distribuce datových sad, a to jako
- datové soubory ke stažení (povinně)
- API umožňující přistoupit ke každé jednotlivé položce datové sady (nepovinně)
- API umožňující dotazování nad obsahem uložených datových sad pomocí dotazovacího jazyka SPARQL (nepovinně)
- garantovanou dostupnost distribucí datových sad při přístupu prostřednictvím ISGOD
- negarantovanou dostupnost distribucí datových sad při přístupu prostřednictvím veřejného internetu
Úložiště datových sad daného publikujícího ISVS není novým ISVS, ale je součástí publikujícího ISVS.
Softwarový nástroj úložiště datových sad může správce ISVS vyvinout vlastní nebo může využít volně dostupný open-source nástroj nabízený a udržovaný MV ČR.
Národní katalog otevřených dat
V NKOD jsou evidovány katalogizační záznamy o všech datových sadách dostupných ve VDF. Za katalogizaci datových sad je zodpovědný publikující ISVS, který nahrává obsah do svého úložiště datových sad jako distribuce obsahu datové sady. Publikující ISVS poskytuje API dle otevřené formální normy rozhraní katalogů otevřených dat, prostřednictvím kterého poskytuje katalogizační záznamy o svých publikovaných datových sadách. API zaregistruje správce ISVS v NKOD. NKOD si poté pravidelně katalogizační záznamy načítá.
Čtenáři údajů z VDF mohou v NKOD vyhledávat datové sady a získávat tak metadata popisující přístup k jejich distribucím prostřednictvím VDF. Metadata také popisují přístup k distribucím prostřednictvím otevřeného přístupu.
Správcem NKOD je MV ČR.
Registr práv a povinností
V RPP je evidována přístupnost registrovaných údajů veřejnosti (tj. veřejnost údajů) a veřejné číselníky, které kódují jejich možné hodnoty. Ohlašovatel agendy je povinen označit přístupnost údaje veřejnosti. Také je povinen uvést, zda je údaj kódován veřejným číselníkem. Obsah veřejných údajů a veřejných číselníků je pak sdílený v podobě distribucí datových sad dostupných jako otevřená data prostřednictvím otevřeného přístupu a prostřednictvím VDF.
Pro potřeby otevřeného přístupu i VDF je pro každý veřejných číselník evidováno IRI datové sady v NKOD, ve které je obsah číselníku přístupný. To samé platí pro veřejný údaj, pouze může být datových sad více.
Čtenáři údajů z VDF vyhledávají v RPP evidenci údajů potřebné údaje. V případě veřejných údajů získávají IRI datových sad v NKOD, s pomocí kterých mohou z NKOD získat metadata popisující přístup k obsahu veřejných údajů. Podobně v případě údajů, jejichž hodnoty jsou kódovány veřejnými číselníky, získávají IRI datových sad v NKOD, s pomocí kterých mohou z NKOD získat metadata popisující přístup k obsahu veřejných číselníků.
V RPP je také pro každou agendu evidován výčet veřejných registrovaných údajů, které jsou využívány pro výkon agendy.
Správcem RPP je MV ČR.
Katalog uživatelů dat
Katalog uživatelů dat eviduje, jaké datové sady z VDF čerpají konkrétní OVM a SPUÚ. Registraci čerpání datové sady provádí OVM či SPUÚ za účelem získávání notifikací o změnách v datové sadě. Registrace je předvyplněna z evidence čtení registrovaných veřejných údajů v RPP.
Registrace mj. obsahuje:
- IRI OVM či SPUÚ
- IRI datové sady
- požadovanou maximální frekvenci notifikací (ihned, hodinová, denní, týdenní, …)
- požadovaný způsob a technická specifikace notifikace (datová schránka, WebSub protokol)
Správcem katalogu uživatelů dat je MV ČR.
Notifikační hub
Notifikační hub je nástroj zajišťující s pomocí katalogu uživatelů dat notifikační službu, která informuje subjekty registrované v katalogu uživatelů dat ke čtení datových sad z VDF o změnách v datových sadách. Jedná se o automatickou notifikaci o změnách zjištěných při ohlášení změny ze strany poskytujícího ISVS.
Notifikační hub je implementován na bázi mezinárodního standardu W3C Recommendation WebSub.
Správcem Notifikačního hubu je MV ČR.
Směrovací služba
Distribuce datové sady je v otevřených datech zpřístupněna jako datový soubor ke stažení nebo jako API, které umožňuje získat data každé jednotlivé položky datové sady (entity), o níž jsou v datové sadě reprezentovány údaje. Přístup k údajům je realizován s pomocí tzv. dereference identifikátoru položky. V otevřených datech jsou jako identifikátory použity tzv. IRI (Internationalized resource identifier, více viz Otevřená formální norma pro propojená data). Dereference identifikátoru v podobě IRI znamená přistoupení k IRI prostřednictvím HTTP protokolu podobně jako přistupujeme k webovým stránkám. Výsledkem dereference je strojově nebo lidsky čitelná reprezentace údajů o identifikované položce (v závislosti na HTTP content negotiation).
IRI položky vyplývá z úložiště datových sad, na kterém je datová sada s položkou fyzicky uložena a z pravidel pro tvorbu IRI. To ale činí IRI závislé na konkrétním fyzickém umístění, které se může měnit. Např. může změnit své fyzické umístění celé úložiště tím, že se změní jeho provozovatel nebo je přesunuto do jiného prostředí. Nebo může dojít k rozhodnutí přesunout obsah datové sady do jiného úložiště. Pokud k takové změně dojde, může dojít i ke změně IRI položek. Přes tato IRI ale již mohou být propojeny údaje o prvku či souvisejících prvcích z jiných datových sad ve VDF i v otevřených datech či údajích dostupných přes řízený přístup. Pokud se IRI takto mění, znamená to, že nejsou tzv. perzistentní, tj. trvalé. Pro zajištění perzistentních, tj. trvalých, identifikátorů slouží směrovací a indexační služba.
Pro veřejný údaj je nutné, aby správce ISVS, ze kterého se obsah údaje publikuje, zavedl identifikátory položek datové sady do směrovací služby a určil k nim tzv. referenční identifikátory na doméně gov.cz. Pro položku tak existují dva identifikátory. První je původní identifikátor položky určený správcem ISVS. Vyplývá z úložiště datových sad, ve kterém je obsah datové sady uložen. Jedná se o IRI v doméně úložiště, při jehož dereferenci úložiště poskytne obsah o identifikované položce. Nazýváme jej lokální identifikátor položky nebo zkráceně lokální IRI položky. Druhý identifikátor je nový identifikátor, který je nezávislý na úložišti. Nazýváme jej referenční identifikátor položky ve VDF nebo zkráceně referenční IRI položky. Referenční IRI používají pro odkazování se na položku všechny datové sady. Dereference referenčního IRI vede na směrovací službu, která provede přesměrování na lokální IRI položky.
Při změně úložiště datových sad nebo obecně při změně lokálních IRI je upraveno směrování ve směrovací službě. Tím je zajištěna perzistence IRI, která umožňuje trvalé a neměnné propojení údajů o stejné položce napříč různými datovými zdroji nezávisle na poskytovatelích těchto údajů.
Správcem směrovací a indexační služby je MV ČR.
Pravidla veřejného datového fondu
Pravidla pro údaje zpřístupněné veřejným datovým fondem
Ve VDF jsou zpřístupňovány veřejné registrované údaje spravované jednotlivými OVM. Pro údaje zpřístupněné prostřednictvím VDF platí:
- Údaje jsou zpřístupněny v datových sadách prostřednictvím referenčního rozhraní pro potřeby čtenářů údajů - OVM a SPUÚ.
- Datové sady jsou navíc publikovány prostřednictvím otevřeného přístupu (tj. jako otevřená data dle § 3 odst. 11 InfoZ) v totožné podobě (tj. s totožnou strukturou a sémantikou).
- Otevřený přístup i přístup prostřednictvím VDF jsou tedy dva přístupy ke stejnému obsahu v podobě otevřených dat.
- První je určen pro veřejnost, druhý je určen pro OVM a SPUÚ a je realizován prostřednictvím referenčního rozhraní.
- Datové sady jsou popsány v podobě katalogizačních záznamů (metadat) v NKOD.
- Datové sady jsou fyzicky dostupné v podobě distribucí. Různé distribuce stejné datové sady zpřístupňují její obsah v různých formátech a prostřednictvím různých přístupových mechanismů. Proto je každá distribuce zaznamenána v katalogizačním záznamu datové sady v NKOD. VDF předpokládá tři následující způsoby zpřístupnění obsahu datové sady, z nichž první je povinný a zbylé dva jsou volitelné:
- v podobě datového souboru s kompletním obsahem datové sady ke stažení,
- v podobě API, které umožňuje přistupovat ke kompletním údajům o každé jednotlivé entitě či konceptu, o němž jsou v datové sadě reprezentovány údaje, prostřednictvím dereference identifikátoru entity či konceptu, který je stanoven poskytovatelem údajů v podobě IRI (Internationalized Resource Identifier, více viz Otevřená formální norma pro propojená data) a
- v podobě API, které umožňuje dotazování nad obsahem datové sady s pomocí dotazovacího jazyka SPARQL
- Informace o veřejnosti registrovaného údaje je zachycena v jeho evidenci v RPP označením údaje jako veřejného údaje.
- Pro veřejný údaj obsahuje RPP v evidenci údaje IRI datové sady (nebo datových sad) v NKOD, v níž je obsah odpovídající údaji zpřístupněn prostřednictvím VDF a publikován jako otevřená data.
- Pro údaj kódovaný číselníkem obsahuje RPP v evidenci údaje IRI datové sady v NKOD, v níž je číselník zpřístupněn prostřednictvím VDF a publikován jako otevřená data.
Vlastní mechanismus zpřístupnění údajů do VDF přibližuje dále uvedený obrázek na několika příkladech údajů „agendy 1“. Čísla v kroužcích na obrázku označují jednotlivé příklady.
- V RPP je u agendy 1 evidováno, že údaje A i B jsou veřejné. To znamená, že jsou dostupné jako otevřená data prostřednictvím VDF a otevřeného přístupu.
- Oba údaje jsou dostupné prostřednictvím stejné datové sady.
- V RPP je v evidenci těchto údajů uvedeno IRI datové sady v NKOD (datová sada se jmenuje „Údaje A + B agendy 1“).
- Datová sada je publikovaná a dostupná v několika distribucích, katalogizační záznam obsahuje pro každou distribuci odkaz na její fyzické umístění (tj. její URL).
- V RPP je u agendy 1 evidováno, že údaj C je veřejný. Jedná se o stejnou situaci jako v příkladu 1, pouze s tím rozdílem, že údaj C je publikován v jiné samostatné datové sadě.
- Agenda 1 vytváří a udržuje číselník, který je dostupný ve VDF a je publikován jako otevřená data.
- V RPP je u agendy 1 evidováno, že údaj D je veřejný a je publikován v samostatné datové sadě. Jedná se o stejnou situaci jako v příkladu 1.
- V RPP je u agendy 1 evidováno, že údaj E je neveřejný a tudíž není možné jej zpřístupnit ve VDF. U údaje E je ale evidováno, že je kódován číselníkem (v tomto případě se pro demonstraci jedná o číselník spravovaný mimo agendu 1). Evidence údaje v RPP obsahuje IRI datové sady v NKOD, který obsahuje publikovaný číselník (stejně jako v příkladu 5).
- Reprezentuje přístup k distribucím datových sad prostřednictvím VDF.
Pravidla sdílení veřejných údajů prostřednictvím VDF
Pravidla publikace veřejných údajů do VDF
Základní prvky architektury VDF z pohledu poskytovatele údajů zobrazuje následující obrázek.
Poskytovatelem údajů do VDF je správce ISVS, ve kterém jsou vedeny registrované veřejné údaje. Tento ISVS je vyznačen na levé straně obrázku jako systém pro správu datového kmene, kterým OVM spravuje svůj datový kmen. V praxi se samozřejmě může jednat o více ISVS, zde si pro jednoduchost zobrazujeme jen jeden systém.
Pro potřeby sdílení údajů ve VDF poskytovatel údajů vytvoří systém pro zpřístupnění údajů prostřednictvím VDF. Může se jednat o samostatný systém nebo to může být modul v rámci existujícího systému. Zajišťuje získávání obsahu veřejných údajů z datového kmene poskytovatele, rozdělení do vhodných datových sad a převod do podoby definované otevřenými formálními normami a jeho dávkové předání do úložiště datových sad.
Úložiště datových sad zajišťuje kontrolu technické správnosti zaslaných dávek vůči otevřeným formálním normám a zpřístupnění distribucí obsahu ve všech formátech definovaných otevřenými formálními normami. Úložiště dále zajišťuje dostupnost distribucí čtenářům prostřednictvím ISGOD i prostřednictvím veřejného internetu. Dostupnost distribucí prostřednictvím ISGOD navíc garantuje. Úložiště datových sad pro ukládání obsahu datových sad z daného ISVS je vytvořeno pro daný ISVS právě jedno a spravuje jej správce ISVS. V případě, že se jedná o aktualizaci obsahu datové sady, oznamuje úložiště datových sad notifikačnímu hubu, že obsah datové sady byl změněn.
Poté, co jsou distribuce obsahu datových sad uloženy v úložišti a zpřístupněny, jsou datové sady katalogizovány v NKOD prostřednictvím systému pro zpřístupnění údajů. K tomu poskytuje systém pro zpřístupnění údajů API, které splňuje otevřenou formální normu rozhraní katalogů otevřených dat. Katalogizace datových sad v NKOD je tak automatizovaná.
Celý proces publikace údajů sdružených v jedné datové sadě do VDF je znázorněn na následujícím diagramu. Proces předpokládá, že příslušná agenda již byla ohlášena v RPP včetně všech jejích údajů v potřebné úrovni granularity.
V rámci procesu:
- Systém pro zpřístupnění údajů
- Připraví obsah datové sady v podobě datového souboru v jednom z formátů definovaných otevřenými formálními normami.
- Specifikaci otevřených formálních norem lze získat z repozitáře otevřených formálních norem.
- Pokud pro údaje neexistuje otevřená formální norma, musí ji správce systému pro zpřístupnění údajů s podporou MV ČR nejprve vytvořit.
- Zašle připravený obsah datové sady do úložiště datových sad.
- Úložiště datových sad
- Provede technickou kontrolu zaslaného obsahu
- Kontrola správného formátování (např. JSON nebo XML formátování)
- Kontrola validity datové struktury vůči datovým schématům definovaných otevřenými formálními normami (např. vůči JSON nebo XML schématům)
- V případě špatné syntaxe zašle zpět systému pro zpřístupnění údajů chybové hlášení a skončí.
- Vytvoří distribuce obsahu jeho transformací do všech podob definovaných otevřenými formálními normami s využití transformačních skriptů/procedur/mapování, které jsou součástí otevřených formálních norem.
- Zpřístupní vytvořené distribuce
- Zpřístupní je jako datové soubory dostupné ke stažení prostřednictvím ISGOD a z veřejného internetu.
- URL pro stažení datového souboru je stejné pro přístup prostřednictvím ISGOD a veřejného internetu, k čemuž je nutné správně nastavit DNS v prostředí KIVS/CMS a DNS v prostředí veřejného internetu.
- Volitelně zpřístupní jednotlivé položky obsahu dle otevřené formální normy pro propojená data tak, že má každá položka své referenční a lokální IRI dereferencovatelné prostřednictvím ISGOD a z veřejného internetu.
- Referenční IRI položky je stejné pro přístup prostřednictvím ISGOD a veřejného internetu, k čemuž je nutné správně nastavit DNS v prostředí KIVS/CMS a DNS v prostředí veřejného internetu.
- Lokální IRI položky je stejné pro přístup prostřednictvím ISGOD a veřejného internetu, k čemuž je nutné správně nastavit DNS v prostředí KIVS/CMS a DNS v prostředí veřejného internetu.
- Volitelně zpřístupní jejich obsah v podobě SPARQL endpointu prostřednictvím ISGOD a ve veřejném internetu.
- URL SPARQL endpointu je stejné pro přístup prostřednictvím ISGOD a veřejného internetu, k čemuž je nutné správně nastavit DNS v prostředí KIVS/CMS a DNS v prostředí veřejného internetu.
- Zašle zpět systému pro zpřístupnění údajů potvrzení o úspěšném uložení.
- Jako součást potvrzení zasílá metadata o vytvořených distribucích v podobě definované otevřenou formální normou pro rozhraní katalogů otevřených dat.
- Systém pro zpřístupnění údajů
- Vytvoří kompletní katalogizační záznam o datové sadě včetně metadat o distribucích vytvořených úložištěm datových sad a zpřístupní jej prostřednictvím API dle otevřené formální normy pro rozhraní katalogů otevřených dat.
- Zašle notifikačnímu hubu informaci o změně obsahu datové sady.
- Úroveň detailu informace není v tomto místě řešena.
- Národní katalog otevřených dat
- Získá katalogizační záznam z API poskytnutého systémem pro zpřístupnění údajů a zaeviduje jej.
- Ohlašovatel agendy
- Ohlásí do RPP jako součást ohlášení agendy referenční IRI datové sady (datových sad) v NKOD, ve které (kterých) je veřejný údaj zpřístupněn. Ohlášení provede poté, co NKOD datovou sadu na základě zaslaného katalogizačního záznamu zaeviduje (zpravidla do 1 dne).
- Notifikační hub
- Zaeviduje informaci o změně datové sady zaslanou úložištěm datových sad.
Systém pro zpřístupnění údajů prostřednictvím VDF souvisí s existujícím systémem pro zpřístupnění údajů prostřednictvím PPDF, který zajišťuje poskytování údajů o konkrétním subjektu práva, na který přistupuje čtenářský AIS prostřednictvím PPDF. Systém pro zpřístupnění údajů prostřednictvím VDF (dále jen systém pro zpřístupnění údajů) oproti tomu aktivně v pravidelných správcem ISVS definovaných intervalech exportuje obsah veřejných údajů do podoby datových sad a dávkově je předává do úložiště datových sad, ze kterého jsou jako otevřená data dostupné prostřednictvím VDF a otevřeného přístupu.
PPDF a VDF jsou tedy dva různé způsoby sdílení datového kmene agendy. Technická podoba dat určená pro sdílení prostřednictvím PPDF je definována v kontextech, tj. XSD schématech popisujících XML struktury, ve kterých je obsah datového kmene agendy sdílen prostřednictvím PPDF. Technická podoba dat určená pro sdílení prostřednictvím VDF je definována otevřenými formálními normami. Otevřené formální normy definují datová schémata. Nejedná se ale nutně jen o XSD schémata, ale také o JSON schémata, CSV schémata nebo ontologie pro popis RDF reprezentace. To z toho důvodu, že totožný obsah, který je dostupný prostřednictvím VDF je dostupný jako otevřená data, kde je nutno z důvodů interoperability a dodržení dobré praxe nabídnout obsah v různých standardních formátech.
Protože ale kontexty pro PPDF a datové struktury v OFN pro VDF jsou dvěma syntaktickými stranami téže sémantické mince (tj. jsou různými syntaktickými reprezentacemi stejné sémantiky), je nutno tuto sémantiku strukturovaně a explicitně vyjádřit. K tomu jsou využívány techniky ontologického konceptuálního modelování, kdy je sémantika všech údajů v dané agendě popsána na konceptuální úrovni v podobě ontologie podle vyhlášky, která nahradí současnou vyhlášku č. 529. Pro tvorbu konceptuálních modelů v podobě ontologie MV ČR spravuje a provozuje sadu volně dostupných modelovacích nástrojů. Ty umožňují také z konceptuálních modelů definice kontextů pro PPDF a datových struktur v OFN pro VDF automatizovaně generovat a zajišťovat tak jejich vzájemnou sémantickou interoperabilitu. Konceptuální model agendy by navíc měl být tvořen konzistentně s modely ostatních agend, a modely agend by měly vycházet ze společné ontologie veřejné správy a ze slovníků definovaných EU (tzv. ISA Core Vocabularies), což podporuje sémantickou interoperabilitu vyměňovaných údajů napříč agendami i v rámci EU.
Čtení veřejných údajů z VDF
Základní stavební kameny architektury VDF z pohledu čtenáře údajů zobrazuje následující obrázek.
Čtenářem údajů z VDF je správce ISVS, který čte veřejné údaje. Tento ISVS je v obecné úrovni vyznačen na levé straně obrázku jako systém pro čtení údajů z VDF (dále jen systém pro čtení údajů).
Systém pro čtení údajů čte veřejné údaje z VDF jako otevřená data prostřednictvím ISGOD v podobě distribucí datových sad v různých formátech definovaných otevřenými formálními normami. Jsou umožněny 3 základní druhy přístupu prostřednictvím ISGOD:
- Přístup ke kompletnímu obsahu datové sady v podobě datových souborů voláním
- služeb ISGOD umožňujících přistoupit k metadatům o datové sadě a jejích distribucích na základě jejich referenčních IRI a k URL daného souboru a stáhnout jej. (povinné)
- Přístup k jednotlivým položkám datových sad voláním služeb ISGOD umožňujících přistoupit k datům o dané položce na základě jejího referenčního IRI. (volitelné)
- Dotazování nad položkami datových sad voláním dotazovacích služeb ISGOD. (volitelné)
Služby ISGOD jsou realizovány jako webové služby postavené na principech REST, které jsou poskytovány jednotlivými komponentami VDF znázorněnými v pravé části obrázku:
- REST služby NKOD umožňují číst metadata o datových sadách a jejich distribucích.
- REST služby úložiště datových sad umožňují číst obsah v nich uložených datových sad v podobě
- stahování datových souborů s obsahem uložených datových sad (povinné)
- přístupu k IRI jednotlivých položek obsahu uložených datových sad (volitelné)
- SPARQL dotazů nad obsahem uložených datových sad (volitelné)
ISGOD je pouhým logickým zastřešením výše uvedených služeb.
Čtení obsahu datové sady v podobě datového souboru
Čtení obsahu datové sady v podobě datového souboru typicky systém pro čtení údajů provádí za účelem aktualizace vlastní kopie údajů přebíraných z VDF. Aktualizaci typicky provádí v pravidelných intervalech nebo na základě notifikací o změnách zasílaných notifikačním hubem na základě registrace v katalogu uživatelů, ale mimo svůj run-time. Dávkový přístup ke kompletnímu obsahu datové sady v podobě datového souboru předpokládá, že systém pro čtení údajů zná referenční IRI datové sady. Referenční IRI datové sady je možné zjistit z evidence agendových údajů v RPP nebo vyhledáváním v NKOD. Přístup je pak realizován následujícím postupem:
- Systém pro čtení údajů přistupuje k referenčnímu IRI datové sady.
- Směrovací služba přesměrovává referenční IRI datové sady na lokální IRI datové sady v NKOD.
- Systém pro čtení údajů přistupuje k lokálnímu IRI datové sady v NKOD.
- NKOD vrací metadata o datové sadě.
- Systém pro čtení údajů vybírá distribuci datové sady dle potřebného formátu a přistupuje k URL ke stažení obsahu distribuce.
- Úložiště datových sad zasílá systému pro čtení údajů obsah datového souboru na daném URL.
Následující obrázek postup znázorňuje v podobě sekvenčního UML diagramu na konkrétním příkladu přístupu k datové sadě “Služby veřejné správy”, která je publikována z RPP.
Čtení položky datové sady
Čtení položky datové sady typicky systém pro čtení údajů provádí za účelem zobrazení veřejných údajů o položce v uživatelském rozhraní nebo jiné práce s konkrétní položkou v okamžiku potřeby práce s údaji o položce, tj. v rámci svého run-time. Přístup k položce předpokládá, že systém pro čtení údajů zná referenční IRI položky. Referenční IRI položky je možné získat následujícími způsoby:
- V předchozích krocích byl přečten z VDF údaj s referenčním IRI jako hodnotou.
- V předchozích krocích byl přečten z PPDF údaj s proprietárním identifikátorem entity jako hodnotou (tj. identifikátor v podobě řetězce, který identifikuje entitu lokálně v rámci ISVS). Referenční IRI položky s veřejnými údaji o entitě získá systém pro čtení údajů voláním směrovací služby s kódem údaje (evidovaným v RPP) a proprietárním identifikátorem.
Přístup je pak realizován následujícím postupem:
- Systém pro čtení údajů přistupuje k referenčnímu IRI položky.
- Směrovací služba přesměrovává referenční IRI položky na lokální IRI položky v konkrétním úložišti datových sad, kde jsou údaje o položce uloženy.
- Systém pro čtení údajů přistupuje k lokálnímu IRI položky na daném úložišti datových sad.
- Úložiště datových sad vrací veřejné údaje o položce.
- Systém pro čtení údajů zobrazuje nebo jinak zpracovává získané údaje.
Následující obrázek postup znázorňuje v podobě sekvenčního UML diagramu na konkrétním příkladu přístupu k veřejným údajům o službě evidované v RPP s proprietárním identifikátorem S10751 a s názvem “Pěstitelské pálení”. Jedná se o položku datové sady “Služby veřejné správy”, která je publikována z RPP. Postup zahrnuje i získání referenčního identifikátoru položky z proprietárního identifikátoru na začátku procesu. Systému pro čtení údajů je známo pouze id “S10751” pro údaj agendy 104 s kódem “104-1-11”. Zkonstruuje IRI identifikující položku a přistoupí na něj. Toto IRI vede na směrovací službu, která provede přesměrování na referenční IRI položky.
Pravidla sdílení veřejných číselníků prostřednictvím VDF
Speciálním případem sdílení veřejných údajů prostřednictvím VDF je pak sdílení veřejných číselníků. Vychází z architektury sdílení veřejných údajů popsané v předchozí kapitole. Má však svá specifika, která jsou popsána zde.
Pravidla publikace veřejných číselníků do VDF
Architektura pro publikaci veřejných číselníků do VDF je vystavěna na bázi architektury pro publikaci veřejných údajů do VDF. Aby byl veřejný číselník publikován do VDF, musí být podle § 51 odst. 8 ZoZR zaveden do RPP. Zavedení je provedeno prostřednictvím AIS působnostní a provede jej buď ohlašovatel agendy nebo ČSÚ (dále dohromady jen poskytovatel číselníku). ČSÚ zavádí do RPP veřejné číselníky nezávisle na agendách. Ohlašovatel agendy zavádí veřejný číselník jen v případě, že je agendový údaj kódován číselníkem, který ještě není v RPP nikým zaveden.
Všechny veřejné číselníky jsou tedy jako referenční údaje evidovány v RPP prostřednictvím AIS působnostní a z něj jsou také publikovány do VDF. Z AIS působnostní jsou také publikovány do VDF všechny ostatní veřejné údaje evidované v RPP v podobě datových sad. Z pohledu architektury pro publikaci veřejných údajů do VDF je tedy pro potřeby všech veřejných číselníků AIS působnostní systémem pro správu datového kmene a zároveň má jako svoji komponentu systém pro zpřístupnění údajů prostřednictvím VDF, který zajišťuje publikaci obsahu veřejných číselníků do VDF. Pro ukládání obsahu veřejných číselníků a také obsahu veřejných údajů vedených v RPP je využito stávající úložiště, na kterém je uložen obsah RPP publikovaný jako otevřená data. AIS působnostní zajišťuje také API poskytující katalogizační záznamy o jednotlivých datových sadách s veřejnými číselníky a s obsahem údajů vedených v RPP.
K realizaci výše popsané architektury publikace veřejných číselníků do VDF a jako otevřená data je nutno zajistit následující rozšíření informačního systém AIS působnostní a RPP:
- označování veřejnosti a neveřejnosti údaje
- včetně odkazů na legislativu v případě neveřejnosti údaje
- včetně IRI datových sad v NKOD, prostřednictvím kterých je veřejný údaj publikován
- evidenci veřejných číselníků
- pro každý veřejný číselník existuje 1..- verzí, které chápeme jako jednotlivé datové sady
- všechny datové sady reprezentující jednotlivé verze číselníku jsou seskupeny do zastřešující datové sady
- pro zastřešující datovou sadu a jednotlivé verze jsou evidována metadata datové sady dle otevřené formální normy pro rozhraní katalogů otevřených dat
-
- kterým je u číselníků vždy MV ČR, nikoliv poskytovatel číselníku
- pro zastřešující datovou sadu je navíc evidováno
-
- což není poskytovatel datové sady s číselníkem do VDF, kterým je v případě veřejných číselníků vždy MV ČR, viz předchozí bod
-
- pro verzi číselníku je navíc evidováno
- lokální proprietární identifikátor či kód číselníku
- potřebné pro konstrukci lokálních IRI číselníků a jejich položek
- může vyplnit poskytovatel číselníku nebo je vygenerováno automaticky, pokud poskytovatel číselníků vlastní identifikátor či kód číselníku neeviduje
-
- pro datové sady reprezentující jednotlivé verze číselníku jsou navíc evidovány následující vazby, které nejsou evidovány pro zastřešující datovou sadu:
- Je verzí (reference na zastřešující datovou sadu)
- Má předchozí verzi (reference na datovou sadu s předchozí verzí číselníku, existuje-li)
- zavedení nového veřejného číselníku poskytovatelem číselníku
- poskytovatel číselníku specifikuje metadata pro zastřešující datovou sadu číselníku
- lze převzít nebo jinak použít existující formulář pro registraci datové sady
- poskytovatel číselníku specifikuje metadata pro datovou sadu s první verzí číselníku
- může zvolit možnost kopírovat hodnoty zadané pro zastředující datovou sadu
- poskytovatel číselníku předá obsah první verze číselníku ručně v uživatelském rozhraní nahráním připraveného souboru s obsahem první verze veřejného číselníku v podobě definované otevřenou formální normou
- předchozí tři body lze realizovat také automatizovaně načtením seznamu veřejných číselníků poskytovatele z URL, které zadá
- seznam musí být zpřístupněn dle otevřené formální normy pro rozhraní katalogů otevřených dat.
- veřejné číselníky ale nemusí být pro účely předání zpřístupněny jejich správcem jako otevřená data.
- předaný obsah je zvalidován vůči otevřené formální normě pro číselníky
- obsah je uložen v podobě zkontrolovaného předaného datového souboru
- obsah veřejného číselníku pouze eviduje, ale nejsou nad ním stavěny žádné aplikační funkce
- zavedení nové verze již zavedeného veřejného číselníku poskytovatelem číselníku
- stejný postup jako při zavádění nového veřejného číselníku, ale je zavedena pouze další verze číselníku zařazená pod zastřešující datovou sadu
- původní verze zůstává evidována včetně její publikace do VDF a jako otevřená data
- funkcionality systému pro zpřístupnění údajů prostřednictvím VDF
- veřejné číselníky již jsou evidovány v podobě souborů s jejich jednotlivými verzemi v podobě definované otevřenými formálními normami, čili je nutno pouze zajistit jejich předání do úložiště veřejných číselníků a datových sad RPP
-
- jako doposud bude zpřístupňovat obsah RPP jako datové sady dle příslušných otevřených formálních norem ve formátech JSON, JSON-LD a prostřednictvím SPARQL endpointu
- zajistí také publikaci distribucí datových sad s verzemi veřejných číselníků evidovaných v RPP dle otevřené formální normy pro číselníky (formáty XML, CSV, JSON-LD a SPARQL endpoint)
- jelikož se jedná pouze o komponentu v rámci AIS působnostní, resp. RPP, není nutné zajišťovat všechny funkcionality přesně podle obecné architektury publikace veřejných údajů do VDF
- je nutné zajistit dostupnost nejen z veřejného internetu jako doposud, ale také prostřednictvím ISGOD (referenční rozhraní) a garantovat dostupnost
- funkcionality lokálního katalogu otevřených dat pro katalogizaci datových sad publikovaných v úložišti veřejných číselníků a datových sad RPP
- zpřístupňuje do NKOD katalogizační záznam pro každou datovou sadu:
- datové sady zastřešující verze číselníků a datové sady s verzemi číselníků
- metadata o datových sadách jsou získány od poskytovatele
- metadata o distribucích jsou doplněny automatizovaně na základě vytvářených distribucí v úložišti
- datové sady s obsahem dalších veřejných údajů evidovaných v RPP (tj. ty, které jsou již dnes publikovány jako otevřená data)
- metadata jsou fixně předvyplněna
- je registrován pod MV ČR
- označování údaje jako údaje kódovaného verzí veřejného číselníku
- včetně zaznamenávání IRI datové sady s touto verzí veřejného číselníku z NKOD
- Aby mohlo být IRI zaznamenáno, musí být daná verze veřejného číselníku nejprve do RPP zavedena, publikována do VDF a katalogizována v NKOD.
- evidence veřejných údajů využívaných ohlášenou agendou
Kromě nových verzí veřejného číselníku existuje možnost, že je číselník kompletně nahrazen zcela novým číselníkem. V tom případě je skutečně zaveden jako zcela nový číselník bez vazby na původní číselník. Původní číselník ale zůstává evidován.
Číselníky kódující údaje evidované v RPP již nebudou publikovány jako otevřená data stávajícím mechanismem. Stanou se veřejnými číselníky, tj. budou evidovány v AIS působnostní a budou z něj publikovány do VDF a jako otevřená data standardním výše popsaným způsobem.
Pravidla čtení veřejných číselníků z VDF
Čtení veřejných číselníků včetně jejich obsahu jako celku v podobě datových souborů ke stažení (VDF), přístupu k jednotlivým položkám datových sad s verzemi číselníků (VDF a otevřená data) a dotazování prostřednictvím SPARQL endpointu (otevřená data) probíhá v rámci architektury pro čtení veřejných údajů popsané výše. Veřejné číselníky jsou dostupné dle otevřené formální normy pro číselníky.
Technická pravidla pro aplikační komponenty veřejného datového fondu
Úložiště datových sad
Úložiště datových sad je složeno ze 3 modulů:
- souborové úložiště distribucí datových sad
- ukládá distribuce v podobě datových souborů
- zpřístupňuje datové soubory distribucí prostřednictvím VDF a veřejného internetu
- každý datový soubor je dostupný na jednom URL, které je stejné pro VDF i veřejný internet
- nutno správně nastavit DNS pro KIVS/CMS a DNS pro veřejný internet
- modul pro validaci a transformaci distribucí dle příslušných otevřených formálních norem
- kontroluje správné formátování a validitu
- provádí transformace mezi jednotlivými formáty s využitím definic transformací v otevřených formálních normách
- ukládá výsledky transformací do souborového úložiště a v případě RDF distribucí také do triplestore
- bez definované otevřené formální normy pro daný typ dat není možné údaje prostřednictvím VDF zpřístupňovat
- příslušnou otevřenou formální normu nebo normy získává modul z repozitáře otevřených formálních norem
- triplestore pro ukládání RDF distribucí
- ukládá RDF distribuce datové sady dle otevřených formálních norem v triplestore (triplestore = databázový systém pro ukládání RDF dat v podobě trojic)
- zpřístupňuje SPARQL endpoint pro dotazování nad RDF reprezentací a HTTP dereferenci IRI položek prostřednictvím rozhraní pro čtení distribucí jako otevřená data
- lokální IRI položky je stejné pro VDF i veřejný internet, URL SPARQL endpointu stejné pro VDF i veřejný internet
- nutno správně nastavit DNS pro KIVS/CMS a DNS pro veřejný internet
Směrovací služba pro veřejné číselníky a jejich položky
Jak bylo popsáno výše veřejný číselník bude podle otevřené formální normy pro číselníky zpřístupněn jako datový soubor ke stažení a prostřednictvím dereference IRI jednotlivých položek. Je tedy nutno určit tvar referenčních a lokálních IRI položek veřejných číselníků a také samotných číselníků. Ta jsou určena dle pravidel pro tvorbu IRI následovně:
- Referenční IRI číselníku:
https://vdf.gov.cz/číselníky-vdf/zdroj/číselníky/<ID číselníku v RPP>
- Referenční IRI verze číselníku k DDDD-MM-YY
https://vdf.gov.cz/číselníky-vdf/zdroj/číselníky/<ID číselníku v RPP>/<DDDD-MM-YY>
- Lokální IRI číselníku:
https://rpp-opendata.egon.gov.cz/odrpp/zdroj/číselníky/<ID číselníku v RPP>
- Lokální IRI verze číselníku:
https://rpp-opendata.egon.gov.cz/odrpp/zdroj/číselníky/<ID číselníku v RPP>/<DDDD-MM-YY>
- Referenční IRI položky číselníku:
<referenční IRI číselníku>/položky/<lokální kód položky>
- Lokální IRI položky číselníku:
<lokální IRI číselníku>/položky/<lokální kód položky>
Kde
- <ID číselníku v RPP> značí neměnné veřejné ID identifikující číselník v RPP
- <DDDD-MM-YY> značí datum vydání verze číselníku
- <lokální kód položky> značí kód položky číselníku v rámci daného číselníku
Pro potřeby sdílení veřejných číselníků je ve směrovací službě směrování výše uvedených referenčních IRI na lokální IRI přednastaveno a není potřeba, aby správce RPP nebo poskytovatelé jednotlivých číselníků směrování konfigurovali.
Dále je potřeba ve směrovací službě nastavit směrování na referenční IRI pro případy, kdy je znám pouze <lokální kód položky> a RPP identifikátor agendového údaje, jehož je hodnotou. Konfiguraci tohoto směrování provádí RPP. Kdykoliv ohlašovatel agendy uvede pro daný agendový údaj veřejný číselník, má RPP evidováno, kdo je poskytovatelem číselníku. Do směrovací služby tedy zaeviduje pravidlo pro směrování dvojice
(<RPP identifikátor agendového údaje>, <lokální kód položky>)
na referenční IRI
https://vdf.gov.cz/číselníky-vdf/zdroj/číselníky/<ID číselníku v RPP>/položky/<lokální kód položky>
Příloha 1: Metodika poskytování a čerpání údajů prostřednictvím VDF
- Postupy zpřístupňování údajů prostřednictvím VDF
- Určení údajů poskytovaných do VDF
- Návrh podoby datových sad a jejich distribucí
- Příprava informačního systému pro export dat
- Export údajů do distribucí datových sad
- Publikace distribucí datových sad
- Aktualizace údajů, archivace a notifikace
- Katalogizace datové sady
- Registrace lokálního katalogu
- Postupy čerpání údajů prostřednictvím VDF
- Vyhledávání datových sad s údaji
- Import údajů z datových sad do informačního systému
- Příjem notifikací o změnách v datových sadách
Přístupy se liší nejen v tom, jaké údaje zpřístupňují a komu je zpřístupňují, ale také v několika dalších aspektech shrnutých v následující tabulce.
Příloha 2: Srovnání vlastností jednotlivých způsobů přístupu
Přístup k PPDF | Řízený přístup | Přístup k VDF | Otevřený přístup | |
úroveň garance kvality obsahu | správnost, úplnost, platnost a aktuálnost | správnost, úplnost, platnost a aktuálnost | správnost, úplnost, platnost a aktuálnost | správnost, úplnost, pravidelné aktualizace pro zajištění maximální možné platnosti a aktuálnosti |
úroveň garance zpřístupněných údajů pro výkon agend veřejné správy | vysoká dostupnost, formální správnost | bez garance pro výkon agend | vysoká dostupnost, formální správnost | bez garance pro výkon agend |
sjednocený popis zpřístupněných údajů | RPP | bez popisu3) | RPP | bez popisu |
centrální popis způsobu zpřístupnění údajů | TSÚA | NKOD | NKOD | NKOD |
podoba definice datových formátů pro zpřístupnění | TSÚA | OFN | OFN | OFN |
systém pro správu oprávnění | RPP | KUD | přístup bez omezení | přístup bez omezení |
systém pro vedení evidence přístupu k údajům | RPP | KUD | KUD | bez evidence |
identifikace subjektů a objektů práva | IČ a AIFO pro subjekty, proprietární id pro objekty | IRI | IRI | IRI |
Infrastruktura (infrastrukturní a technologická vrstva)
Komunikační infrastruktura veřejné správy
Popis Komunikační infrastruktury veřejné správy
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. Skládá ze ze 2 hlavních složek, jednak Centrálního místa služeb (CMS) a následně sítí, které jsou s ním propojeny (KIVS). Pro účely tohoto popisu se bere CMS/KIVS jako jeden celek, tedy samostatná a oddělená infrastruktura sloužící pro síťové a bezpečné propojení eGovernmentu.
KIVS jako samostatný pojem je také používán jako specifická možnost připojení do CMS. Při používání CMS/KIVS se myslí celek, který obsahuje obecně jakýkoliv způsob připojení, viz dále.
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.
OVS přistupuje ke službám CMS pomocí portálu CMS na adrese https://www.cms2.cz/. Adresa portálu je dostupná pouze z vnitřní sítě KIVS/CMS, tedy až poté, kdy je OVS připojeno jednou z možných variant níže. Pokud se na adresu přistupuje mimo vnitřní síť KIVS/CMS, dostane se uživatel pouze na stránku MVČR.
OVS a SPUÚ se připojují ke službám CMS výhradně jedním ze čtyř možných způsobů:
- Prostřednictvím Krajských sítí (aktuálně v krajích Vysočina, Plzeňském, Karlovarském, Zlínském a částečně Pardubickém + další budou-li vybudovány).
- Prostřednictvím metropolitních sítí připojených např. na Integrovanou telekomunikační sít (ITS) MVČR.
- Prostřednictvím Komunikační infrastruktury veřejné správy (KIVS) s využitím komerčních nabídek soutěžených prostřednictvím Ministerstva vnitra.
- Prostřednictvím veřejného internetu, a to přes zabezpečený tunel VPN SSL nebo VPN IPSec.
OVS čerpají služby eGovernmentu, jako např. propojený datový fond, výhradně přes CMS. Pro čerpání služeb z CMS jsou pro OVS, s výjimkou obcí I. typu, přípustné pouze varianty 1 až 3 výše. Komunikace mezi jednotlivými OVS je 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.
Obce I. typu mají povolený způsob čerpání služeb CMS, a tedy i publikovaných služeb eGovernmentu (jako například CzechPOINT, služby základních registrů, atd.), prostřednictvím veřejného internetu, pokud jsou tyto služby publikovány do veřejného internetu s využitím služeb CMS.
Pokud chce úřad využít KIVS, tj. soutěž přes centrálního zadavatele Ministerstvo vnitra, je nutné definovat požadavky dle katalogových listů a následně zrealizovat nákup v dynamickém nákupním systému. Služby CMS lze čerpat také prostřednictvím Národních datových center.
Pohled na CMS/KIVS
Pravidla Komunikační infrastruktury veřejné správy
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
OVS přistupuje ke službám CMS pomocí portálu CMS na adrese https://www.cms2.cz/. Adresa portálu je dostupná pouze z vnitřní sítě KIVS/ CMS, tedy až poté, kdy je OVS připojeno jednou z možných variant níže. Pokud se na adresu přistupuje mimo vnitřní síť KIVS/CMS, dostane se uživatel pouze na stránku MVČR. 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/KIVS 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.
OVS a SPUÚ se připojují ke službám CMS výhradně jedním ze čtyř možných způsobů:
- Prostřednictvím Krajských sítí (aktuálně v krajích Vysočina, Plzeňském, Karlovarském, Zlínském a částečně Pardubickém + další budou-li vybudovány).
- Prostřednictvím metropolitních sítí připojených např. na Integrovanou telekomunikační sít (ITS) MVČR.
- Prostřednictvím Komunikační infrastruktury veřejné správy (KIVS) s využitím komerčních nabídek soutěžených prostřednictvím Ministerstva vnitra.
- Prostřednictvím veřejného internetu, a to přes zabezpečený tunel VPN SSL nebo VPN IPSec.
OVS čerpají služby eGovernmentu, jako např. propojený datový fond, výhradně přes CMS. Pro čerpání služeb z CMS jsou pro OVS, s výjimkou obcí I. typu, přípustné pouze varianty 1 až 3 výše. Komunikace mezi jednotlivými OVS je 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.
Obce I. typu mají povolený způsob čerpání služeb CMS, a tedy i publikovaných služeb eGovernmentu (jako například CzechPOINT, služby základních registrů, atd.), prostřednictvím veřejného internetu, pokud jsou tyto služby publikovány do veřejného internetu s využitím služeb CMS.
Pokud chce úřad využít KIVS, tj. soutěž přes centrálního zadavatele Ministerstvo vnitra, je nutné definovat požadavky dle katalogových listů a následně zrealizovat nákup v dynamickém nákupním systému. Služby CMS lze čerpat také prostřednictvím Národních datových center.
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:
- 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í.
- 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.
- 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)4) 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-1 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.
eGovernment Cloud
Popis eGovernment cloudu
Základním cílem projektu eGovernment Cloud (dále také jako "eGC"), je zvýšení efektivity, rozsahu poskytovaných služeb, kvality a bezpečnosti a zároveň snížení nákladů provozu informačních systémů a aplikací veřejné správy, a to využíváním sdílených ICT služeb na úrovni infrastruktury, výpočetních platforem a standardizovatelných aplikací. Tím dochází k naplnění strategie 3E při současném zvýšení kvality a bezpečnosti při pořizování a provozu informačních systémů veřejné správy využíváním sdílených cloudových služeb eGC. Dalším cílem projektu eGC je v maximální míře usnadnit jednotlivým správcům ISVS architektonické, bezpečnostní, nákupní a projektové procesy využíváním služeb eGC.
Informační koncepce ČR zohledňuje základní cíle a koncepty eGC, stanovené usnesením Vlády ČR ve Strategickém rámci Národního cloud computingu (UV 1050/2016) a rozpracovávané v rámci projektu Příprava vybudování eGovernment cloudu, jehož výstupy byly schváleny v listopadu 2018 vládou ČR (UV 749/2018).
Služby eGC zahrnují tři hlavní kategorie cloudových služeb: IaaS (Infrastructure as a Service – služby na úrovni datových center, sítí a HW), PaaS (Platform as a Service – služby na úrovni standardních SW platforem, jako jsou databáze, webové servery) a SaaS (Software as a Service – kompletní funkcionalita standardních nebo standardizovatelných aplikací poskytovaná jako služba, např. e-mail, ekonomický systém, spisová služba apod.).
Služby eGC jsou poskytovány komerční částí eGC (KeGC - služby provozované komerčními subjekty s využitím jejich vlastních datových center a komunikační infrastruktury) a státní částí (SeGC – služby provozované v datových centrech a na HW a SW platformách v majetku státu a provozované organizacemi řízenými státem – poskytovatelem státního cloud computingu).
Součástí vybudování eGC je i konsolidace datových center a HW platforem, čímž se rozumí postupný přesun provozu většiny informačních systémů a aplikací veřejné správy z datových center jednotlivých institucí do vybraných datových center státu (státní část eGC), resp. do datových center ověřených komerčních subjektů (komerční část eGC). Konsolidovaná infrastruktura a HW/SW platformy budou poskytovány formou IaaS a PaaS služeb eGC. Vybudování těchto služeb zahrnuje mj.:
- definici minimálních standardů pro poskytování IaaS a PaaS služeb pro státní a komerční část eGC,
- sjednocení provozního prostředí informačních systémů a aplikací provozovaných ve státní části eGC na několik vybraných platforem,
- zajištění potřebné bezpečnosti, spolehlivosti, škálovatelnosti a jednotnosti provozu ICT služeb.
Součástí vybudování eGC je dále postupná definice standardů pro vybrané softwarové aplikace podporující stejnou agendu či podpůrný a administrativní proces. Standardizované aplikační služby budou poskytovány formou SaaS služeb eGC. Využití standardizovaných aplikací přispěje ke standardizaci pracovních postupů (byznys procesů) ve veřejné správě.
Vybudování eGC umožní organizacím veřejné správy, aby se více soustředily na svoje klíčové procesy místo podpůrných procesů typu zajištění provozu informačních systémů a aplikací. Organizace však musí i nadále být schopny definovat svoje požadavky na ICT služby a integrovat je do svých klíčových procesů.
Jedním ze základních pravidel pro využití služeb SeGC nebo KeGC je zajištění požadované úrovně bezpečnosti eGC služeb v závislost na bezpečnostní úrovni informačního systému veřejné správy, pro který jsou služby eGC využívány. Tato bezpečnostní úroveň se odvozuje od bezpečnostních dopadů daného IS. Zařazení poptávaného cloud computingu do bezpečnostní úrovně provádí orgán veřejné moci podle vyhlášky č. 315/2021 Sb., o bezpečnostních úrovních pro využívání cloud computingu orgány veřejné moci. SeGC zajistí nejvyšší kritickou úroveň bezpečnosti a je určen pro provoz služeb eGC nejvyšší bezpečnostní úrovně (automaticky to jsou informační nebo komunikační systémy, které jsou kritickou informační infrastrukturou podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti). KeGC je určen pro provoz služeb eGC ostatních bezpečnostních úrovní a v maximální míře umožňuje využití tržních mechanismů pro zajištění optimálních cen.
U moderně navržených ISVS pro provoz v cloudu lze provést dekomponování, což vede ke zvýšení efektivnosti využívání prostředků při vývoji a provozování těchto informačních systémů. Dekompozice zároveň umožňuje hybridní provoz s využitím služeb cloud computingu různé bezpečnostní úrovně (dále jen „BÚ“).
Druhým rozhodujícím kritériem pro využití služeb eGC je kalkulace a porovnání nákladů vlastnictví (TCO) jednotlivých IS v modelu provozu on-premise (na vlastní infrastruktuře) a s využitím služeb eGC. Ke stanovení ekonomické náročnosti je dostupný Kalkulátor nákladů ISVS provozovaného v cloud; včetně uživatelské příručky.
Každý úřad si také musí být vědom toho, že financování cloudových služeb se liší od provozu vlastního řešení. Při provozu a nákupu vlastních technologií jde o tzv. CAPEX, tedy kapitálové výdaje, a pořízené věci zůstávají v majetku úřadu. Naopak nákup cloudových služeb je tzv. OPEX, tedy provozní výdaje, kdy úřadu v majetku nic nezůstává a platí si pouze službu. S tímto odlišným způsobem financování je třeba počítat při tvorbě rozpočtu a jeho čerpání, protože při využívání cloudových služeb pro celou infrastrukturu úřadu se razantně zvýší provozní výdaje a sníží investiční.
Oblast cloud computingu je od 1. 8. 2020 regulována příslušnými ustanoveními zákona č. 365/2000 Sb., o informačních systémech veřejné správy, kde v Hlavě VI zákona je zaveden mechanismus zápisu poptávek a nabídek cloud computingu do katalogu cloud computingu a zavedena povinnost orgánů veřejné správy využívat pouze takový cloud computing, který byl na základě splnění podmínek uvedených v zákoně zapsán Digitální a informační agenturou do katalogu cloud computingu.
Na webových stránkách Digitální a informační agentury je dostupný Metodický návod pro zápis poptávky a nabídky cloud computingu do katalogu cloud computingu.
Poskytovatelé služeb eGC musí splňovat zákonem určené podmínky, které zahrnují zejména oblast bezpečnosti poskytovaných služeb a jejich provozních parametrů, ale také důvěryhodnosti poskytovatele. Splnění podmínek ověřuje Digitální a informační agentura ve spolupráci s Národním úřadem pro kybernetickou a informační bezpečnost a dalšími složkami státu. Požadavky, které musí splnit poskytovatel cloud computingu, aby byla jeho nabídka zapsána do katalogu cloud computingu, stanovuje vyhláška č. 316/2021 Sb., o některých požadavcích pro zápis do katalogu cloud computingu.
Rozsah údajů vedených v katalogu cloud computingu o poptávkách, nabídkách a využívaném cloud computingu specifikuje vyhláška č. 433/2020 Sb., o údajích vedených v katalogu cloud computingu.
Řídící orgán eGovernment Cloudu (také jako ŘOeGC) koordinuje budování a rozvoj eGC, rozvíjí a udržuje metodické postupy pro eGC, kontroluje a řídí soutěžní mechanismus KeGC a nabídku služeb SeGC.
V současné době je umísťování IS orgánů veřejné správy do eGC (využívání služeb eGC) zcela dobrovolné, přičemž se uplatňuje princip mandatory-compare. Podle § 5 odst. 2 písm. j) a k) zákona č. 365/2000 Sb., o informačních systémech veřejné správy, resp. vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy mají orgány veřejné správy povinnost zajistit si ekonomické zhodnocení výhodnosti provozu ISVS. Orgán veřejné správy musí provést kalkulaci TCO, takže umístění on-premise pro nově pořizované systémy nebo v rámci technického zhodnocení anebo rozvoje spravovaného informačního systému veřejné správy bude nadále možné pouze tehdy, pokud kalkulace TCO neprokáže, že je nákladově efektivnější než umístění do eGC.
Bezpečnostní pravidla pro orgány veřejné správy, která musí nastavit, pokud využívá cloud computingu jsou dána vyhláškou č. 190/2023 Sb., o bezpečnostních pravidlech pro orgány veřejné moci využívající služby poskytovatelů cloud computingu.
Co je a co není cloud dle zákona
Upřesnění definice služeb třídy SaaS aneb jaká aplikační řešení, která orgány veřejné správy využívají/poptávají, lze považovat za cloud computing ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy?
Aplikační řešení, která jsou cloud computing třídy SaaS ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy , musí splňovat současně tyto podmínky:
- slouží více správcům ISVS (orgány veřejné správy (dále jen „OVS“) v roli tenantů), kteří jej využívají k provozu vlastních ISVS, nebo jiným zákazníkům (mimo OVS) a zároveň
- jsou provozovány na sdílené platformě cloud computingu třídy IaaS, příp. PaaS
Podmínka 2) může být splněna jedním ze dvou způsobů:
- SaaS je provozován na službách IaaS/PaaS samostatně zapsaných do katalogu CC tímto nebo jiným poskytovatelem CC,
- SaaS je provozován na službách IaaS/PaaS téhož poskytovatele CC, který nabízí SaaS, ale služby IaaS/PaaS využívá pouze pro provoz daného SaaS. V tomto případě služby IaaS/PaaS se do katalogu CC samostatně nezapisují. Existence a účinnost bezpečnostních opatření, která jsou zajišťována jednotlivými vrstvami provozní infrastruktury a která jsou vyžadována pro službu SaaS v dané bezpečnostní úrovni, se ověřují na základě „Podkladů pro ověření SaaS“, které ve své žádosti o zápis služby do katalogu CC uvedl poskytovatel SaaS.
Tyto služby typu SaaS mohou být využívány pouze v souladu s Hlavou VI ZoISVS a mj. musí být celý „stack“ IaaS/PaaS/SaaS zapsán v Katalogu CC. Zároveň musí být zapsáni všichni poskytovatelé CC (ať už materiální poskytovatelé, distributoři nebo koncoví poskytovatelé).
Aplikační řešení, která nejsou CC ve smyslu ZoISVS (a nepovažujeme je za CC třídy SaaS), jsou taková, která
- slouží více správcům ISVS (OVS), ale jsou pro každého správce provozovány na nesdílené (dedikované) výpočetní infrastruktuře;
- slouží pouze pro jednoho správce ISVS (OVS), přičemž může jít o aplikaci umožňující vzdálený přístup přes Internet nebo přes vnitřní síť CMS/KIVS pro mnoho externích uživatelů (např. aplikace pro podání přihlášky na střední školu, nebo aplikace využívané jednotlivými uživateli z řad OVS/OVM, avšak s centrální správou uživatelských účtů a báze dat ze strany toho jednoho správce ISVS), i když je provozována na platformě CC třídy IaaS, příp. PaaS (tato platforma však podléhá povinnosti zápisu do katalogu CC).
Upozorňujeme, že je nutné vždy uvažovat o ISVS v rozsahu ZoISVS, tzn. ve vymezení uvedeném v § 1 ZoISVS (zejména s ohledem na výjimky v odst. (2), (3) a (4) § 1 ZoISVS).
Katalog cloud computingu
Katalog cloud computingu dle zákona o informačních systémech veřejné správy naleznete na webu Digitální a informační agentury.
Nástroj pro vyhledávání v katalogu cloud computingu naleznete přímo zde nebo na této stránce níže. Jedná se o vyhledávací nástroj nad katalogem cloud computingu (dále jen „CC“).
Zde zveřejněné služby CC splnily v rámci zápisu nabídek CC veškeré požadavky zákona č. 365/2000 Sb., o informačních systémech veřejné správy pro zápis do katalogu CC, a to v dané bezpečnostní úrovni.
V katalogu CC lze vyhledávat:
- konkrétní služby CC materiálních poskytovatelů tzn. nepřímý prodej služeb CC materiálních poskytovatelů a přímý prodej služeb CC od materiálních poskytovatelů (*)
- konkrétní služby CC přeprodejců tzn. přímý prodej služeb CC od přeprodejců 5)
Nástroj pro vyhledávání v katalogu cloud computingu
Pravidla eGovernment cloudu
Přístup správců ISVS k eGC
Každý správce centralizovaného poskytovaného agendového informačního systému by měl postupně činit při správě a rozvoji svých informačních systémů takové kroky, aby oddělil vrstvu platformy a technologií od vrstvy komunikační a aplikační vrstvy příslušných informačních systémů. To znamená, že by se svými postupnými kroky měl připravit na to, že od určité doby bude provozovat svoje centralizované agendové informační systémy v cloudu a měl by postupně omezovat svoji závislost na vlastních datových centrech a pouze jím provozovaných technologických platformách.
Provozování AIS OVM v eGC v souvislosti s komunikací pomocí CMS/KIVS
Umístění AIS OVM v eGC znamená, že eGC je jen jiná adresa daného OVM. Zde jsou dvě možnosti přístupu do CMS:
- Připojené do CMS/KIVS je OVM a AIS v eGC je přesměrován do CMS/KIVS přes OVM (př. Portál občana). Pro tento scénář je AIS v eGC brán jako interní AIS OVM, který se připojuje do CMS/KIVS přes připojení daného OVM
Publikování portálu OVM
Publikování portálu OVM je specifický případ publikování AIS OVM, kdy se v rámci provozu portálu v eGC umožňuje, aby byly služby portálu dostupné pro klienty, kteří nejsou OVM, prostřednictvím internetu přímo od poskytovatele eGC.
Portál je v případě provozu na vlastní infrastruktuře publikován výhradně prostřednictvím CMS službou CMS2-02 Zveřejnění aplikace a to do:
- Do sítě Internet, služba CMS2-02-2
V případě umístění portálu v eGC, je umožněna publikace portálu z eGC, kdy:
- eGC je rozšířeným IP prostorem CMS/KIVS a
- AIS OVM všech subjektů, kteří přispívají do portálu OVM v eGC, čerpají údaje o subjektu práva prostřednictvím referenčního rozhraní.
Klienti, kteří nejsou OVM, přistupují k portálu v otevřeném internetu přes HTTPS publikovaném přímo z eGC.
Povinnosti komerčních poskytovatelů služeb eGC
Konkrétní povinnosti stanoví zákon o informačních systémech veřejné správy a na základě tohoto zákona pak vydané vyhlášky ministerstva a NÚKIB. Řídící orgán eGovernment Cloudu pak na základě zákona a vyhlášek připravuje a vydává metodické pokyny. Již nyní však platí pravidla pro nutnost připojení skrze infrastrukturu CMS/KIVS a tím i respektování katalogového listu služby připojení přes IPSec
Určování nástrojů osobní produktivity jako ISVS
Orgány veřejné správy se musí při poskytování interaktivních nástrojů osobní produktivity úředníka využívající cloud computing rozhodnout, zda jde o informační systém veřejné správy (ISVS) nebo jeho část ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), a mohou tak podléhat regulaci cloud computingu podle Hlavy VI tohoto zákona.
Dle § 2 odst. 1 písm. b) ZoISVS je: „informačním systémem veřejné správy funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy nebo plnění jiných funkcí státu anebo dalších veřejnoprávních korporací …“
Informační činností dle § 2 odst. 1 písm. a) se myslí: „získávání a poskytování informací, reprezentace informací daty, shromažďování, vyhodnocování a ukládání dat na nosiče a uchovávání, vyhledávání, úprava nebo pozměňování dat, jejich předávání, šíření, zpřístupňování, výměna, třídění nebo kombinování, blokování a likvidace dat ukládaných na nosičích. Informační činnost je prováděna správci, provozovateli a uživateli informačních systémů veřejné správy prostřednictvím technických a programových prostředků“.
Z definice ISVS vyplývá, že cílevědomá, avšak ne-systematická, informační činnost pro účely výkonu veřejné správy nemusí spadat pod rozsah definice. Scénáře interaktivního využívání nástrojů s podporou cloud computingu (jako jsou např. interaktivní nástroje umělé inteligence, volně dostupné on-line mapy nebo jazykové překladače) nesplní podmínku systematické informační činnosti výkonu veřejné správy, pokud využívání určitého konkrétního nástroje k určitému informačnímu účelu není interně v rámci orgánu veřejné správy ustanoveno jako závazné. Jestliže se tedy úředník sám rozhoduje ad-hoc, který a jestli vůbec nějaký on-line nástroj pro daný účel využije, nenaplní se tento atribut definice ISVS.
Naopak se lze domnívat, že systematické využití např. tabulkového kalkulátoru (např. MS Excel) v malé obci pro evidenci poplatků za psy nebo za hrobová místa naplní znaky „cílevědomé a systematické informační činnosti pro účely výkonu veřejné správy“, a tento informační systém by tedy měl být označen a spravován jako ISVS. Za rozlišující kritérium výkladu pojmu „systematická informační činnost pro účely výkonu veřejné správy“ tedy považujeme jakýkoli interní předpis OVS, který zavazuje úředníky využívat vždy určitý konkrétní nástroj (informační systém nebo jeho část) pro zabezpečení určitého účelu výkonu veřejné správy.
Ač tedy nástroje osobní produktivity jednoznačně spadají do definice informační činnosti, je potřeba vždy vážit hledisko systematičnosti pro účel výkonu veřejné správy.
Dále ještě zohledníme metodické vodítko Co je a co není ISVS. V kapitole „Pomůcka pro určování ISVS“ jsou uvedeny dvě pomocné otázky k rozhodování OVS, zda se v konkrétním případě nějakého informačního systému má jednat o ISVS:
- Bylo by nefunkčností informačního systému bezprostředně narušeno nebo ohroženo plnění povinnosti vyplývající z kompetencí daného orgánu veřejné správy?
- Jsou v informačním systému uloženy údaje o vykonávané správní činnosti nebo údaje pro podporu výkonu u této činnosti?
Pokud jsou odpovědi na tyto otázky ANO, s největší pravděpodobností se v případě posuzovaného informačního systému jedná o ISVS.
Toto vodítko může potvrdit výše vyslovený názor, že tabulkový kalkulátor instalovaný byť jen na jednom notebooku v rámci malé obce, který je však jediným zavedeným nástrojem pro správu určitých agend (viz výše), splní obě podmínky a měl by být tedy spravován jako ISVS.
Naopak, ad-hoc využití interaktivních nástrojů dle shora uvedených příkladů (interaktivní nástroje umělé inteligence, volně dostupné on-line mapy, on-line jazykové překladače apod.) zpravidla nedá odpověď “ano” na tyto dvě otázky metodického vodítka, a v takovém případě se nekvalifikuje jako ISVS.
Národní datová centra
Popis Národních datových center
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
Pravidla Národních datových center
NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.
Diskuze